🏛️Movimiento lateral
Esquema de pivoting
Tenemos el siguiente esquema de red que podemos usar para tener claro la visión de la red:

Después de lootear el host DEV01, encontramos el siguiente conjunto de credenciales al volcar los LSA Secrets:
Método alternativo para conseguir credenciales
Si no hubiéramos conseguido por lo que sea las credenciales de hporter podríamos haber enumerado el usuario igualmente desde la sesión de Meterpreter:
Y desde aquí cargar Mimikatz para extraer credenciales:
Dado que tenemos persistencia en DEV01 podemos usarlo como punto de partida para lanzar nuevos ataques.
Configurar pivoting
Debemos hacer el reenvío del puerto 3389 (RDP) del objetivo a un puerto que elijamos, cómo el 13389
Conexión por RDP
Usamos /drive:home,"/home/kali/Escritorio/hack-tools/Windowspara transferir archivos cómodamente entre las máquinas por RDP:

Análisis con Bloodhound
🩸BloodHoundUsaremos el recopilador SharpHound para enumerar todos los objetos de AD posibles y luego ingerir los datos en la interfaz gráfica de BloodHound para su revisión. Podemos descargar el ejecutable (aunque en una evaluación real, es mejor compilar nuestras propias herramientas) y usar el práctico administrador de archivos DNN para subirlo al objetivo. Queremos recopilar la mayor cantidad de datos posible y no tenemos que preocuparnos por la evasión, así que usaremos la flag -c All para usar todos los métodos de recopilación.
Sharphound.exe
Podemos escribir net use para ver la ubicación de nuestra unidad redirigida y luego transferir la herramienta.
También podríamos subir sharphound.exe a través del File Manager que descubrimos, lo cual es muy práctico.
Desde Meterpreter
Podríamos cargar Sharphound igualmente desde una sesión de Meterpreter abierta:
Y lo ejecutamos desde una shell:
ZIP generado
Esto generará un archivo Zip que podremos descargar de nuevo mediante la herramienta de gestión de archivos DNN o copiarla a nuestro Kali de la siguiente manera:
También nos lo podríamos descargar desde el File Management de DNN, mucho más práctico:

Buscando nuestro usuario hporter y seleccionando First Degree Object Control, podremos ver que el usuario tiene derechos ForceChangePassword sobre el usuario ssmalls.

Como apunte, podemos ver que todos los usuarios del dominio tienen acceso RDP al host DEV01. Esto significa que cualquier usuario del dominio puede acceder mediante RDP y, si escala privilegios, podría robar datos confidenciales como credenciales. Este hallazgo es importante; podemos calificarlo como Excessive Active Directory Group Privileges de riesgo medio. Si todo el grupo tuviera derechos de administrador local sobre un host, sin duda sería un hallazgo de alto riesgo.

Podemos usar PowerView para cambiar la contraseña del usuario ssmalls. Nos conectamos al destino mediante RDP tras comprobar que el puerto esté abierto. RDP nos facilitará la interacción con el dominio mediante una consola de PowerShell, aunque también podríamos hacerlo mediante nuestro acceso de reverse shell.
Para lograr esto, podemos usar otro comando de Port Forwarding SSH, de tipo Local Port Forwarding. Este comando nos permite enviar todo el tráfico RDP del host DEV01 al host dmz01 a través del puerto local 13389.
Una vez configurado este Port Forwarding, podemos usar xfreerdp para conectarnos al host mediante la redirección de unidad para transferir archivos de ida y vuelta fácilmente.
Cambiar la ruta donde se encuentran las herramientas de enumeración / explotación de Windows en nuestro equipo de atacante, en mi caso "/home/kali/Escritorio/hack-tools/Windows/AD-Tools"
Observamos que solo tenemos acceso a la consola, ya que este servidor no tiene instalado el rol de Experiencia de Escritorio, pero solo necesitamos una consola.

A continuación, escribimos powershell para colocarnos en una consola de PowerShell y podremos usar PowerView para cambiar la contraseña del usuario ssmalls de la siguiente manera:
Podemos volver a nuestro host de ataque y confirmar que la contraseña se cambió correctamente. Generalmente, queremos evitar este tipo de actividad durante una prueba de penetración, pero si es nuestra única opción, debemos confirmarlo con nuestro cliente. La mayoría nos pedirá que procedamos para ver hasta dónde llegamos, pero siempre es mejor preguntar.
Por supuesto, queremos anotar cualquier cambio como este en nuestro registro de actividad para poder incluirlo en un apéndice de nuestro informe.
Share Hunting
Tras investigar un poco más el host y el AD, no encontramos nada útil. BloodHound no muestra nada interesante para el usuario ssmalls. Tanto la sección "Enumeración con credenciales desde Windows" como la sección "Enumeración con credenciales desde Linux" abordaron la búsqueda de recursos compartidos de archivos con Snaffler y CrackMapExec, respectivamente.
En numerosas ocasiones, durante las pruebas de penetración, he tenido que recurrir a la búsqueda de recursos compartidos de archivos para encontrar información, como la contraseña de una cuenta de servicio o similar. A menudo he podido acceder a recursos compartidos departamentales (como TI) con credenciales con pocos privilegios debido a permisos NTFS débiles. En ocasiones, incluso he podido acceder a recursos compartidos de algunos o todos los usuarios de la empresa objetivo debido al mismo problema.
Con frecuencia, los usuarios desconocen que su unidad de disco personal es un recurso compartido de red asignado y no una carpeta local en su ordenador, por lo que pueden guardar allí todo tipo de datos confidenciales. Los permisos de los recursos compartidos de archivos son muy difíciles de mantener, especialmente en grandes organizaciones. A menudo, durante las pruebas de penetración, he tenido que buscar en recursos compartidos de archivos cuando me he quedado atascado. Recuerdo una prueba de penetración específica en la que tenía credenciales de usuario, pero me quedé atascado durante unos días y tuve que revisar recursos compartidos. Después de un tiempo, encontré un web.configarchivo con credenciales válidas para una cuenta de servicio MSSQL. Esto me otorgó permisos de administrador local en un servidor SQL donde un administrador de dominio había iniciado sesión, y se acabó el juego.
En otras ocasiones, he encontrado archivos con contraseñas en unidades de usuario que me han ayudado a avanzar. Dependiendo de la organización y de cómo estén configurados sus permisos de archivo, puede haber mucho que analizar y mucho "ruido". Una herramienta como Snaffler puede ayudarnos a gestionarlo y a centrarnos en los archivos y scripts más importantes. Probémoslo.
Primero, ejecutemos Snaffler desde nuestra sesión RDP como el usuario hporter.
Esto no revela nada interesante, así que volvamos a ejecutar nuestra enumeración de recursos compartidos como el usuario ssmalls. Los usuarios suelen tener diferentes permisos, por lo que la enumeración de recursos compartidos debe considerarse un proceso iterativo. Para evitar tener que volver a usar RDP, podemos usar el módulo de CrackMapExec spider_plus para explorar.
Si esto falla probar a ejecutarlo varias veces
Esto crea un archivo para nosotros en nuestro directorio /tmp, así que veámoslo.
El archivo SQL Express Backup.ps1 en el recurso compartido IT/Private/Development parece muy interesante. Vamos a descargarlo usando smbclient. Primero, necesitamos conectarnos.
Luego podemos navegar hasta el recurso compartido Development.
Al revisar el archivo, vemos que se trata de una especie de script de backup con credenciales codificadas para backupadm, otra contraseña de acceso directo al teclado. Observo una tendencia en esta organización. Quizás el mismo administrador la configuró como la contraseña que usamos antes por fuerza bruta con Hydra, ya que esto está relacionado con el desarrollo.

Esta cuenta backupadm nos indica que es el administrador que tiene acceso a todos los backups, por lo que podremos encontrar algún backup interesante con más contraseñas.
Antes de intentar usar esta cuenta en algún lugar, investiguemos un poco más. Primero veremos todos los recursos compartidos SMB:
Hay un archivo .vbs interesante en el recurso compartido SYSVOL, al que pueden acceder todos los usuarios del dominio.
Podemos descargarlo nuevamente con smbclient.
Revisando el script encontramos otro conjunto de credenciales: account:L337^p@$$w0rD
Al revisar BloodHound, no encontramos ningún usuario account, así que podría ser una contraseña antigua. Según el año en los comentarios del script, es probable que lo sea. Podemos añadir esto a nuestros hallazgos sobre datos confidenciales en recursos compartidos y anotarlo en la sección de credenciales de nuestras notas del proyecto. En ocasiones, encontraremos contraseñas antiguas que aún se usan para cuentas de servicio antiguas y que podemos usar para un ataque de Password Spraying
Kerberosting con Powerview
Para cubrir todas las bases, verifiquemos si hay usuarios compatibles con Kerberos. Podemos hacerlo mediante Proxychains usando GetUserSPNs.py de Impacket o PowerView desde el objetivo. En nuestra sesión RDP, cargaremos PowerView y enumeraremos las cuentas de Service Principal Names (SPN).
Hay bastantes. Vamos a exportarlos a un archivo CSV para procesarlos sin conexión.
Podemos descargar este archivo mediante la redirección de la unidad RDP que configuramos anteriormente:
Abrimos el archivo .csv con LibreOffice Calc o Excel, extraemos los hashes y los agregamos a un archivo ilfreight_spns.
Podemos extraer solamente los hashes en un formato para crackearlo con hashcat con ChatGPT
Ahora podemos ejecutar Hashcat para ver si podemos crackear alguno y, de ser así, si corresponden a cuentas con privilegios.
Un hash falla, pero al consultar BloodHound, la cuenta backupjob no parece sernos útil. Aún podemos anotar otro hallazgo Weak Kerberos Authentication Configuration (Kerberoasting) y seguir adelante.
Password Spraying
Otra técnica de movimiento lateral que vale la pena explorar es el Password Spraying. Podemos usar DomainPasswordSpray.ps1 o la versión de Windows de Kerbrute desde el host DEV01, o usar Kerbrute desde nuestro host de ataque mediante Proxychains (todos con los que vale la pena experimentar).

Encontramos una contraseña válida para dos usuarios más, pero ninguno tiene acceso interesante. Aun así, conviene anotar el hallazgo Weak Active Directory Passwords y continuar.
Técnicas varias
Probemos algunas cosas más para cubrir todas las necesidades.
Registry.xml
Podemos buscar en el recurso compartido SYSVOL archivos Registry.xml que puedan contener contraseñas de usuarios configurados con inicio de sesión automático mediante la directiva de grupo.
Esto no arroja resultados útiles.
Contraseñas en la descripción
A continuación, podemos buscar contraseñas en la Description de los campos de usuario de AD, lo cual no es muy común, pero aún lo vemos de vez en cuando (¡incluso he visto contraseñas de cuentas de administrador de dominio y de empresa aquí!).
Encontramos una para la cuenta frontdesk, pero esta tampoco es útil. Cabe destacar que existen múltiples maneras de obtener la contraseña de una cuenta de usuario en este dominio, y existe un host con privilegios RDP otorgados a todos los usuarios del dominio. Aunque estas cuentas no tienen derechos especiales, sería un cliente el que solucionaría estos problemas, ya que un atacante a menudo solo necesita una contraseña para tener éxito en AD.
Aquí podemos anotar un hallazgo Passwords in AD User Description Field y continuar.
Próximos pasos
En este punto, hemos investigado a fondo el dominio y hemos encontrado varios conjuntos de credenciales, pero nos topamos con un obstáculo. Volviendo a lo básico, podemos ejecutar un análisis para ver si algún host tiene WinRM habilitado e intentar conectarnos con cada conjunto de credenciales.
Lo más efectivo es ejecutarlo contra todos los hosts internos que hemos descubierto y que guardamos anteriormente en el archivo live_hosts:
Vemos que tenemos WinRM en todas las máquinas:
También podemos hacer un escaneo específico de un host en concreto:
El host 172.16.8.50, o MS01 es el único que queda en el que no hemos podido entrar aparte del controlador de dominio, así que vamos a intentarlo usando evil-winrm y las credenciales del usuario backupadm. que encontramos anteriormente en el archivo SQL Express Backup.ps1 del recurso compartido IT/Private/Development
¡Funciona y estamos dentro!
En este punto, podríamos usar este shell de evil-winrm para enumerar el dominio con una herramienta como PowerView. Ten en cuenta que necesitaremos usar un objeto PSCredential para realizar la enumeración desde este shell debido al problema de "doble salto" de Kerberos . Practica esta técnica y vea qué otras herramientas de enumeración de AD podría usar de esta manera.
Volviendo a la tarea en cuestión. Nuestro usuario no es administrador local y whoami /priv no muestra ningún privilegio útil. Al revisar el módulo Escalada de privilegios en Windows, no encontramos nada interesante, así que buscamos credenciales. Tras investigar un poco, encontramos un archivo unattend.xml sobrante de una instalación anterior.
Verifiquemos si contiene alguna contraseña, como a veces ocurre.
Encontramos las credenciales del usuario local ilfserveradm, con la contraseña Sys26Admin.
Este no es un usuario de dominio, pero es interesante que tenga acceso a Escritorio remoto, pero no sea miembro del grupo de administradores locales. Accedamos mediante RDP y veamos qué podemos hacer. Tras acceder mediante RDP y realizar una enumeración adicional, encontramos software no estándar instalado en el directorio C:\Program Files (x86)\SysaxAutomation.

Una búsqueda rápida revela este exploit de escalada de privilegios local. Según la descripción, este Servicio Programado Sysax se ejecuta como la cuenta local SYSTEM y permite a los usuarios crear y ejecutar trabajos de copia de seguridad. Si se elimina la opción de ejecutar como usuario, la tarea se ejecutará de forma predeterminada como la cuenta SYSTEM. ¡Hagamos una prueba!
Primero, creamos un archivo llamado pwn.bat en C:\Users\ilfserveradm\Documents que contenga la línea net localgroup administrators ilfserveradm /add para agregar a nuestro usuario al grupo de administradores locales (en ocasiones, necesitaremos corregirlo y anotarlo en los apéndices de nuestro informe). A continuación, podemos realizar los siguientes pasos:
Abrimos
C:\Program Files (x86)\SysaxAutomation\sysaxschedscp.exeSeleccionamos
Setup Scheduled/Triggered TasksAdd Task (Triggered)
Folder to monitor
C:\Users\ilfserveradm\DocumentsActivamos
Run task if a file is added to the monitor folder or subfolder(s)Elegimos
Run any other Programy elegimosC:\Users\ilfserveradm\Documents\pwn.batDesmarcamos
Login as the following user to run taskHacemos clic en
Finishy luegoSave
Podéis ver las imágenes del proceso en la pregunta 3 del caso práctico al final de esta sección.
Finalmente, para activar la tarea, creamos un nuevo archivo .txt en el directorio C:\Users\ilfserveradm\Documents. Podemos comprobar que el usuario ilfserveradm se ha añadido al grupo Administrators.
Post-explotación / Looting
A continuación, realizaremos una post-explotación en el host MS01. Observamos un par de archivos interesantes en la raíz de la unidad c:\ budget_data.xlsx, Inlanefreight.kdbx que merecería la pena revisar y, posiblemente, informar al cliente si no se encuentran en la ubicación prevista. A continuación, podemos usar Mimikatz, para elevar a un token NT AUTHORITY\SYSTEM y volcar los LSA Secrets.
Encontramos una contraseña establecida, pero no un nombre de usuario asociado. Parece ser una cuenta configurada con inicio de sesión automático, por lo que podemos consultar el Registro para encontrar el nombre de usuario.
Ahora tenemos un nuevo par de credenciales: mssqladm:DBAilfreight1!.
Antes de continuar, revisemos si hay otras credenciales. Vemos que Firefox está instalado, así que podemos usar la herramienta LaZagne para intentar recuperar las credenciales guardadas en el navegador. No hubo suerte, pero siempre vale la pena revisarlo.
También vale la pena ejecutar Inveigh una vez que tengamos administrador local en un host para ver si podemos obtener hashes de contraseñas para cualquier usuario.
Acercándonos
Hemos enumerado el dominio por completo, nos hemos movido lateralmente y hemos saqueado lo que pudimos encontrar en los hosts objetivo. En este punto, tenemos las credenciales del usuario mssqladm y podemos seguir buscando una ruta para comprometer el dominio.
Caso práctico
Pregunta 1
Busca un script de backup que contenga la contraseña del usuario
backupadm. Indica la contraseña de este usuario como respuesta.
Configuración de pivoting con SSH
Este comando nos permite enviar todo el tráfico RDP del host DEV01 al host dmz01 a través del puerto local 13389 para conectarnos por RDP:
Conexión por RDP
Configurar la ruta donde están los scripts de enumeración como PowerView.ps1 en nuestro equipo atacante. Solo tenemos una shell:

Análisis con Bloodhound
Buscando nuestro usuario hporter y seleccionando First Degree Object Control, podemos ver que el usuario tiene derechos ForceChangePassword sobre el usuario ssmalls.

Descargar PowerView
En la ruta c:\DotNetNuke\Portals\0 comprobamos con net use la ubicación de nuestra unidad redirigida y luego transferimos la herramienta:
Cambiar contraseña del usuario Smalls con PowerView
Conexión por RDP con el usuario smalls y la nueva contraseña
Vemos que funciona, por lo que la contraseña se ha cambiado perfectamente.
Enumerar recursos compartidos
Con Snaffler encontramos varios recursos compartidos que pueden contener credenciales. Vamos a conectarnos por SMB a Department Shares configurando correctamente el pivoting:
Luego podemos navegar hasta el recurso compartido IT/Private/Development. Dentro encontramos un script de backup que nos vamos a descargar:
Al leer el archivo encontramos las credenciales de backupadm:
Pregunta 2
Realiza un ataque de Kerberoasting y recupera los tickets TGS de todas las cuentas configuradas como SPN. Descifra el TGS del usuario de
backupjoby envía la contraseña en texto plano como respuesta.
Enumeración de usuarios Kerberos
En la powershell que tenemos abierta con PowerView ejecutamos:
Vamos a exportarlos a un archivo CSV para procesarlos sin conexión.
Lo más sencillo es leer el CSV con type y copiarlo a nuestro Kali Linux. También podemos copiarlo directamente a nuestro Kali con:
Cracking con Hashcat
Debemos limpiar el archivo y dejar solo los hashes kerberos para poder crackearlo con Hashcat:
Tenemos la contraseña del usuario backupjob!
Pregunta 3
Escala privilegios en el host
MS01y envía el contenido del archivoflag.txten el Escritorio del administrador.
El host 172.16.8.50, o MS01 es el único que queda en el que no hemos podido entrar aparte del controlador de dominio, así que vamos a intentarlo usando evil-winrm y las credenciales del usuario backupadm.
Escaneo de puertos
Conexión con EvilWinrm
Búsqueda de archivo unattend.xml
Encontramos las credenciales del usuario ilfserveradm:Sys26Admin. Este usuario pertenece al grupo Remote Desktop Users, por lo que vamos a conectarnos para ver que nos encontramos:
Configuración de pivoting
Especificamos el host 172.16.8.50:
En este host si tenemos interfaz gráfica:

En el directorio C:/ nos encontramos un archivo de Keepass Inlanefreight.kdbx interesante, pero no está instalado Keepass, por lo que no merece la pena detenerse aquí, aunque transfiriendo este archivo a Kali y usando keepass2john para convertirlo a un formato legible por john, descubrimos la contraseña Password1, que nos puede servir para técnicas de Password Spraying:
Enumeración de programas instalados
Encontramos un programa que nos llama la atención: Sysax FTP Automation 6 versión 6.1.0. Rápidamente encontramos un exploit válido para escalar privilegios:
Solo tenemos que seguir estos pasos:
Primero, creamos un archivo llamado pwn.bat en C:\Users\ilfserveradm\Documents que contenga la línea net localgroup administrators ilfserveradm /add para agregar a nuestro usuario al grupo de administradores locales (en ocasiones, necesitaremos corregirlo y anotarlo en los apéndices de nuestro informe). A continuación, podemos realizar los siguientes pasos:
Abrimos
C:\Program Files (x86)\SysaxAutomation\sysaxschedscp.exe

Seleccionamos
Setup Scheduled/Triggered TasksAdd Task (Triggered)

Folder to monitor
C:\Users\ilfserveradm\DocumentsActivamos
Run task if a file is added to the monitor folder or subfolder(s)

Elegimos
Run any other Programy elegimosC:\Users\ilfserveradm\Documents\pwn.bat

Desmarcamos
Login as the following user to run task

Hacemos clic en
Finishy luegoSave

Comprobar administradores locales
Finalmente, para activar la tarea, creamos un nuevo archivo .txt en el directorio C:\Users\ilfserveradm\Documents. Podemos comprobar que el usuario ilfserveradm se ha añadido al grupo Administrators.
Acceso a la flag
Pregunta 4
Obtén el hash de la contraseña NTLMv2 del usuario
mpalledorousy crackéalo para revelar el valor en texto plano. Envíe la contraseña del usuario como respuesta.
Ahora que somos administradores locales vamos a usar Mimikatz para elevar a un token NT AUTHORITY\SYSTEM y volcar los LSA Secrets.
Abrimos un CMD como administrador local, poniendo .\ delante del nombre del usuario, ya que de otra manera se autentica contra el dominio y no contra la máquina actual:

Encontramos una contraseña establecida, pero no un nombre de usuario asociado. Parece ser una cuenta configurada con inicio de sesión automático, por lo que podemos consultar el Registro para encontrar el nombre de usuario.
Ahora tenemos un nuevo par de credenciales: mssqladm:DBAilfreight1!. Explotaremos este usuario en la siguiente sección.
LLMNR Poisoning con Inveight
Cracking de Hash NTLMv2
Lo tenemos!
Última actualización
