Monteverde
Platform
HackTheBox
O.S
Windows
Level
Medium
Skills
Weak static credentials LDAP Enumeration
Azure AD
Fase 1: Reconocimiento
Para comenzar la fase de reconocimiento ante cualquier equipo, el primer método que suelo utilizar es una enumeración de todos los puertos TCP que la máquina víctima tenga abiertos, para así detectar servicios y posibles vectores de ataque.
sudo nmap -sS -p- --open --min-rate 5000 -n -Pn -vv 10.10.10.172 -oN target
Una vez concluida la enumeración general sobre todos los puertos abiertos TCP de la máquina, realizo un escaneo que me permita detectar versiones de los servicios que están activos (-sV) y lanzar scripts de nmap por defecto para intentar obtener información extra de cada protocolo (-sC).
nmap -p88,135,389,445,5985 -sCV 10.10.10.172 -oN ports88: Kerberos
135: RPC
389: LDAP
445: SMB
5985: WinRM
Y como último método de enumeración he decidido utilizar la herramienta Crackmapexec para descubrir de manera rápida, el nombre de dominio y el nombre del host.
Luego de esto, añado tanto el nombre del host, el nombre de dominio como el FQDN al fichero de DNS (/etc/hosts) para que así, mi máquina local no tenga problemas al intentar resolver la IP de la máquina.
Fase 2: Explotación
Una vez tengo una idea general de a que me estoy enfrentando, lo que hago es intentar enumerar recursos compartidos SMB que la máquina me pueda permitir ver de manera anónima, utilizando herramientas como Smbclient, Smbmap o el propio Crackmapexec, todos estos métodos sin éxito.
Así que lo siguiente que se me ocurre es comprobar si puedo iniciar sesión en el dominio a través de LDAP de forma anónima.
Para ello utilizo la herramienta ldapsearch e intento realizar una enumeración de todos los objetos del dominio sin especificar ni usuario (-D) ni contraseña (-w)
Verifico que la operación ha sido exitosa y se ha recuperado toda la información relacionada con el dominio.
En este punto, existen dos opciones claras. La primera consiste en guardar toda la salida en un archivo para comenzar a filtrar utilizando herramientas como grep, aprovechando parámetros como -C, -A, -B, entre otros. Esto permite identificar patrones relevantes y, posteriormente, realizar búsquedas más específicas utilizando ldapsearch.
O la otra opción es simplemente conectarnos a través de LDAP con ayuda de una herramienta que enseña la información de una manera más amigable.
En mi caso opto por la segunda y la herramienta que usaré para ello será jxplorer, la cual se puede instalar directamente desde los repositorios oficiales de Kali Linux.
Ok, una vez dentro, recomiendo poner la vista en Table Editor, ya que es mucho más cómoda a la vista.
Tras un tiempo de análisis, he conseguido extraer los siguientes usuarios:
Procedo a anotarlos en una lista y al ver que hay algún que otro nombre un tanto extraño, decido realizar una prueba de credenciales para comprobar que no estuviera ninguna contraseña oculta entre los usuarios.
crackmapexec smb 10.10.10.172 -u users.txt -p users.txt
He de admitir que mis principales sospechas rondaban en torno al usuario AAD_987d7f2f57d2, pero bueno, si HackTheBox dice que era el usuario de los jobs, quien soy yo para decir algo... 🙂↕️
Obtenido el usuario lo primero que hago es comprobar si pertenece al grupo de administración remota pero aún no hay suerte.
Así que ahora si que si me dedico a enumerar los shares SMB con credenciales válidas.
Bien, el primer share que se me hace agua la boca agua visitar es el de los usuarios, vamos a ver que se encuentra por allí 👀.
En el directorio del usuario mhope había un fichero llamado azure.xml, el cual he decidido descargarme para analizarlo mejor desde mi máquina local.
Una vez abierto con un editor de código, se puede apreciar una contraseña en texto plano 🫣.
Bien, procedo a comprobar si la contraseña es válida para el usuario mhope, y al mismo tiempo intento acceder mediante WinRM utilizando sus credenciales de dominio.
Perfecto!
La flag se encuentra en el Desktop del usuario obtenido.
Fase 3: Post-Explotación
Al empezar con esta fase, lo primero que suelo hacer es una enumeración manual sobre mi usuario, los privilegios a los que pertenezco, los grupos asociados, etc.
Dejo por aquí algunos de los comandos que suelo ejecutar por si a alguien le son de utilidad.
# Mostrar los privilegios asociados al usuario actual y grupos
whoami /priv | whoami /groups
# Ver ficheros ocultos
dir -Force
# Ver los usuarios del sistema y ver su info
net users
net user nombre_usuario
# Ver usuarios que pertenecen al grupo local de administradores
net localgroup administrators
# Ver variables de entorno definidas
Get-ChildItem env:
# Ver permisos archivos sospechosos
icacls archivo_objetivo
# Ver historial en sistemas con PSReadline
cat $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txtBien, con solo ver los grupos a los que pertenece mi usuario, me doy cuenta que pertenezco a uno de administradores Azure 😲.
Por lo cual, tras investigar durante un tiempo, concluí que el entorno está utilizando Azure AD.
¿Qué es Azure AD?
Se encarga de sincronizar datos de usuarios y del dominio del AD on-premise a la nube Azure.
Por cierto, en mi investigación he dado con el perfil de XPN y me ha dejado un poco loco los grandiosos artículos que tiene y su perfil como Red Teamer en general, dejo por aquí abajo los links:
Link a su web: https://blog.xpnsec.com/about
Link al artículo relacionado con el tema: https://blog.xpnsec.com/azuread-connect-for-redteam/
Bien, una vez comprendido que es este servicio, podemos plantearnos otra cuestión.
¿Cómo funciona en realidad Azure AD?
Para llevar a cabo la sincronización, Azure AD Connect utiliza credenciales con permisos elevados que le permiten acceder, leer y transferir información del dominio local. Estas credenciales se almacenan cifradas en el propio servidor donde se ejecuta el servicio, y son utilizadas por el sistema de forma transparente durante el proceso de sincronización.
Ok, pues si las credenciales privilegiadas se encuentran en local, ¿No habrá alguna forma de extraerlas sabiendo que soy administrador del servicio que se encarga de realizar este proceso?
La respuesta es que sí, existe un script llamado AdSyncDecrypt que permite:
Localizar la base de datos local que usa Azure AD Connect.
Obtener los valores cifrados de credenciales de sincronización.
Para posteriormente usar una dll de Microsoft para descifrar esos datos aprovechando el mismo mecanismo que usa el servicio.
Y por último recuperar el usuario y contraseña en texto plano usados para sincronizar con Azure AD.
El link de descarga del script es el siguiente:
Una vez instalado el zip, lo descomprimimos y pasamos tanto el ejecutable, como la librería DLL a la máquina víctima.
Antes de ejecutar el script, tenemos que encontrarnos en la ruta:
C:\program files\Microsoft Azure AD Sync\bin
Y desde ahí lanzo el script con la opción -FullSQL para que la instalación de Azure AD Connect utilice una instancia completa de SQL Server (en lugar de la versión reducida, localDB) y así evitar problemas al ejecutar.
Una vez obtengo las credenciales, solo quedaría realizar un login por WinRM y obtener la flag 😉.
Last updated