BloodHound representa un directorio de identidades como un grafo: los nodos son usuarios, grupos, equipos y otros objetos, y las aristas son las relaciones y permisos que los conectan. Sobre ese grafo busca caminos de ataque: secuencias de permisos legítimos que, encadenados, llevan de una cuenta sin privilegios a un objetivo crítico. El punto central es que cada permiso de la cadena está bien concedido por separado; el problema es la cadena, y una persona revisando permisos de a uno no la puede ver. Los datos los recolectan programas separados —SharpHound para Active Directory y AzureHound para Entra ID y Azure— y se cargan en la interfaz. La versión actual es Community Edition, gratuita y desplegada en contenedores; la versión antigua, hoy llamada Legacy, ya no recibe mantenimiento. Y esto se corre sobre un dominio propio o con autorización escrita: el resultado es un mapa de cómo comprometer la organización.
Ver índice de contenidos
El problema que resuelve
Active Directory es el servicio de directorio de Microsoft: guarda las cuentas, los grupos, los equipos y las políticas de una organización, y decide quién puede hacer qué. En una empresa con años de historia acumula decenas de miles de objetos y una cantidad de permisos que nadie tiene en la cabeza.
Cada uno de esos permisos se concedió por un motivo razonable en su momento: alguien necesitaba administrar unas máquinas, un grupo tenía que poder restablecer contraseñas de su área, un servicio requería leer cierto atributo. El problema aparece cuando se encadenan.
La observación que originó la herramienta
Nadie diseñó un camino desde una cuenta sin privilegios hasta administrador del dominio. Se formó solo, permiso por permiso, durante años. Revisando permisos de a uno todos parecen correctos; el riesgo solo se ve cuando se los mira como una red de relaciones. Es un problema de estructura, no de configuración individual.
Esa es la razón de ser de BloodHound, y también de por qué se lo presenta como una herramienta de gestión de caminos de ataque y no de escaneo de vulnerabilidades: no busca fallos de software, busca consecuencias no previstas de decisiones administrativas correctas.
Nodos, aristas y por qué un grafo
El modelo tiene dos piezas y se aprende en un minuto:
- Nodos. Los objetos del directorio: usuarios, grupos, equipos, unidades organizativas, dominios. En el caso de identidad en la nube se agregan aplicaciones y roles.
- Aristas. Las relaciones entre ellos: pertenecer a un grupo, tener administración local sobre un equipo, poder restablecer la contraseña de otra cuenta, tener control delegado sobre una unidad organizativa, o tener una sesión abierta en una máquina concreta.
La elección del grafo no es estética. Un grafo permite hacer una pregunta que una tabla de permisos no responde: ¿existe algún recorrido desde acá hasta allá? Y esa es exactamente la pregunta que se hace quien atacó una sola cuenta y quiere llegar al control del dominio.
Qué es un camino de ataque
Un camino de ataque es una secuencia de aristas que conecta un punto de partida con un objetivo. El ejemplo canónico tiene cuatro saltos:
- Una cuenta común pertenece a un grupo de soportePerfectamente normal: alguien de mesa de ayuda necesita ese grupo para trabajar.
- Ese grupo tiene administración local sobre las estaciones de trabajoTambién razonable: para eso existe el grupo.
- En una de esas estaciones hay una sesión abierta de una cuenta con más privilegiosCircunstancial. Alguien de infraestructura entró a resolver un problema y quedó la sesión.
- Esa cuenta tiene control delegado sobre la unidad organizativa de los servidoresDelegación hecha años atrás por un motivo que ya nadie recuerda.
Cada eslabón tiene su justificación. Juntos, forman un recorrido desde una cuenta de soporte hasta el control de los servidores. Y lo importante es qué se hace con eso:
Se busca la arista cuya eliminación corta más caminos a la vez. En un directorio real, unas pocas aristas concentran la mayoría de los recorridos hacia objetivos críticos, y ahí está el trabajo con mejor relación entre esfuerzo y resultado. Conviene además distinguir dos tipos: las aristas estructurales son configuración y se corrigen; las de sesión son circunstanciales y se reducen con hábitos de operación, como no iniciar sesión con cuentas privilegiadas en equipos de usuario.
Community Edition y Legacy
Este punto genera confusión porque hay tutoriales de las dos generaciones circulando. La documentación oficial es clara: la versión antigua, hoy llamada Legacy, ya no recibe mantenimiento. Lo vigente en el mundo libre es Community Edition.
| Edición | Estado | Recolectores |
|---|---|---|
| Community Edition | Vigente y gratuita. Arquitectura en contenedores con interfaz web | SharpHound CE, AzureHound CE, OpenHound CLI |
| Enterprise | Producto comercial, con seguimiento continuo | SharpHound Enterprise, AzureHound Enterprise |
| Legacy | Sin mantenimiento. Solo aparece en material antiguo | Recolectores de su generación |
Si un tutorial te pide instalar una aplicación de escritorio y conectarla a una base de grafos a mano, es de la generación anterior. La edición comunitaria actual se despliega distinto.
Cómo se monta
Según la guía de inicio rápido oficial, Community Edition usa una arquitectura en contenedores de varias capas —base de datos, aplicación e interfaz— orquestada con Docker Compose, y la interfaz queda disponible en el puerto local 8080, escuchando solo en la máquina local salvo que se cambie la configuración.
Los requisitos mínimos que documenta son 8 GB de memoria, 4 núcleos y 10 GB de disco, y para entornos de más de 50.000 usuarios sube a 96 GB de memoria, 12 núcleos y 50 GB de disco. Ese salto dice algo sobre la naturaleza del problema: recorrer todos los caminos posibles de un grafo enorme es costoso.
La documentación oficial ofrece conjuntos de datos de ejemplo de Active Directory y de Azure que se cargan directamente en la interfaz. Es la mejor manera de aprender a leer el grafo y las consultas: te da un directorio grande y desordenado sin que tengas que recolectar nada de ninguna parte. Si estás empezando, este es el camino.
La recolección de datos
Los datos no los obtiene la interfaz: los recolectan programas separados que se ejecutan dentro del entorno y producen archivos JSON empaquetados en un ZIP, que después se cargan por la interfaz o por la interfaz de programación.
- SharpHound CE para Active Directory.
- AzureHound CE para Entra ID y Azure.
- OpenHound CLI para otras plataformas de identidad como GitHub, Jamf y Okta.
La recolección hace muchísimas consultas al directorio, deja rastro y produce un archivo que es un mapa completo de cómo comprometer la organización. Tres consecuencias: se acuerda por escrito con quien opera el directorio, se coordina la ventana porque genera carga y activa alertas, y el archivo resultante se trata como el activo más sensible del trabajo —cifrado, con acceso restringido y destruido cuando el trabajo termina—. Un ZIP de recolección filtrado le ahorra semanas a quien quiera atacar esa organización.
El marco completo de autorización, alcance y manejo de evidencia está en fundamentos de hacking ético. Para aprender, un dominio propio en máquinas virtuales o los datos de ejemplo.
Lo mismo, del lado defensivo
BloodHound nació en el ámbito ofensivo, pero su valor mayor está en el defensivo, y por un motivo simple: quien administra el directorio puede cortar aristas, y quien lo audita solo puede señalarlas.
- Reducir la pertenencia a grupos con alcance amplio. Un grupo con administración local sobre todas las estaciones es una arista que aparece en casi todos los caminos.
- Separar las cuentas administrativas de las de uso diario. Y no iniciar sesión con las privilegiadas en equipos de usuario, que es lo que crea las aristas de sesión.
- Revisar las delegaciones heredadas. El control delegado sobre una unidad organizativa suele sobrevivir al motivo que lo justificó.
- Medir con el grafo, no con la intuición. Antes y después de un cambio: cuántos caminos hacia objetivos críticos quedaron. Es una métrica que se puede mostrar.
- Repetir la recolección periódicamente. El grafo cambia solo, porque las organizaciones conceden permisos todo el tiempo.
Errores frecuentes
- Recolectar sin autorización escrita específica. No alcanza con tener acceso al dominio: la recolección se acuerda aparte.
- Tratar el archivo de recolección como un archivo cualquiera. Es un mapa de cómo comprometer la organización.
- Seguir tutoriales de la generación Legacy. Esa versión ya no recibe mantenimiento y su despliegue es distinto.
- Intentar corregir todos los caminos. El trabajo útil es encontrar la arista que corta muchos a la vez.
- Confundir aristas estructurales con aristas de sesión. Las primeras son configuración; las segundas, hábitos de operación.
- Presentar el grafo entero a quien decide. Un grafo de veinte mil nodos no comunica nada: se presenta el camino y la arista propuesta.
- Recolectar una sola vez. El grafo cambia continuamente y una foto vieja da una falsa sensación de orden.
Preguntas frecuentes
¿BloodHound explota vulnerabilidades?
No. No busca fallos de software ni intenta aprovecharlos: analiza permisos y relaciones que están correctamente configurados y muestra qué recorridos permiten cuando se los mira en conjunto. Por eso se lo describe como una herramienta de gestión de caminos de ataque y no como un escáner de vulnerabilidades. Lo que encuentra no se arregla con una actualización, porque no hay nada roto en sentido estricto: se arregla cambiando decisiones de diseño de permisos, quitando pertenencias a grupos con alcance demasiado amplio o revisando delegaciones que sobrevivieron a su motivo original.
¿Cuál es la diferencia entre BloodHound y SharpHound?
Son dos piezas de un mismo flujo. SharpHound es el recolector: se ejecuta dentro del entorno, consulta el directorio y produce archivos JSON empaquetados en un ZIP. BloodHound es la plataforma que recibe esos datos, los guarda en sus bases y permite recorrer el grafo y buscar caminos. Para identidad en la nube el recolector equivalente es AzureHound, que cubre Entra ID y Azure, y hay además un recolector para otras plataformas de identidad. La separación tiene sentido operativo: la recolección ocurre donde está el directorio, y el análisis puede hacerse en otra máquina.
¿Se puede usar sin un dominio real?
Sí, y es la forma recomendada de empezar. La documentación oficial ofrece conjuntos de datos de ejemplo de Active Directory y de Azure que se cargan directamente en la interfaz con la opción de carga rápida. Eso te da un directorio grande y desordenado —que es justo lo que hace falta para aprender a leer caminos— sin recolectar nada de ninguna organización. La alternativa es montar un dominio propio en máquinas virtuales, que además enseña mucho sobre cómo se crean estas relaciones en primer lugar. Practicar sobre un dominio ajeno no está entre las opciones.
¿Por qué pide tanta memoria?
Porque recorrer todos los caminos posibles de un grafo es un problema costoso, y crece rápido con el tamaño. La guía oficial documenta un mínimo de 8 GB de memoria, 4 núcleos y 10 GB de disco, y para entornos de más de 50.000 usuarios recomienda 96 GB de memoria, 12 núcleos y 50 GB de disco. Ese salto refleja la naturaleza del cálculo: no se trata de guardar más filas sino de explorar exponencialmente más combinaciones de relaciones. Para aprender con los datos de ejemplo, los requisitos mínimos alcanzan sin problema.
¿Qué se hace primero con los resultados?
Buscar concentración, no cantidad. En un directorio real hay muchísimos caminos, y la mayoría pasa por unas pocas aristas: una pertenencia a un grupo con alcance demasiado amplio, una delegación heredada, un derecho de administración local concedido a todo un departamento. Cortar una de esas aristas elimina cientos de caminos de una vez, y eso es lo que conviene proponer primero. Presentar el grafo completo a quien tiene que decidir no funciona: lo que se muestra es un camino concreto, la arista que se propone quitar, y cuántos caminos desaparecen al hacerlo.
¿La versión antigua sigue sirviendo?
La página oficial de recursos indica que la versión Legacy ya no recibe mantenimiento, así que no conviene apoyar trabajo nuevo en ella. Vale la pena saberlo porque circula mucho material que la usa: si un tutorial te pide instalar una aplicación de escritorio y conectarla a mano a una base de grafos, es de esa generación. La edición comunitaria actual se despliega como un conjunto de contenedores con interfaz web, tiene su propia interfaz de programación y sus propios recolectores, y es la que reciben las mejoras. Al buscar documentación conviene comprobar de qué generación es.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. Sección Hacking. Discusiones de la comunidad sobre evaluación de dominios en contextos autorizados.
- Underc0de, blog. Microsoft confirma ataques contra Exchange Server, por Dragora, 15 de mayo de 2026. Ejemplo del tipo de incidente donde el movimiento lateral dentro del dominio es el problema de fondo.
Documentación oficial
- SpecterOps. BloodHound. Documentación oficial, con el enfoque de caminos de ataque y el modelo de grafo.
- SpecterOps. Community Edition Quickstart. Arquitectura en contenedores, requisitos de memoria y procesador, interfaz en el puerto local 8080 y formas de cargar datos.
- SpecterOps. Legacy BloodHound. La página oficial que indica que la versión antigua ya no recibe mantenimiento.
- SpecterOps. Repositorio de BloodHound. Código de la edición comunitaria y de los recolectores.
- Microsoft. Active Directory Domain Services Overview. Documentación del servicio de directorio que se analiza.
- Microsoft. Buenas prácticas de roles en Entra ID. Referencia oficial para el lado de identidad en la nube.