Descubriendo el camino para llegar a domain admin con BloodHound

Hoy en día prácticamente todas las empresas utilizan el Directorio Activo de Microsoft para administrar los recursos, usuarios y políticas de sus redes corporativas. Por eso uno de los objetivos finales de una intrusión siempre suele ser conseguir los máximos privilegios sobre el DA. Pero también suele ser bastante común que, cuando comprometemos un servidor y nos "asomamos" a las redes internas para comenzar con los movimientos laterales, nos encontremos con una auténtica maraña de servidores, relaciones de confianza, grupos anidados, etc, etc., es decir, literalmente es fácil que nos perdamos en el bosque, nunca mejor dicho.

Para facilitarnos el entendimiento de la topología a la que nos enfrentamos y visualizar las posibles vulnerabilidades y fallos existe una herramienta que se llama BloodHound que utiliza gráficos para revelar las relaciones ocultas y, a menudo no intencionadas, dentro de un entorno de DA.

Por un lado un atacante puede usarla para identificar fácilmente rutas de ataque altamente complejas que de otro modo serían imposibles de identificar rápidamente y, por otro, un administrador podría usarla también para identificar y eliminar esos mismos caminos de ataque. En definitiva, tanto los miembros del Red Team como los del Blue Team pueden usar BloodHound para obtener una comprensión más profunda de las relaciones de privilegios en un entorno de Active Directory.


Bloodhound está desarrollado por @_wald0, @CptJesus, y @harmj0y. y básicamente es una aplicación web de JavaScript de una sola página, construida sobre Linkurious, compilada con Electron, con una base de datos Neo4j alimentada por un ingestor PowerShell. Tenéis las instrucciones de instalación en la Wiki del proyecto. En este post haremos una pequeña demo desde la perspectiva de un atacante...

Primero, para funcionar BloodHound requiere tres conjuntos de información de un entorno de Active Directory:

- ¿Quién ha iniciado sesión en dónde?
- ¿Quién tiene los derechos de administrador?
- ¿Qué usuarios y grupos pertenecen a qué grupos?
- (Opcionalmente) ¿Qué directores tienen control sobre otros objetos de usuario y grupo?

En la mayoría de los casos, la recopilación de esta información no requiere privilegios de administrador ni la ejecución de código en sistemas remotos. El primer ingestor de Bloodhound -que así es como se conoce- estaba basado en PowerView y hacía que la recopilación de datos fuera rápida y simple, e incluso teníamos la ventaja de que podíamos llamarlo directamente desde Empire (módulo Powershell/situation_awareness/network/bloodhound) o incluso desde Meterpreter importando el cmdlet (powershell_import BloodHound.ps1). Sin embargo el uso de Powershell v2 penalizaba algo la velocidad de la enumeración en grandes entornos y, sobretodo, elevaba bastante el uso de la memoria, por lo que se reescribió un nuevo ingestor en C#: SharpHound.

Supongamos que el atacante ha conseguido RCE en un servidor en la DMZ, lo normal sería que subiera los ejecutables del ingestor Sharphound para recopilar toda la información necesaria para tratarla luego con Bloodhound. Pero, ¿para qué andar subiendo archivos y dejar más rastro del necesario? Si podemos lo ideal sería averiguar cuál es el controlador de dominio y luego pivotar a través del servidor comprometido para hacer las consultas LDAP pertinentes y extraer tan valiosa información.

En el servidor comprometido:

Obtener el PDC:

nltest /dclist:dominio.inet
Obtener lista de los DC del dominio 'dominio.inet' a partir de '\\server1.dominio.inet'.
    server1.dominio.inet [PDC]  [DS] Sitio: Madrid
    server2.dominio.inet        [DS] Sitio: Paris
    server3.dominio.inet        [DS] Sitio: Roma
El comando se completó correctamente

Pivotar (ej. meterpreter):

meterpreter > portfwd add -l 389 -p 389 -r 192.168.15.10
[*] Local TCP relay created: 0.0.0.0:389 192.168.15.10:389

En la máquina del atacante:

c:\Users\user\Desktop\Post-explotacion\BloodHound-master\Ingestors>SharpHound.exe -d dominio.inet --DomainController server1.dominio.inet --ldapport 389 --ignoreldapcert
Initializing BloodHound at 23:08 on 05/07/2018
Starting Default enumeration for dominio.inet
Status: 1805 objects enumerated (+1805 28,65079/s --- Using 62 MB RAM )
Status: 1817 objects enumerated (+12 19,53763/s --- Using 62 MB RAM )
Status: 1819 objects enumerated (+2 14,78862/s --- Using 62 MB RAM )
...
Status: 3133 objects enumerated (+1 4,957278/s --- Using 49 MB RAM )
Finished enumeration for dominio.inet in 00:10:32.1862701
878 hosts failed ping. 2 hosts timedout.

Removed 10 duplicate lines from .\group_membership.csv
Removed 66 duplicate lines from .\sessions.csv


Como veis, el resultado son dos ficheros .csv, uno con los grupos del dominio y su membresía y otro con las sesiones iniciadas a lo largo del mismo. Por defecto según la documentación si no se indica ningún método de recolección debería haber sacado además los grupos locales del equipo y las relaciones de confianza.

Puede ser lógico que habiendo indicado el dominio como parámetro no sacara los grupos locales, pero las relaciones de confianza si que las deberíamos tener, así que volvemos a ejecutar el comando indicando ese método de recolección:

c:\Users\user\Desktop\Post-explotacion\BloodHound-master\Ingestors>SharpHound.exe -d dominio.inet --DomainController server1.dominio.inet --ldapport 389 --ignoreldapcert --CollectionMethod Trusts
Initializing BloodHound at 13:48 on 05/07/2018
Starting Trusts enumeration for dominio.inet
Finished enumeration for dominio.inet in 00:00:00.4490726

Removed 1 duplicate lines from .\trusts.csv

c:\Users\user\Desktop\Post-explotacion\BloodHound-master\Ingestors>type trusts.csv
SourceDomain,TargetDomain,TrustDirection,TrustType,Transitive
dominio.inet,dominio2.inet,Bidirectional,External,True

 
Como podeis comprobar, existe otro domimio y una relación bidireccional con el mismo.

Tenéis todas las opciones posibles de enumeración en el README del ingestor (https://github.com/BloodHoundAD/SharpHound). Mi consejo es que extraigáis todo lo posible para cargarlo posteriormente y verlo con Bloodhound. Una vez con los ficheros csv en nuestro poder, configuraremos un base de datos en blanco en Neo4j antes de iniciarlo:

,/conf/neo4j.conf

#*****************************************************************
# Neo4j configuration
#
# For more details and a complete list of settings, please see
# https://neo4j.com/docs/operations-manual/current/reference/configuration-settings/
#*****************************************************************

# The name of the database to mount
#dbms.active_database=graph.db
#dbms.active_database=BloodHoundExampleDB.graphdb
dbms.active_database=nueva.graphdb
...


Luego ejecutaremos el cliente de Bloodhound y en el menú de la derecha, en "Upload Data", subiremos los ficheros:



Una vez con los datos cargados ya podemos visualizar los resultados de todas las queries predefinidas o las personalizadas que creemos y, sobretodo, indicar el nodo de inicio y el objetivo final para descubrir posibles fallos en las ACLs que nos lleven al camino hacia el administrador de dominio o admin path!


Proyectos:
- https://github.com/BloodHoundAD/BloodHound
- https://github.com/BloodHoundAD/SharpHound
 
Referencias:
- My First Go with BloodHound
- Lay of the Land with BloodHound
- Attacking Active Directory Permissions with BloodHound
- Attack Mapping with BloodHound
- Active Directory Risk Auditing with BloodHound
- How the BloodHound tool can improve Active Directory security
- SharpHound: Evolution of the BloodHound Ingestor
- Introducing the Adversary Resilience Methodology — Part One
- Introducing the Adversary Resilience Methodology — Part Two
- A Guide to Attacking Domain Trusts

Comentarios

Publicar un comentario