Forest
Platform
HackTheBox
O.S
Windows
Level
Easy
Skills
AS-REP Roasting
LDAP enumeration
WriteDACL
Fase 1: Reconocimiento
Escaneo inicial de todos los puertos de la máquina objetivo.
nmap -sS -p- --open -n -Pn -vvv 10.10.10.161 -oN target 
Una vez escaneados los puertos abiertos, haré un escaneo de versiones (-sV) y un lanzamiento de scripts automáticos para cada puerto (-sC).
nmap -sCV -p88,135,389,445,5985 10.10.10.161 -oN ports
Al no ver nada relevante, decido obtener más información básica acerca de la máquina objetivo: su nombre, nombre del dominio (si pertenece a uno), etc. Así que con ayuda de crackmapexec realizo una enumeración básica a través del protocolo SMB.
crackmapexec smb 10.10.10.161
Al obtener estos valores, decido añadir el nombre del host, el nombre del dominio y el FQDN (nombre_host.nombre_dominio) a mi fichero DNS (/etc/hosts), para que así resuelva estos nombres sin ningún inconveniente.
Lo siguiente que intento es observar si el host tenía la enumeración de shares habilitada, así no dispusiera de un usuario válido del dominio. Ya les adelanto que sin éxito.
Así que se me ocurre realizar una enumeración de objetos a través de LDAP, con la esperanza de que tuviera habilitado el acceso anónimo.
Efectivamente, sin proporcionar credenciales válidas, me ha dejado listar todos los objetos del dominio.
Mi objetivo con esto es sacar principalmente nombres de usuarios válidos e incluso, si existe, información adicional de cada usuario.
Para realizar esta tarea de manera más amena hago uso de jxplorer.
Una vez conectado procedo a buscar usuarios y anotarlos todos en un fichero que ya usaré posteriormente para diversas acciones 😏.
Tener en cuenta que los nombres de usuarios que debemos guardar, son los que salen en el UserPrincipalName, ya que ese es el nombre con el cual se autentican contra el dominio.
Fase 2: Explotación
Al tener una lista de usuarios válidos a nivel de dominio y al estar el puerto 88 abierto, me hace pensar que la autenticación interna seguramente se esté realizando a través de Kerberos (digo pensar como si fuera algo difícil, cuando esta autenticación es la más típica y lógica en entornos AD 😆).
Vale, ya sin bromas malas, en el proceso de autenticación kerberos se pueden producir varios ataques y uno de ellos es el AS-REP Roasting.
Bien, pues existen algunos usuarios configurados en el AD que tienen la preautenticación deshabilitada, esto significa que el KDC no requiere que estos usuarios firmen su solicitud AS-REQ con su contraseña (usando un timestamp cifrado), lo que permite que un atacante (yo 😆) pueda solicitar un AS-REP cifrado sin conocer la contraseña del usuario (que es nuestro caso).
Para simular este paso, existe una librería de impacket que nos automatiza el proceso y hace la petición al KDC por nosotros. Esta se llama GetNPUsers, vamos a ver como funciona en la práctica:
Para el uso simplemente tenemos que poner los parámetros vistos en el pantallazo anterior. Los últimos 2 son opcionales, aunque es recomendable especificar un formato que luego reconozca alguna herramienta de cracking offline (en este caso john, aunque ese mismo formato sirve también para hashcat) y además es cómodo almacenar el o los hashes encontrados en un fichero de salida en vez de simplemente mostrarlo por pantalla.
Ok, pues comprobamos que la cuenta del usuario svc-alfresco no requiere una preautenticación kerberos y por lo tanto nos ha respondido el KDC a nuestro AS-REQ con la clave de sesión cifrada con el hash de la contraseña del usuario.
También pueden existir más causas como que estas cuentas se usen para tareas automáticas y para evitarse dolores de cabeza con el timestamp de Kerberos, los admins suelen desactivar esta función.
Volviendo al proceso, voy a crackear el trozo encriptado que hemos logrado capturar.
Para ello usaré hashcat.
El modo 18200 lo podemos encontrar en la web oficial de los ejemplos de hashcat:
hashcat -a 0 -m 18200 hash.hash /usr/share/wordlists/rockyou.txt --status --status-timer 8
Observo que se ha crackeado con éxito y que la contraseña del usuario svc-alfresco es ‘s3rvice’.
Compruebo si esta credencial es válida para realizar una conexión remota por winrm.
crackmapexec winrm 10.10.10.161 -u 'svc-alfresco' -p 's3rvice'
Perfecto!
Me conecto desde mi kali con ayuda de Evil-Winrm y extraigo la flag del usuario, situada en su desktop.
Fase 3: Post-Explotación
Lo primero que realizo es una enumeración de los grupos de los cuales forma parte mi usuario actual.
Puedo observar que existen unos cuantos grupos que no son los por defecto...
Así que, sin perder mucho tiempo realizo una extracción de toda la información del dominio con Bloodhound-Python, para posteriormente analizarla detenidamente con Bloodhound y descubrir si estos grupos a los que pertenece mi usuario poseen alguna posible ruta de escalada.
La instalación de la herramienta de extracción utilizada es la siguiente:
# Creación de entorno virtual con python para que no cause problemas con más dependencias
python3 -m venv nombre_entorno
# Activación del entorno
source nombre_entorno/bin/activate
# Instalación del recolector de bloohound para python
pip install bloodhound
Recolectada la información, procedo a subir el zip que me ha generado mi herramienta a Bloodhound.
Bueeeeno, al analizar el grupo ‘Account operators’ puedo ver que posee control total del grupo ‘Exchange Windows Permissions’ que, a su vez, tiene la ACE ‘WriteDacl’ sobre el dominio.
Bien, resumiendo esto, mi usuario posee la capacidad de leer y modificar las ACEs dentro de las DACL del dominio, es decir que me puedo otorgar permisos interesantes 😏.
Para empezar con la explotación de esa ACE vulnerable, tengo que formar parte del grupo ‘Exchange Windows Permissions’. Al tener control total sobre este grupo, pues simplemente agrego mi usuario a este grupo 😆.
Tener en cuenta que para realizar esta acción, he decidido hacerlo desde una consola PowerShell.
Puedes invocar una en kali, simplemente con el comando pwsh. 😉
Ok, al pertenecer al grupo que quería desde un principio, puedo ahora agregar la ACE que yo quiera.
En este caso, he optado por otorgarme permisos DCSync, para así poder actual como otro domain controller y poder leer información sensible del sistema (hashes de usuarios).
Para realizar esta tarea, decido utilizar la librería dacledit de impacket, ya que me parece súper cómoda.
El comando leído, significa lo siguiente:
Estoy creando una ACE (-action write), que le conceda permisos DCSync (-rights DCSync) al usuario svc-alfresco (-principal svc-alfresco) y que esta modificación la haga en la DACL del dominio en general, representado el objeto con el distinguishedname (-target-dn ‘DC=htb,DC=local’). Y por último que esta acción la realice el usuario svc-alfresco, el cual es el que posee la ACE ‘WriteDACL’ sobre este objeto (el dominio).
Al tener permisos DCSync, solo queda volcar los secretos del DC.
Y al ver tener en mi mano el hash NTLM del administrador, solo me queda realizar un PtH y conectarme a la máquina como admin.
La flag del root se encuentra en el desktop.
Last updated