EscapeTwo
EscapeTwo es una máquina Windows de dificultad fácil centrada en un escenario de compromiso completo de dominio, donde se nos proporcionan credenciales de un usuario con pocos privilegios. Aprovechamos estas credenciales para acceder a un recurso compartido que contiene un archivo Excel dañado. Modificando su estructura de bytes logramos extraer credenciales, que luego utilizamos en un ataque de password spraying en el dominio, obteniendo acceso válido a un usuario con permisos sobre MSSQL.
Desde ahí, enumeramos el sistema y conseguimos nuevas credenciales de SQL, que al aplicarlas nos permiten acceso por WinRM. Al continuar con el análisis del dominio, descubrimos que el usuario tiene privilegios de WriteOwner sobre una cuenta que administra los ADCS. Esto nos permite enumerar los servicios de certificados, donde encontramos una configuración insegura en Active Directory Certificate Services.
Al explotar esta mala configuración, logramos obtener el hash del usuario Administrator, lo que nos permite comprometer completamente el dominio.
Reconnaissance
Para la fase de reconocimiento inicial de la máquina EscapeTwo utilizamos nuestra herramienta personalizada iRecon. Esta herramienta automatiza un escaneo Nmap completo que incluye:
Detección de puertos TCP abiertos (
-p- --open).Escaneo de versiones (
-sV).Ejecución de scripts NSE típicos para enumeración adicional (
-sC).Exportación del resultado en XML y conversión a HTML para facilitar su lectura.
Para empezar, exportaremos en una variable de entorno llamada IP la dirección IP de la máquina objetivo, lanzaremos la herramienta de iRecon proporcionándole la variable de entorno.
Resumen de Puertos Abiertos
En la enumeración de puertos encontramos importantes como los siguientes:
88
Kerberos
445
SMB
389
LDAP
636
LDAPS
1433
Microsoft SQL Server (MSSQL)
5985
WinRM
Por los puertos encontrados, parece que nos estamos enfrentando a un Domain Controller (DC) de Windows.
A través de la herramienta de netexec y ldapsearch enumeraremos el equipo para localizar más información. Entre la información obtenida, verificamos el hostname, versión del SO y el nombre del dominio.
En nuestro archivo /etc/hosts añadiremos las siguientes entradas correspondientes para que a la hora de hacer referencia al dominio, hostname o FQDN (nombre de dominio completo que identifica de forma única una máquina o servidor en una red).
Validaremos las credenciales que se nos han proporcionado, verificando que nos sirven para autenticarnos por LDAP.
Kerberoasting Attack (FAILED)
En este caso ya contamos con credenciales válidas del dominio, intentamos realizar un ataque de Kerberoasting.
Este ataque se basa en solicitar un TGS (Ticket Granting Service) para aquellas cuentas del dominio que tengan asignado un SPN (servicePrincipalName). Para ello, usamos la herramienta GetUserSPNs.py de Impacket, que nos permite identificar usuarios con SPNs asociados y solicitar el TGS correspondiente para luego intentar crackear el hash offline.
En este caso, el ataque tuvo éxito y encontró a dos cuentas que tienen un SPN asignado. Probaremos de crackear de manera offline estos hashes TGS obtenidos en el archivo hashes.txt.
Al intentar crackear a través de hashcat los hashes obtenidos, comprobamos que la contraseña no se encuentra dentro del diccionario típico de rockyou.txt. Comprobaremos más adelante otros tipos de ataques a realizar, etc.
AS-REP Roast Attack (FAILED)
Realizaremos una enumeración de los usuarios del dominio a través de NetExec. Para ello utilizaremos el siguiente comando para obtener solamente los nombres de uusarios disponibles y los almacenaremos en el archivo users.txt.
Dado que disponemos de un listado potencial de usuarios válidos del dominio, intentamos realizar un AS-REP Roast Attack.
Este ataque consiste en solicitar un TGT (Ticket Granting Ticket) a aquellos usuarios del listado (users.txt) que tengan habilitado el flag DONT_REQ_PREAUTH de Kerberos. Para esto, utilizamos la herramienta GetNPUsers.py de la suite Impacket, que nos permite identificar qué usuarios tienen esa opción activa.
El objetivo es obtener un TGT sin autenticación previa y luego intentar crackear offline la contraseña. Sin embargo, ninguno de los usuarios tenía configurado dicho flag, por lo tanto, no eran susceptibles a AS-REP Roasting.
Shell as sql_svc
SMB Enumeration
A través de las credenciales de rose@sequel.htb, realizaremos una enumeración del servicio SMB. En el resultado obtenido, comprobamos que disponemos del permiso de READ sobre varios recursos compartidos, entre los que destacamos los siguientes:
Accounting Department
Users
El módulo spider_plus permite enumerar de forma automática el contenido de los recursos compartidos SMB a los que tenemos acceso, sin necesidad de montarlos manualmente ni navegar carpeta por carpeta.
Este módulo analiza los shares accesibles (como Users, SYSVOL, NETLOGON, etc.), y recopila metadatos sobre todos los archivos y carpetas encontrados: nombre, tamaño, extensiones, rutas, y más.
Esto nos permite detectar archivos interesantes, como contraseñas, documentos internos, scripts de login o información sensible, sin descargar nada.
Tras usar el módulo spider_plus, encontramos varios archivos en los recursos SMB. En el share Accounting Department destacaron dos documentos Excel:
accounting_2024.xlsx(9.98 KB)accounts.xlsx(6.62 KB)
Por el nombre y la ubicación, es probable que contengan información interna o sensible relacionada con temas contables. Son archivos que vale la pena revisar más a fondo.
A través de la herramienta NetExec (nxc), descargamos los archivos .xlsx identificados previamente en el recurso compartido Accounting Department, con el objetivo de analizarlos de forma local.
Information Extraction from an Unreadable Excel File via Decompression
Al intentar abrir cualquiera de los archivos Excel descargados, observamos que no se visualizan correctamente. En lugar de mostrar datos estructurados, se presentan en un formato ilegible, compuesto por caracteres extraños y sin sentido aparente.
Esto sugiere que el archivo no es un documento de Excel convencional o está corrupto. Sin embargo, al tratarse de un archivo .xlsx, sabemos que internamente funciona como un contenedor .zip, lo cual nos da una vía alternativa para intentar extraer su contenido real.
Dado que el archivo accounts.xlsx no se podía visualizar correctamente al abrirlo, procedimos a descomprimirlo directamente utilizando la herramienta unzip. Al tratarse de un archivo .xlsx, sabíamos que internamente es un contenedor ZIP con una estructura basada en archivos XML.
Durante la extracción se desplegaron múltiples archivos XML, como workbook.xml, sheet1.xml, sharedStrings.xml, entre otros, que conforman la estructura y contenido del documento. Esto nos permite analizar el contenido de forma manual, sin depender del visor de Excel.
Una vez descomprimido el archivo, revisamos el fichero xl/sharedStrings.xml, que contiene los textos visibles dentro de las celdas del Excel. Ahí encontramos datos claramente estructurados como una tabla de usuarios con sus respectivas credenciales:
Angela Martin –
angela@sequel.htb/0fwz7Q4mSpurIt99Oscar Martinez –
oscar@sequel.htb/86LxLBMgEWaKUnBGKevin Malone –
kevin@sequel.htb/Md9Wlq1E5bZnVDVosa –
sa@sequel.htb/MSSQLP@ssw0rd!
Esto confirma que el archivo contenía información sensible relacionada con usuarios del dominio, incluyendo credenciales en texto claro, lo cual representa una vulnerabilidad crítica si alguno de estos accesos sigue siendo válido.
Password Spraying
Tras extraer las credenciales del archivo Excel, añadimos los nuevos usuarios que no teníamos previamente al archivo users.txt, y guardamos las contraseñas descubiertas en un archivo aparte (passwords.txt) para su posterior uso en ataques de autenticación.
A través de NetExec verificamos unas nuevas credenciales válidas obtenidas para el usuario oscar@sequel.htb.
A través de este usuario también realizamos la enumeración correspondiente pero no logramos obtener ningún tipo de información adicional.
MSSQL Enumeration
En la enumeración inicial de puertos a través de Nmap, descubrimos que se encontraba el servicio de MSSQL (Microsoft SQL Server) expuesto a través del puerto por defecto 1433. Con lo cual también decidimos probar a autenticarnos con los usuarios que disponíamos para verificar si lográbabmos obtener información interesante.
Despúes de una enumeración con dichos usuarios, comprobamos que podemos autenticarnos al servicio MSSQL.
El hash stealing a través de xp_dirtree es una técnica que se aprovecha de cómo funcionan algunas funciones de MSSQL al acceder a rutas remotas. En concreto, xp_dirtree intenta leer el contenido de una carpeta, y si le damos una ruta UNC (como \\IP\recurso), el servidor intenta autenticarse contra ese recurso compartido.
Esto provoca que el servidor MSSQL envíe automáticamente las credenciales del usuario del servicio (por ejemplo, sql_svc) a nuestra máquina, lo que nos permite capturar su hash NTLMv2 con herramientas como Responder.
Para ello, ejecutaremos nuestro responder que recibirá ese hash NTLMv2.
A través de NetExec nos autenticaremos al servicio MSSQL y ejecutaremos la QUERY para abusar del componente xp_dirtree y así obtener el hash NTLMv2.
Esto confirma que logramos capturar el hash del usuario sql_svc, el cual puede ser utilizado en ataques de cracking o relay dependiendo del entorno. Pero como vimos anteriormente, este usuario también era susceptible a Kerberoasting y no pudimos crackear su hash TGS.
Durante la revisión del archivo XML extraído del Excel, identificamos unas credenciales asociadas al usuario sa junto a una contraseña que parecía estar relacionada con MSSQL (MSSQLP@ssw0rd!).
Al probar estas credenciales mediante autenticación por defecto (Windows Auth), el login falló, lo cual indica que sa no es un usuario del dominio, razón por la cual tampoco apareció en el password spraying inicial.
Sin embargo, al intentar autenticación local (--local-auth), las credenciales funcionaron correctamente.
Abusing xp_cmdshell component on MSSQL (RCE)
Al contar con acceso como sa, la cuenta administrativa por defecto de SQL Server, podemos aprovechar el componente xp_cmdshell para ejecutar comandos directamente en el sistema operativo.
Utilizando NetExec, es posible hacerlo con el parámetro -x, que permite lanzar comandos remotos a través del servicio MSSQL.
El resultado confirma que la ejecución es exitosa y que los comandos se ejecutan con el contexto del usuario sequel\sql_svc, lo cual nos da ejecución remota de comandos (RCE) en el host comprometido.
Utilizaremos una Reverse Shell de https://revshells.com en PowerShell para obtener acceso a la máquina directamente.
Nos pondremos en escucha por el puerto especificado en el generador de RevShells.
A través de NetExec ejecutaremos el comando que se nos ha proporcionado para ganar acceso al Domain Controller a través de la Reverse Shell de PowerShell.
Verificamos que logramos acceder al sistema a través del usuario sequel\sql_svc.
Auth as ryan
Sensitive Credentials Exposed in SQL Server Configuration File
Realizando una enumeración del DC, nos encontramos con un archivo de configuración de SQL en el cual aparecen en texto plano las credenciales del usuario que disponemos actualmente.
Validaremos que las credenciales encontradas en ese archivo de configuración son válidas para el usuario sequel\sql_svc.
Password Spraying
Comprobamos si la contraseña WqSZAF6CysDQbGb3 era reutilizada por otros usuarios del dominio. Para ello, realizamos un password spraying con NetExec utilizando dicha contraseña contra un listado de usuarios:
Como resultado, confirmamos que esta contraseña es válida para dos cuentas:
ryan:WqSZAF6CysDQbGb3sql_svc:WqSZAF6CysDQbGb3
Esto indica una posible reutilización de credenciales, una práctica insegura que puede facilitar movimientos laterales en el entorno.
Probamos de validar si con estas nuevas credenciales del usuario ryan obtenidas, podemos autenticarnos a WinRM para acceder remotamente al DC. Verificamos que en el resultado nos aparece como Pwn3d! lo cual nos confirma el acceso.
A través de NetExec ejecutaremos comandos mediante PowerShell a través del parámetro (-X) y obtendremos finalmente la flag user.txt.
Auth as ca_svc
BloodHound Enumeration
En este punto realizamos una enumeración del dominio utilizando RustHound, un collector compatible con BloodHound y con soporte para Active Directory Certificate Services (ADCS).
Por otro lado, levantaremos nuestro BloodHound CE para tenerlo disponible y poder subir la información recopilada en el punto anterior.
Abusing WriteOwner privileges to gain full control from a user
Durante el análisis en BloodHound, identificamos que el usuario ryan@sequel.htb posee el privilegio WriteOwner sobre el objeto ca_svc@sequel.htb.
Este privilegio permite que ryan se establezca como propietario del objeto, lo que a su vez le otorga control total sobre él. A partir de ahí, es posible llevar a cabo distintos tipos de ataques. Entre los más relevantes destacamos:
Targeted Kerberoasting
Shadow Credentials
Reset de contraseña (aunque no recomendable en un entorno real de pentesting)
Este tipo de abuso es especialmente útil cuando queremos escalar privilegios sin modificar directamente contraseñas ni levantar alertas.
A través de BloodyAD, nos convertimos en propietarios del usuario ca_svc aprovechando el privilegio WriteOwner detectado en BloodHound. Una vez asignado este cambio, nos otorgamos el permiso GenericAll, lo que nos da control total sobre la cuenta. Con este acceso, podemos llevar a cabo ataques como Shadow Credentials, Kerberoasting dirigido , etc.
Shadow Credentials Attack through certipy-ad
Aprovechando el control total que teníamos sobre la cuenta ca_svc, realizamos un ataque de Shadow Credentials utilizando Certipy. Este ataque consiste en inyectar un certificado malicioso dentro del atributo msDS-KeyCredentialLink del usuario objetivo, permitiéndonos autenticarnos como él sin conocer su contraseña.
En este caso, usamos Certipy para automatizar el proceso. Al finalizar, obtuvimos un TGT válido y la caché de credenciales (.ccache) para ca_svc, así como su hash NTLM, sin necesidad de modificar la contraseña ni generar alertas visibles.
Auth as Administrator
ESC4 exploitation case with certipy-ad
En BloodHound verificamos que la cuenta ca_svc@sequel.htb posee el privilegio GenericAll sobre una plantilla de certificado vulnerable. Esta relación nos permite abusar de una vulnerabilidad tipo ESC4, que consiste en emitir certificados maliciosos para autenticarnos como otros usuarios privilegiados, en este caso Domain Admins.
Usando certipy-ad, identificamos que la plantilla de certificado DunderMifflinAuthentication es vulnerable a ESC4. Esta plantilla permite autenticación como cliente, está habilitada, y ca_svc (a través del grupo Cert Publishers) tiene permisos peligrosos como WriteOwner, WriteDACL y FullControl.
Esta configuración nos permite emitir certificados maliciosos en nombre de cualquier usuario del dominio, incluyendo administradores, facilitando una escalada directa a Domain Admin.
Seguiremos los siguientes pasos para poder abusar del ESC4 en el ADCS.
Aprovechando los permisos sobre la plantilla DunderMifflinAuthentication, modificamos su configuración mediante certipy-ad. Antes de realizar cambios, se guardó la configuración original por seguridad. La plantilla fue actualizada con éxito, lo que nos permitirá emitir certificados personalizados para llevar a cabo una escalada de privilegios.
Tras modificar la plantilla DunderMifflinAuthentication, volvimos a analizar su configuración con certipy-ad. Se confirmó que los cambios fueron aplicados correctamente y que el grupo Cert Publishers, al que pertenece ca_svc, mantiene permisos peligrosos como Full Control, WriteOwner, WriteDACL y WriteProperty.
Certipy vuelve a marcar la plantilla como vulnerable a ESC4, lo que valida que sigue siendo explotable para emitir certificados maliciosos y escalar privilegios dentro del dominio.
Una vez confirmada la vulnerabilidad en la plantilla DunderMifflinAuthentication, procedimos a solicitar un certificado malicioso usurpando la identidad del usuario Administrator. Para ello, utilizamos certipy-ad, aprovechando los permisos de ca_svc sobre la plantilla.
La solicitud se completó con éxito y obtuvimos un certificado válido con UPN Administrator. El certificado fue guardado localmente en formato .pfx, lo que nos permitirá autenticarnos como Administrator mediante técnicas como Pass-the-Cert.
Con el certificado malicioso generado previamente, realizamos una autenticación como Administrator utilizando Pass-the-Cert a través de certipy-ad.
La autenticación fue exitosa, se obtuvo un TGT válido y, además, se recuperó el hash NTLM del usuario administrator@sequel.htb.
Abusing through Pass-the-Hash (PtH) on NetExec
Utilizando el hash NTLM obtenido previamente del usuario Administrator, realizamos una autenticación mediante Pass-the-Hash (PtH) usando NetExec.
La prueba fue exitosa, confirmando que el hash es válido y que tenemos acceso completo como Administrator a través de WinRM. Esto demuestra el control total sobre el sistema con privilegios de Domain Admin, sin necesidad de conocer la contraseña en texto claro.
A través de NetExec obtendremos finalmente la flag root.txt sin necesidad de acceder al Domain Controller.
Última actualización
¿Te fue útil?