Escape

Escape es una máquina Windows Active Directory de dificultad media que comienza con un recurso compartido SMB en el que los usuarios autenticados como invitados pueden descargar un archivo PDF confidencial. Dentro del archivo PDF hay credenciales temporales disponibles para acceder a un servicio MSSQL que se ejecuta en la máquina. Un atacante puede forzar al servicio MSSQL a autenticarse en su máquina y capturar el hash. Resulta que el servicio se está ejecutando bajo una cuenta de usuario y el hash es descifrable. Con un conjunto válido de credenciales, un atacante puede ejecutar un comando en la máquina usando WinRM. Al enumerar la máquina, un archivo de registro revela las credenciales del usuario ryan.cooper. Una enumeración adicional de la máquina revela que hay una autoridad de certificación presente y una plantilla de certificado es vulnerable al ataque ESC1, lo que significa que los usuarios que son legibles para usar esta plantilla pueden solicitar certificados para cualquier otro usuario en el dominio, incluidos los administradores de dominio. Por lo tanto, al explotar la vulnerabilidad ESC1, un atacante puede obtener un certificado válido para la cuenta de administrador y luego usarlo para obtener el hash del usuario administrador.


Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Escape. Este resultado lo almacenaremos en un archivo llamado allPorts.

A través de la herramienta de extractPorts, la utilizaremos para extraer los puertos del archivo que nos generó el primer escaneo a través de Nmap. Esta herramienta nos copiará en la clipboard los puertos encontrados.

Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX para posteriormente trabajar con ellos. Verificamos a través del resultado obtenido de que la máquina se trata de un Domain Controller (DC) por los puertos y servicios que se encuentran expuestos.

Transformaremos el archivo generado targetedXML para transformar el XML en un archivo HTML para posteriormente montar un servidor web y visualizarlo.

Accederemos a http://localhost y verificaremos el resultado en un formato más cómodo para su análisis.

A través de la herramienta de nxc 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.

Añadiremos en nuestro archivo /etc/hosts las entradas correspondientes para que a la hora de hacer referencia al dominio o el equipo, nos responda correctamente a la dirección IP del Domain Controller.

RID Cycling Attack

Revisaremos si el usuario guest (Invitado) se encuentra habilitado en el dominio. A través de nxc logramos verificar de la existencia del usuario, con lo cual podríamos llegar a intentar enumerar el SMB con este usuario, probar de enumerar usuarios, etc.

A través de la herramienta de ridenum trataremos de realizar un RID Cycling Attack para lograr enumerar usuarios a través de fuerza bruta del RID. Comprobamos el resultado en el cual se muestran los diferentes nombres de usuarios existentes en el dominio.

Nos guardaremos el resultado en el archivo users.txt. A través de expresiones regulares, nos quedaremos solamente con los nombres de usuarios correspondientes.

AS-REP Roast Attack [FAILED]

Dado que disponemos de una lista potencial de usuarios válidos del dominio, probaremos de realizar un AS-REP Roast Attack para lograr obtener un Ticket Granting Ticket (TGT) de aquellos usuarios que tengan asignado el DONT_REQ_PREAUTH de Kerberos.

En este caso, no logramos obtener ningún hash debido que ningún usuario tenía la flag marcada.

SMB Enumeration

A través del usuario guest (Invitado) realizaremos una enumeración de los recursos compartidos del sistema para verificar si a través de este usuario tenemos acceso algún recurso compartido.

En el resultado obtenido, verificamos que tenemos acceso al recurso compartido Public con permisos de READ.

Mediante el módulo de spider_plus realizaremos una enumeración de los recursos compartidos para que se nos genere un archivo JSON con la estructura de los archivos que se encuentran en los diferentes recursos compartidos.

Esto es bastante útil para disponer de un mapa de los recursos compartidos y así localizar de manera más eficaz aquellos archivos que sean más interesantes.

Del archivo que se nos genera a través del spider_plus, comprobaremos el contenido de este. En el resultado se nos muestra que en los recursos compartidos del DC solamente se encuentra un archivo llamado SQL Server Procedures.pdf en el recurso compartido Public.

Descargaremos este archivo a través de nxc y lo almacenaremos con el nombre SQLServerProcedures.pdf.

Information Leakage

Al visualizar el contenido del PDF descargado, se comprueba que en el apartado de Bonus se muestran credenciales de acceso a la base de datos de MSSQL.

Initial Foothold

MSSQL Enumeration

Dado que el servicio de MSSQL se encuentra expuesto por el puerto 3306, probaremos de autenticarnos con las credenciales obtenidas PublicUser/GuestUserCanWrite1.

Comprobamos el acceso al servicio y realizamos una enumeración de las bases de datos presentes, en el cual no obtenemos ninguna base de datos que podamos extraer información útil.

Attempting to enable xp_cmdshell component in MSSQL [FAILED]

Probaremos de habilitar el compontente xp_cmdshell para tratar de obtener una vía potencial de lograr ejecutar comandos arbitrarios en el sistema. En este caso, se nos muestra que no disponemos del acceso necesario para habilitar el componente y lograr obtener finalmente el RCE.

MSSQL Hash Stealing [Net-NTLMv2] (xp_dirtree)

En este punto, lo que realizaremos es intentar abusar del componente xp_dirtree para obtener un hash Net-NTLMv2 del usuario que ejecuta el servicio de MSSQL. Básicamente, lo que intentaremos realizar es que el servicio de MSSQL se intente autenticar en nuestro servidor SMB que montaremos, para así lograr obtener el hash y posteriormente intentar crackearlo.

Desde nuestro equipo montaremos un servidor SMB con impacket a través del siguiente comando.

Desde el servicio de MSSQL intentaremos listar el contenido de nuestro recurso que estamos compartiendo.

Verificamos nuevamente en nuestro servidor SMB que hemos logrado obtener un hash Net-NTLMv2 del usuario que ha intentado autenticarse a nuestro servidor. En este caso, el usuario se trata de sql_svc.

A través de hashcat logramos finalmente crackear el hash del usuario mencionado.

Validaremos a través de nxc de las credenciales obtenidas para verificar que podemos autenticarnos correctamente.

Por otro lado, probamos de verificar si teníamos capacidad de conectarnos directamente al DC a través de WinRM. En e resultado se nos muestra el mensaje como Pwn3d!, con lo cual nos confirma de que podemos conectarnos remotamente al equipo con dichas credenciales.

A través de evil-winrm comprobamos que logramos obtener acceso remoto al Domain Controller.

Initial Access

Information Leakage

Realizando una enumeración del equipo, localizamos un archivo llamado ERRORLOG.BAK localizado en C:\SQLServer\Logs. Este archivo quizás pueda tener información que nos pueda servir más adelante, por lo tanto nos lo descargaremos a través del comando download que nos proporciona evil-winrm.

Analizando el archivo ERRORLOG.BAK logramos verificar en los logs un intento de inicio de sesión del usuario Ryan.Cooper en el cual nos aparece las credenciales en texto plano de dicho usuario.

Abusing WinRM - EvilWinRM

Verificaremos de que las credenciales son válidas para el usuario mencionado y si tenemos capacidad de conectarnos al equipo. Al comprobar el acceso, nos conectaremos al DC y verificaremos la flag user.txt.

Privilege Escalation

DC Enumeration (adPEAS) - Powershell tool to automate Active Directory enumeration

Realizaremos una enumeración del AD a través de la herramienta adPEAS.ps1 que es un script de Powershell (parecido a winPEAS) pero en vez de buscar malas configuraciones de Windows, hace exactamente lo mismo pero en el entorno del AD.

Nos descargaremos el script en nuestro equipo y lo compartiremos a través de un servidor web.

Desde el DC importaremos en memoria a través de IEX el script de adPEAS.ps1 que estamos compartiendo. Una vez lo dispongamos en memoria, ejecutaremos el Invoke-adPEAS.

En el resultado obtenido, encontramos un servicio de Active Directory Certificate Services (AD CS) en el dominio.

  • Nombre de la CA: sequel-DC-CA

  • Hostname: dc.sequel.htb

  • IP: 10.10.11.202

  • Fecha de Creación: 18/11/2022

  • NTAuthCertificates: True

  • Plantillas disponibles:

    • UserAuthentication

    • DirectoryEmailReplication

    • DomainControllerAuthentication

    • KerberosAuthentication

    • EFSRecovery

    • EFS

    • DomainController

    • WebServer

    • Machine

    • User

    • SubCA

    • Administrator

Plantilla vulnerable detectada: UserAuthentication

  • Tiene el flag ENROLLEE_SUPPLIES_SUBJECT, lo que puede permitir falsificar certificados.

  • El usuario sequel\sql_svc tiene GenericAll sobre la plantilla.

  • El grupo sequel\Domain Users puede inscribirse en esta plantilla.

  • Extended Key Usage: Client Authentication, Secure Email, Encrypting File System.

Esto podría ser explotable para obtener certificados válidos en el dominio. Podemos profundizar con Certipy o Certify para ver si es viable.

Abusing Active Directory Certificate Services (ADCS)

ADCS es el rol que maneja la emisión de certificados para usuarios, equipos y servicios en la red de Active Directory. Este servicio, si está mal configurado, puede presentar vulnerabilidades que los atacantes podrían explotar para elevar privilegios o acceder a información sensible.

Algunas de las posibles vulnerabilidades que puede tener ADCS son:

  1. Delegación de privilegios en la emisión de certificados: Si ciertos usuarios tienen permisos para emitir certificados para otros, un atacante podría abusar de estos privilegios para obtener permisos elevados.

  2. Mala configuración en las plantillas de certificados: Configuraciones incorrectas en las plantillas de certificados podrían permitir que un atacante solicite un certificado en nombre de otro usuario, incluso uno con privilegios elevados.

  3. NTLM Relaying en HTTP: Si el ADCS acepta autenticación NTLM en lugar de Kerberos, un atacante podría redirigir las solicitudes para ganar acceso.

Lo primero de todo, para no tener problemas con el DC, sincronizaremos la hora de nuestro equipo con la del DC a través de ntpdate.

Ejecutamos Certipy con el usuario sql_svc para buscar plantillas vulnerables, pero no encontramos ninguna con permisos explotables. Probaremos más adelante con otro usuario para ver si hay alguna plantilla explotable.

Probamos con el usuario Ryan.Cooper y esta vez sí encontramos una plantilla vulnerable. Nos apareció la plantilla UserAuthentication, que tiene una vulnerabilidad ESC1 porque:

  • Cualquier usuario del dominio puede inscribirse.

  • El solicitante puede definir el subject, lo que nos permite suplantar identidades.

  • Soporta autenticación de cliente, lo que nos puede servir para obtener acceso.

  • Permite exportar la clave privada, lo que facilita su uso.

ESC1 exploitation case with certipy-ad

La vulnerabilidad ESC1 en ADCS permite que cualquier usuario del dominio solicite un certificado en su propio nombre y lo use para autenticarse como otro usuario con más privilegios. Esto sucede cuando una plantilla de certificados está configurada de forma insegura, permitiendo que el solicitante defina manualmente el Subject Alternative Name (SAN) y que la clave privada sea exportable. Si la plantilla también permite la autenticación de cliente, un atacante puede obtener acceso no autorizado dentro del dominio.

Al explotar ESC1, solicitamos un certificado usando la plantilla vulnerable UserAuthentication y configuramos el UPN como administrator@sequel.htb. Esto nos permite autenticar como el administrador del dominio. La solicitud fue exitosa, generando un certificado que ahora podemos usar para autenticarnos. El archivo resultante, administrator.pfx, contiene la clave privada y el certificado necesario para la autenticación.

Con el certificado generado, lo usamos para autenticarnos como Administrator en el dominio sequel.htb. Esto nos permitió obtener un TGT (Ticket Granting Ticket) almacenado en un archivo ccache (administrator.ccache). Con este ticket, podemos usar herramientas como impacket para autenticarnos realizando un Pass The Ticket (PtT). Además, conseguimos el NT hash del administrador, lo que nos abre nuevas posibilidades de explotación dentro del dominio.

A través del TGT obtenido previamente, nos conectamos usando wmiexec.py con las credenciales del usuario Administrator en el Domain Controller de sequel.htb. Utilizamos el siguiente comando para autenticar y obtener acceso.

Una vez conectado, verificamos el acceso con el comando whoami, que confirmó que estamos autenticados como sequel\administrator. Teniendo acceso al DC, finalmente logramos visualizar la flag root.txt.

Última actualización

¿Te fue útil?