Support
Platform
HackTheBox
O.S
Windows
Level
Easy / Medium
Skills
WireShark
LDAP enumeration
BloodHound
RBCD
Fase 1: Reconocimiento
Escaneo inicial a todos los puertos TCP de la máquina.
sudo nmap -sS -p- --open --min-rate 3000 --max-retries 3 -n -Pn -v 10.10.11.174 -oN target
Escaneo profundo a todos los puertos comunes descubiertos anteriormente.
Primero que nada obtengo toda la información sobre el dominio y el nombre de equipo que pueda otorgar Crackmapexec a través de SMB para luego añadirlo al fichero /etc/hosts, con el objetivo de que nuestra máquina Kali pueda resolver mediante DNS sin problema.
Nombre de equipo: DC
Nombre de dominio: support.htb
FQDN: dc.support.htb
Procedemos a descubrir que permisos tenemos sobre los shares SMB.
smbmap -H 10.10.11.174 -u 'null'
Al ver que tenemos permisos de lectura sobre el share support-tools, me conecto con smbclient y analizo el contenido.
Al observar un poco por encima puedo notar de que la mayoría de programa corresponden a software comúnmente utilizado; el único archivo ‘interesante’ es el llamado UserInfo.exe.zip, así que lo instalamos en local para su posterior análisis.
Fase 2: Explotación
Al descomprimir el zip, vemos que existe un ejecutable de Windows y varias librerías.
Para probar a ejecutar el archivo y saber que hace internamente lo podemos hacer desde un Windows (pasando el binario a local o a una VM) o bien podemos usar la herramienta wine que es lo que yo haré.
Antes que nada, dejo por aquí una breve guía sobre como instalar y configurar wine :)
# Instalacion
sudo apt install wine
# adds support for the i386 (32-bit) arc on a 64-bit system
sudo dpkg --add-architecture i386
# Instalacion wine32
sudo apt install wine32:i386
# Reiniciar entorno wine
WINEPREFIX=~/.wine winebootA continuación, lo que normalmente haríamos sería ejecutar el binario deseado utilizando el comando wine. Sin embargo, en este caso concreto, el binario ha sido desarrollado con el framework .NET.
¿Cuál es el problema? Que los ejecutables .NET requieren tener el entorno de ejecución de .NET instalado, y wine, por defecto, no incluye soporte nativo para .NET. Por tanto, no podremos ejecutarlo directamente sin antes instalar el framework correspondiente dentro del entorno de wine
La solución es instalar la implementación del Framework para wine, llamada wine Mono.
Para ello nos vamos al siguiente enlace: https://dl.winehq.org/wine/wine-mono/ e instalamos el MSI a nuestra máquina local.
Lo ejecutamos con el siguiente comando:
wine msiexec /i archivo_instalado.msiY por último creamos un entorno limpio de 32 bits y reiniciamos wine.
# Creación de un entorno limpio de 32 bits
rm -rf ~/.wine
WINEARCH=win32 WINEPREFIX=~/.wine winebootY ahora si podemos ejecutar nuestro binario sospechoso.
Luego de probar un rato a ejecutarlo con las opciones dadas, nos damos cuenta que al parecer está ejecutando algún tipo de consulta en el dominio relacionada a los usuarios.
Para corroborar esto, usaremos un descompilador de archivos .NET muy conocida llamada ILSPY 😏.
¿Qué hace exactamente la herramienta?
Toma un archivo compilado en .NET, como un .exe o dll.
Extrae el IL (Intermediate Language), que es el código intermedio generado por el compilador de .NET.
Lo descompila a un código fuente en C# legible.
Dejo el repositorio oficial de su versión multiplataforma:
Una vez instalada la versión de Linux nos movemos al directorio artifacts → linux-x64
Luego ejecutamos:
sudo ./ILSpyAbrimos el fichero:
Ok, viendo el código se concluye que para encontrar algún usuario del dominio u obtener información relacionada se realiza una query LDAP.
Perfecto, al hacer una query LDAP sin protección SSL podemos analizar el tráfico y capturar el paquete con el cual se realiza la acción.
Ejecutamos la acción que realiza la query LDAP y capturamos el tráfico de la interfaz de la VPN con WireShark.
Bingo! 😏
En el paquete del Request LDAP logramos capturar el usuario que hace la consulta y la contraseña asociada. Esto es posible gracias a que no se usa LDAP sobre SSL (puerto 636) y a que la autenticación se realiza por el método simple, el cual se hace mediante nombre de usuario y contraseña.
Comprobamos si el usuario obtenido es válido a nivel de dominio.
De locos! y a ver si tenemos suerte y también pertenece al grupo de Remote Management y podemos acceder a la máquina por WinRM.
Mmm vale no ha habido suerte, pero aún así, TENEMOS UN USUARIO VÁLIDO A NIVEL DE DOMINIO, vamos a ver que cosas interesantes podemos hacer ahora. 😈
Lo primero es conectarnos a través de LDAP para observar más información y sacar más datos relevantes sobre el dominio.
Para ello he utilizado la herramienta jxplorer, la cual es bastante intuitiva y la manera en la que organiza la información está bastante bien.
Después de estar un rato analizando, he encontrado que en el usuario support, existía en el campo info lo que parece ser una contraseña en texto plano.
Vamos a comprobarlo directamente a ver si pertenece a un grupo de administración remota, ya que si fuera otro usuario del dominio sin nada interesante estaríamos en la misma situación.
Perfecto, tenemos acceso por WinRM. 🫡
La flag del usuario se encuentra en su Desktop.
Fase 3: Escalada de Privilegios
Al ver los grupos a los que pertenece el usuario, nos damos cuenta que hay uno un tanto interesante:
Para comprobar si este grupo tiene alguna relación con un recurso de admin o si es un posible vector de ataque, usaremos BloodHound.
En mi caso usaré la versión pre copilada disponible en GitHub:
Antes de usar BloodHound necesitamos extraer toda la información que la herramienta va a analizar en un archivo bien sea .zip o .json; en este caso lo haré en un .zip ya que es la forma en la que lo hace SharpHound, que es la herramienta que utilizaré para esta tarea.
Luego de obtener la información del dominio necesaria con SharpHound, la descargamos a la máquina local para posteriormente subirla a BloodHound
Vale, antes que nada dejo una breve guía de instalación de BloodHound del binario pre compilado, el cual será más que suficiente para la tarea que deseamos realizar.
Vamos al siguiente enlace de GitHub, descargamos el binario y lo descomprimimos.
# Instalamos la db necesaria para el funcionamiento de bloodhound
sudo apt install neo4j
# La inicializamos
sudo neo4j start
# Entramos a la URL proporcionada y entramos con las creds
neo4j:neo4j
# Generamos una nueva contraseña
# Ejecutamos el binario instalado previamente de GitHub
./Bloodhound --no-sandbox
# Entramos con las credenciales configuradas anteriormenteBien, una vez hemos cargado BloodHound y hemos subido el archivo generado en pasos previos con SharpHound, vamos a analizar el grupo que hemos catalogado como interesante.
Encontramos que contiene permisos GenericAll sobre el ordenador del dominio objetivo...
Vamos a ver que riesgos implica esto en cuestiones de escalada de privilegios.
Bien, al parece encontramos que es vulnerable a un ataque Resource Based Constrained Delegation Attack.
Hay una variante moderna de la delegación restringida que permite delegar a través del atributo msDS-AllowedToActOnBehalfOfOtherIdentity.
Este es usado cuando el usuario NO ha hecho login aún, pero otro equipo lo quiere suplantar ante un servicio.
Si podemos modificar ese atributo en un equipo objetivo, le estaríamos diciendo al AD:
“Este equipo que controlo está autorizado para actuar en nombre de cualquier usuario”.
Una vez lo tenemos más o menos claro, vamos a ver este concepto aplicado a la práctica.
Tener en cuenta que existen varias formas de explotar esta vulnerabilidad y algunas de ellas las describe el propio BloodHound.
De todas formas dejo por aquí un enlace a un artículo bastante completo sobre este ataque por si quieren entender un poco mejor este caso.
En mi caso estaré realizando el ataque con librerías de Impacket ya que me resulta más cómodo, vamos allá 😈
El primer paso va a ser añadir una máquina nueva al dominio para poder posteriormente configurarle el atributo msDS-AllowedToActOnBehalfOfOtherIdentity apuntando a la máquina víctima con el objetivo de suplantar al usuario administrador de ese PC.
Lo siguiente será configurar el atributo de delegación en el equipo víctima, para que nuestro equipo (pcjuan) pueda actuar en su nombre.
Esto escribe directamente el valor del atributo msDS-AllowedToActOnBehalfOtherIdentity en el objeto DC$, para permitir que pcjuan$ delegue sobre el.
Por último, obtenemos un TGS válido para el servicio CIFS del DC, utilizando la cuenta de máquina maliciosa (controlada por nosotros), la cual tiene derechos delegados sobre el DC mediante RBCD, impersonando al usuario Administrator.
Antes de conectarnos a la máquina a través de una autenticación kerberos, especificamos en la variable KRB5CCNAME, cual es el fichero de caché del ticket de kerberos que debe usar nuestro psexec.
export KRB5CCNAME=Administrator@cifs_dc.support.htb@SUPPORT.HTB.ccachebashPor último nos conectamos a la máquina sin especificar contraseña y haciendo uso de la autenticación kerberos.
La flag del root se encuentra en el Desktop del usuario suplantado. (Si, esta vez he dejado la flag en texto plano sin censura 😅).
Last updated