Blog Análisis

BloodHound MCP: análisis de Active Directory con IA y lenguaje natural

Cómo BloodHound MCP conecta Claude Desktop con Neo4j para auditar AD sin escribir Cypher

📅 Publicado: 18 jun 2026
🔄 Actualizado: 18 jun 2026
👤 Por: jaivic villegas
🔗 Fuente: original
📌 Última revisión: 18 jun 2026
📋 Contenido
  1. Qué es BloodHound MCP y cómo encaja en el flujo de auditoría AD
  2. Qué primitivas peligrosas detecta BloodHound MCP en un dominio real
  3. Qué cambia para tu SOC y equipo de identidad
  4. Mitigaciones priorizadas: por dónde empezar después de una auditoría BloodHound
  5. Uso responsable: lo que BloodHound MCP no cambia en términos legales
  6. Preguntas frecuentes

BloodHound MCP es un servidor que expone el grafo Neo4j de BloodHound Community Edition al Model Context Protocol (MCP), permitiendo que Claude Desktop traduzca peticiones en lenguaje natural a consultas REST contra la API de BloodHound. El resultado práctico: un analista puede pedir «muéstrame todas las cuentas Kerberoasteables» o «¿qué caminos llegan más rápido a Domain Admin?» sin escribir una sola línea de Cypher. Según el artículo técnico publicado por Hacking Articles el 19 de junio de 2026 (fuente), el flujo cubre desde la instalación del servidor hasta la generación de un mapa priorizado de superficie de ataque con mitigaciones, todo ejecutado contra el dominio de laboratorio IGNITE.LOCAL. Para equipos de red team y pentesters que ya usan BloodHound, esto reduce drásticamente el tiempo entre la ingesta de datos y la identificación de primitivas peligrosas.

Qué es BloodHound MCP y cómo encaja en el flujo de auditoría AD

BloodHound almacena las relaciones de Active Directory como un grafo dirigido en Neo4j. Normalmente, los analistas exploran ese grafo a través de la interfaz web de BloodHound o escribiendo consultas Cypher manualmente, lo que requiere conocer la sintaxis del lenguaje de grafos y la estructura interna del modelo de datos.

bloodhound_mcp elimina esa fricción. El servidor clona desde github.com/mwnickerson/bloodhound_mcp, se instala con el gestor de paquetes uv (que genera un entorno CPython 3.11.15 con 55 dependencias en un solo paso con uv sync), y se autentica contra la API REST de BloodHound mediante un token generado desde el panel de administración, no mediante la sesión web. Ese token se almacena en un fichero .env con cinco variables:

BLOODHOUND_DOMAIN=localhost
BLOODHOUND_TOKEN_ID=<id>
BLOODHOUND_TOKEN_KEY=<key>
BLOODHOUND_PORT=8080
BLOODHOUND_SCHEME=http

Una vez registrado en Claude Desktop a través del fichero claude_desktop_config.json, el asistente carga el servidor al arrancar y puede llamar a sus herramientas en cada conversación:

{
  "mcpServers": {
    "bloodhound_mcp": {
      "command": "uv",
      "args": ["--directory", "/home/kali/bloodhound_mcp", "run", "main.py"]
    }
  }
}

El flujo completo es: recolección con bloodhound-python → ingesta en BloodHound CE → consulta en lenguaje natural a través de Claude. La recolección sobre IGNITE.LOCAL con el flag -c All extrajo 3 equipos, 24 usuarios, 53 grupos, 3 GPOs, 2 OUs y 19 contenedores en ficheros JSON que BloodHound ingiere como trabajo de importación (job ID 62 en el laboratorio documentado).

Desde el punto de vista arquitectónico, MCP actúa como capa de traducción: Claude recibe el prompt en lenguaje natural, lo convierte en una llamada al servidor bloodhound_mcp, que a su vez ejecuta la consulta REST correspondiente y devuelve datos estructurados. El analista nunca toca Cypher directamente.

Qué primitivas peligrosas detecta BloodHound MCP en un dominio real

El artículo documenta la detección de más de una docena de primitivas de ataque distintas sobre IGNITE.LOCAL, todas consultadas mediante prompts en lenguaje natural. Conviene agruparlas por categoría de riesgo:

Ataques de credenciales offline

  • Kerberoasting: cuentas con SPN configurado cuyos tickets TGS pueden crackearse sin interacción con el DC. BloodHound MCP las enumera directamente.
  • AS-REP Roasting: cuentas con DONT_REQUIRE_PREAUTH activo, que permiten solicitar un AS-REP cifrado con la contraseña del usuario sin autenticarse previamente.
  • Cuentas sin contraseña requerida: objetos con el atributo PASSWD_NOTREQD, frecuentemente olvidados en dominios legacy.

Control de objetos y ACLs

  • DCSync: identifica qué principales tienen los derechos DS-Replication-Get-Changes y DS-Replication-Get-Changes-All sobre el dominio, suficientes para volcar todos los hashes NTLM con herramientas como Impacket.
  • ForceChangePassword: edges que permiten a un principal cambiar la contraseña de otro sin conocer la actual.
  • AllExtendedRights + LAPS: combinación que permite leer la contraseña de administrador local gestionada por LAPS desde el atributo ms-Mcs-AdmPwd.
  • GenericAll sobre Tier Zero: control total sobre objetos de alto valor (Domain Admins, Domain Controllers).
  • Shadow Credentials vía AddKeyCredentialLink: permite añadir una clave pública al atributo msDS-KeyCredentialLink de una cuenta y autenticarse como ella mediante PKINIT sin conocer su contraseña.
  • AdminSDHolder backdoor: ACEs persistentes en el objeto AdminSDHolder que SDProp propaga automáticamente a todos los grupos protegidos cada 60 minutos, manteniendo acceso aunque se limpien los grupos.

Delegación de Kerberos

  • Unconstrained Delegation: equipos o cuentas de servicio que almacenan TGTs de cualquier usuario que se autentique contra ellos, incluyendo Domain Admins.
  • Constrained Delegation: permite impersonar usuarios hacia servicios específicos; combinada con S4U2Self puede escalar privilegios.
  • Resource-Based Constrained Delegation (RBCD): el objeto destino controla quién puede delegarle; si un atacante puede escribir msDS-AllowedToActOnBehalfOfOtherIdentity, obtiene impersonación.

Abuso de GPOs y grupos

  • GPO Abuse: GPOs sobre las que un principal tiene GenericWrite o AllExtendedRights, permitiendo modificar políticas que se aplican a equipos o usuarios del dominio.
  • Self-adding to Backup Operators: edges que permiten a un principal añadirse a sí mismo a grupos privilegiados como Backup Operators, que tienen acceso de lectura al registro del sistema y pueden extraer hashes del SAM.

Toda esta información emerge de prompts simples como «hunt for DCSync rights» o «find AS-REP roastable accounts», sin que el analista tenga que recordar la sintaxis Cypher de cada consulta. Eso democratiza el acceso a BloodHound para analistas que no son expertos en grafos, aunque también implica que la barrera de entrada para realizar este tipo de análisis baja considerablemente.

Qué cambia para tu SOC y equipo de identidad

La aparición de herramientas como BloodHound MCP tiene dos lecturas defensivas que conviene separar.

Primera lectura: los atacantes también tienen acceso a esta tecnología. Un operador de red team o un actor malicioso con acceso inicial a un dominio puede instalar bloodhound-python con credenciales robadas, ingestar el grafo y usar un LLM para priorizar rutas de ataque en minutos. El tiempo entre compromiso inicial y escalada a Domain Admin se comprime. Los equipos de detección deben asumir que la enumeración LDAP masiva (-c All) dejará trazas: eventos 4662 en el DC (acceso a atributos de directorio), tráfico LDAP anómalo en volumen, y conexiones al puerto 389/636 desde estaciones de trabajo que normalmente no hacen consultas de directorio.

Segunda lectura: los defensores ganan la misma velocidad. Un analista de identidad puede auditar un dominio completo en una sesión de trabajo, identificar las 30 primitivas más críticas y generar un informe priorizado sin necesidad de ser experto en Cypher ni en la taxonomía interna de BloodHound. Esto es especialmente valioso en organizaciones donde el equipo de IAM y el de seguridad son grupos distintos con distintos niveles de madurez técnica.

Qué monitorizar concretamente:

  • Eventos 4662 con Properties: {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (replicación de directorio) generados desde cuentas que no son DCs → posible DCSync.
  • Modificaciones al atributo msDS-KeyCredentialLink fuera de flujos de Windows Hello for Business → Shadow Credentials.
  • Cambios en msDS-AllowedToActOnBehalfOfOtherIdentity → RBCD.
  • Escrituras en el objeto CN=AdminSDHolder,CN=System → backdoor persistente.
  • Consultas LDAP masivas con filtros como (servicePrincipalName=*) desde hosts no autorizados → enumeración Kerberoasting.

Herramientas como Wazuh pueden correlacionar estos eventos de Windows Security Log con alertas de integridad de objetos AD si se configura la auditoría de directorio correctamente. Para la gestión de acceso privilegiado y la revisión de delegaciones, Teleport ofrece contexto adicional sobre qué sesiones privilegiadas se han abierto y desde dónde.

El laboratorio documentado en el artículo usa un entorno aislado en VMware, lo que es la práctica correcta. Ejecutar bloodhound-python contra un dominio de producción sin autorización explícita constituye acceso no autorizado independientemente de las credenciales utilizadas.

Mitigaciones priorizadas: por dónde empezar después de una auditoría BloodHound

El artículo menciona una sección de mitigaciones sin detallarlas exhaustivamente en el fragmento disponible, pero las primitivas documentadas tienen contramedidas bien establecidas que conviene ordenar por impacto.

Tier 0: acción inmediata

  1. DCSync: revisar con BloodHound (o con el prompt equivalente en MCP) qué cuentas tienen derechos de replicación. Solo los DCs deben tenerlos. Revocar cualquier ACE adicional en el objeto de dominio.
  2. AdminSDHolder backdoor: auditar las ACEs del objeto CN=AdminSDHolder,CN=System,DC=dominio,DC=local y eliminar cualquier entrada que no sea la ACL por defecto. SDProp las propagará automáticamente a los grupos protegidos en el siguiente ciclo (máximo 60 minutos).
  3. GenericAll sobre Tier Zero: identificar y eliminar delegaciones excesivas sobre Domain Admins, Domain Controllers y el propio objeto de dominio.

Tier 1: alta prioridad

  1. Kerberoasting: migrar cuentas de servicio con SPN a Group Managed Service Accounts (gMSA), que rotan contraseñas automáticamente con 120 caracteres aleatorios, haciendo el crackeo offline inviable en la práctica.
  2. AS-REP Roasting: habilitar la preautenticación Kerberos en todas las cuentas. El atributo DONT_REQUIRE_PREAUTH solo debe estar activo si hay una razón técnica documentada.
  3. Shadow Credentials: proteger el atributo msDS-KeyCredentialLink con ACLs restrictivas. Si no se usa Windows Hello for Business ni FIDO2 en el dominio, considerar bloquear escrituras en ese atributo a nivel de ACL.
  4. Unconstrained Delegation: eliminarla de todos los equipos que no sean DCs. Migrar a Constrained Delegation o RBCD con cuentas de servicio dedicadas.

Tier 2: deuda técnica

  1. ForceChangePassword y AllExtendedRights: revisar ACLs en objetos de usuario de alto valor. Aplicar el principio de mínimo privilegio en la delegación de administración de AD.
  2. PASSWD_NOTREQD: deshabilitar el flag en todas las cuentas activas. Las cuentas con este flag y contraseña vacía son credenciales funcionales sin coste de crackeo.
  3. GPO Abuse: auditar los permisos de edición de GPOs. Solo los administradores de grupo de políticas deben tener GenericWrite sobre objetos GPO.

La priorización que genera BloodHound MCP al final de una sesión de análisis —«rolling up dangerous privileges» y «prioritising the attack surface»— es precisamente este tipo de ordenación, pero generada automáticamente a partir del grafo real del dominio, no de una checklist genérica. Esa es su ventaja diferencial frente a una auditoría manual.

Uso responsable: lo que BloodHound MCP no cambia en términos legales

BloodHound MCP reduce la barrera técnica para analizar un dominio de Active Directory, pero no cambia el marco legal ni ético que rodea ese análisis. Conviene ser explícito sobre esto.

Autorización escrita previa: ejecutar bloodhound-python con credenciales válidas contra un dominio de producción sin un contrato de pentest o una autorización escrita del propietario del sistema constituye acceso no autorizado bajo la mayoría de legislaciones (Computer Fraud and Abuse Act en EE.UU., artículo 197 del Código Penal en España, Directiva NIS2 en la UE). Las credenciales válidas no equivalen a autorización.

Entornos de laboratorio aislados: el artículo de referencia ejecuta todo en un laboratorio VMware aislado con dominio IGNITE.LOCAL, sin conectividad a redes de producción. Esa es la única forma correcta de aprender y practicar estas técnicas.

Gestión del token de API: el token de BloodHound MCP tiene acceso de lectura completa al grafo, que contiene rutas de ataque, credenciales hasheadas si se han importado, y la topología completa del directorio. Debe tratarse con el mismo nivel de protección que una contraseña de administrador: rotación periódica, almacenamiento en un gestor de secretos, y revocación inmediata al terminar el engagement.

IA como amplificador, no como sustituto del juicio: Claude Desktop traduce prompts a consultas, pero no valida si los hallazgos son falsos positivos ni entiende el contexto de negocio. Un edge GenericAll sobre una cuenta de servicio puede ser un hallazgo crítico o una configuración intencional documentada. El analista sigue siendo responsable de validar cada resultado antes de incluirlo en un informe.

Para equipos que quieran integrar este tipo de análisis en un flujo de trabajo de detección continua, Wazuh puede actuar como receptor de eventos de auditoría de AD y correlacionar cambios en los atributos más sensibles (KeyCredentialLink, AdminSDHolder, derechos de replicación) con alertas en tiempo real, complementando la visión estática que ofrece BloodHound.

Preguntas frecuentes

¿Necesito saber Cypher para usar BloodHound MCP con Claude Desktop?

No. BloodHound MCP traduce los prompts en lenguaje natural a consultas REST contra la API de BloodHound CE. El analista escribe peticiones como «find Kerberoastable accounts» o «show shortest paths to Domain Admin» y el servidor genera la consulta correspondiente internamente.

¿Qué datos recolecta bloodhound-python con el flag -c All?

En el laboratorio documentado (dominio IGNITE.LOCAL), la recolección con -c All extrajo 3 equipos, 24 usuarios, 53 grupos, 3 GPOs, 2 OUs y 19 contenedores, almacenados en ficheros JSON con marca de tiempo que se ingestaron en BloodHound CE como trabajo de importación.

¿Qué versión de Python usa el entorno de bloodhound_mcp?

El gestor de paquetes uv crea un entorno CPython 3.11.15 con 55 dependencias instaladas en un único paso mediante uv sync.

¿Cómo detectar que alguien está usando bloodhound-python contra mi dominio?

Los indicadores principales son: eventos 4662 en el DC con atributos de directorio sensibles, tráfico LDAP en volumen anómalo desde estaciones de trabajo, y consultas con filtros como (servicePrincipalName=*) o (userAccountControl:1.2.840.113556.1.4.803:=4194304) desde hosts no autorizados. Herramientas SIEM como Wazuh con auditoría de directorio habilitada pueden correlacionar estos eventos.

¿Qué es el AdminSDHolder backdoor y por qué es tan peligroso?

AdminSDHolder es un objeto de AD cuya ACL sirve de plantilla para todos los grupos protegidos (Domain Admins, Administrators, etc.). El proceso SDProp la copia automáticamente cada 60 minutos. Si un atacante añade una ACE maliciosa a AdminSDHolder, esa ACE se propaga y se restaura automáticamente aunque se limpie manualmente en los grupos, creando persistencia que sobrevive a la mayoría de respuestas a incidentes estándar.

jaivic villegas jaivic villegas Ver todos los artículos →