BloodHound : Cartographier les Attaques Active Directory

BloodHound est l'outil de reference open source pour la cartographie des chemins d'attaque dans les environnements Active Directory et Azure AD/Entra ID. Developpe initialement par SpecterOps en 2016, BloodHound exploite la theorie des graphes via une base de donnees Neo4j pour modeliser les utilisateurs, groupes, machines, GPO, OU et leurs relations de privileges. La force de BloodHound reside dans sa capacite a transformer une enumeration brute d'objets AD en un graphe interroge par requetes Cypher, revelant en quelques secondes les chemins d'escalade vers Domain Admin, les relations AdminTo, CanRDP, HasSession ou GenericAll impossibles a detecter manuellement. Utilise par les equipes red team pour planifier les phases de mouvement lateral et d'escalade de privileges, BloodHound est aujourd'hui un pilier de la blue team moderne pour reduire la surface d'attaque AD, prioriser le hardening et identifier les principals Tier 0 mal configures. Cette page entity couvre l'architecture, les collectors (SharpHound, AzureHound, BloodHound.py), la methodologie d'analyse, les requetes Cypher critiques, la detection cote blue team et le mapping MITRE ATT&CK — un guide complet pour comprendre et maitriser BloodHound CE 5.x ainsi que sa version commerciale BloodHound Enterprise.

Definition : qu'est-ce que BloodHound ?

BloodHound est une plateforme de cartographie et d'analyse des chemins d'attaque dans les environnements Active Directory (AD) et Azure AD (Entra ID). Concretement, BloodHound transforme l'enumeration LDAP, SMB, ADWS et Microsoft Graph d'un domaine en un graphe oriente stocke dans Neo4j, ou chaque node represente un objet AD (User, Group, Computer, OU, Domain, GPO, Container, AIACA, EnterpriseCA, CertTemplate) et chaque edge une relation de privilege exploitable (MemberOf, AdminTo, CanRDP, HasSession, GenericAll, GenericWrite, WriteDacl, AddMember, ForceChangePassword, ReadLAPSPassword, AddKeyCredentialLink, Owns, etc.).

Cette modelisation permet a un analyste — qu'il soit pentester, consultant en securite ou defenseur — de poser une question simple : « quel est le chemin le plus court entre cet utilisateur compromis et le groupe Domain Admins ? ». BloodHound repond en quelques millisecondes via une requete Cypher, la affichant visuellement dans son interface web React. C'est cette capacite a relier des privileges a priori anodins (un GenericWrite ici, un MemberOf la, un HasSession ailleurs) en une chaine d'exploitation coherente qui distingue BloodHound des outils d'audit AD classiques tels que PingCastle ou ADRecon.

Historique : de @harmj0y et @wald0 a SpecterOps

BloodHound est ne en 2016 sous l'impulsion de trois chercheurs : Andy Robbins (@_wald0), Will Schroeder (@harmj0y) et Rohan Vazarkar (@cptjesus). Presente initialement a la DEF CON 24, l'outil revolutionne l'enumeration AD en demontrant qu'une approche par graphes rend triviale la decouverte de chemins d'attaque jusque-la invisibles aux pentesters.

L'historique de BloodHound se decoupe en trois epoques :

• BloodHound Legacy (1.x — 4.x, 2016-2023) : version originelle en Electron + Neo4j local, avec SharpHound v1 puis v2. Depreciee depuis aout 2023.
• BloodHound Community Edition (CE, 4.3.1 — 5.x, 2023-aujourd'hui) : refonte complete par SpecterOps. Architecture Docker, API REST, frontend React, ingestion par BHCE Collector, support Azure natif. C'est la version maintenue.
• BloodHound Enterprise (BHE, commercial) : version SaaS avec monitoring continu, metriques d'exposition (Tier Zero exposure), priorisation des chemins critiques et reporting executif. Vendue par SpecterOps aux grandes entreprises et MSSP.

La fondation de SpecterOps en 2017 par David McGuire (avec Robbins, Schroeder et Vazarkar) a structure le developpement professionnel de l'outil. BloodHound CE et BHE partagent le meme moteur graphe, mais BHE ajoute une couche analytique, des integrations SIEM et un cycle de collecte automatise.

Architecture technique de BloodHound CE 5.x

BloodHound CE adopte une architecture microservices conteneurisee deployee via Docker Compose. Les composants cles sont :

• Neo4j (4.4 ou 5.x) : base de donnees graphe stockant nodes et edges. Toutes les requetes Cypher transitent par Neo4j.
• PostgreSQL : metadonnees de l'application (utilisateurs BloodHound, jobs d'ingestion, configuration).
• API BloodHound (Go) : backend REST/GraphQL exposant les endpoints d'ingestion, de requete et d'administration. Ecrit en Go, performant.
• Frontend (React/TypeScript) : SPA moderne pour la visualisation du graphe, l'execution des pre-built queries et la gestion des collectors.
• Collectors externes : SharpHound, BloodHound.py, AzureHound — executes hors BloodHound, generent des fichiers JSON ZIP ingeres ensuite via l'UI ou l'API.

L'API REST de BloodHound CE est documentee via OpenAPI et permet l'automatisation : ingestion programmatique, execution de requetes Cypher, export du graphe. Cette API est exploitee par BHE pour son monitoring continu.

Les collectors : SharpHound, BloodHound.py, AzureHound

Aucune analyse BloodHound n'existe sans phase de collecte. Trois collectors officiels coexistent, chacun adapte a un contexte specifique. Pour un comparatif detaille, consultez notre article BloodHound, SharpHound et BloodyAD : comparatif 2026.

SharpHound (.NET, Windows)

SharpHound est le collector historique, ecrit en C# (.NET Framework 4.7.2+ ou .NET 6 selon les versions). Execute depuis une machine Windows joignable au domaine, il enumere via LDAP, SMB et ADWS l'ensemble des objets et relations. Modes de collecte courants :

• -c All : collecte complete (lente, OPSEC faible).
• -c DCOnly : interrogations LDAP uniquement contre le DC, pas de SMB ni de session enumeration. OPSEC eleve.
• -c Session,LoggedOn : focus sur les sessions actives (necessaire pour les edges HasSession).
• --Stealth : collecte limitee aux objets visibles depuis un user non-priv, reduit le bruit.

BloodHound.py

BloodHound.py (Dirk-jan Mollema) est un collector Python multiplateforme (Linux, macOS, Windows). Plus discret pour les ops red team Linux-based (Kali, BlackArch), il se connecte en LDAP/LDAPS depuis l'exterieur du domaine avec des credentials valides. Limite : il ne collecte pas certaines edges necessitant SMB (HasSession sans --computerfile).

AzureHound

AzureHound est le collector Azure/Entra ID, ecrit en Go par SpecterOps. Il interroge Microsoft Graph et Azure Resource Manager pour enumerer Tenants, Subscriptions, Users, Groups, Service Principals, App Registrations, Roles RBAC et leurs relations. Indispensable pour les environnements hybrides AD/Entra.

Nodes et Edges : le modele de donnees BloodHound

Le graphe BloodHound repose sur une typologie precise. Cette modelisation est la base de toute analyse — la maitriser permet d'ecrire des requetes Cypher pertinentes.

Types de nodes principaux

• User : compte utilisateur AD. Attributs cles : enabled, hasspn, dontreqpreauth, unconstraineddelegation, pwdlastset.
• Computer : machine jointe au domaine. Attributs : operatingsystem, haslaps, unconstraineddelegation, allowedtodelegate.
• Group : groupe de securite. Cibles privilegiees : Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators.
• OU / Container : unites organisationnelles, supports de delegations (GPO link, GenericAll).
• GPO : Group Policy Object. Une GPO controlee revele un controle indirect sur les objets liees.
• Domain : racine du graphe, support des trusts.
• Cert Template, EnterpriseCA, AIACA, RootCA, NTAuthStore : objets PKI introduits avec ADCS (cf. ADCS 2026 : ESC1 a ESC15).

Types d'edges (relations) cles

• MemberOf : appartenance a un groupe (transitif).
• AdminTo : droit administrateur local sur une machine.
• HasSession : session active d'un user sur une machine (vol de credentials potentiel).
• CanRDP / CanPSRemote / ExecuteDCOM : droits d'execution distante.
• GenericAll, GenericWrite, WriteDacl, WriteOwner, Owns : controles AD permettant takeover d'objet.
• ForceChangePassword : permet de reinitialiser le mot de passe d'un user cible.
• AddMember : ajout au groupe sans GenericAll.
• ReadLAPSPassword : lecture du mot de passe local LAPS.
• AddKeyCredentialLink (Shadow Credentials) : ajout d'une cle KeyCredentialLink permettant l'authentification PKINIT.
• AllowedToDelegate, AllowedToAct : delegation Kerberos contrainte (cf. glossaire Active Directory).
• ADCSESC1 a ADCSESC15 : edges composites materialisant les chemins d'attaque ADCS.

Methodologie d'analyse : modele Tier Zero/One/Two

BloodHound encourage l'adoption du modele de tiering Microsoft pour structurer la priorisation. BloodHound Enterprise automatise la classification, et BloodHound CE 5.x integre desormais des labels Tier Zero par defaut.

• Tier 0 : controleurs de domaine, comptes Domain Admins, Schema Admins, comptes service avec privileges, KRBTGT, GPO critiques, AdminSDHolder. Tout chemin menant a Tier 0 est un blocker critique.
• Tier 1 : serveurs metiers, comptes service applicatifs, admins de serveurs.
• Tier 2 : postes utilisateurs, comptes standards.

L'analyse type consiste a identifier tous les principal nodes (utilisateurs ou machines) capables d'atteindre Tier 0 via une chaine d'edges, et a evaluer combien d'attack paths convergent vers Tier 0. Cette metrique d'exposure est au cœur de BHE.

Requetes Cypher courantes

Cypher est le langage de requete de Neo4j. BloodHound expose des pre-built queries mais permet aussi des requetes personnalisees. Voici les classiques.

Trouver les comptes kerberoastables

MATCH (u:User {hasspn:true})
RETURN u.name, u.serviceprincipalnames
ORDER BY u.pwdlastset ASC

Identifie les comptes service avec un SPN (cible kerberoasting) et trie par anciennete du mot de passe.

Trouver les comptes AS-REP roastable

MATCH (u:User {dontreqpreauth:true})
RETURN u.name

Plus court chemin vers Domain Admins

MATCH p=shortestPath((n)-[*1..]->(g:Group))
WHERE g.name CONTAINS "DOMAIN ADMINS@"
RETURN p

Chemins depuis tous les principals "owned" vers Domain Admins

MATCH p=shortestPath((n {owned:true})-[*1..]->(g:Group))
WHERE g.name CONTAINS "DOMAIN ADMINS@"
RETURN p

Comptes avec delegation non contrainte

MATCH (c {unconstraineddelegation:true})
RETURN c.name, labels(c)

Shadow Credentials exploitables

MATCH p=(n)-[:AddKeyCredentialLink]->(t)
RETURN p

Cas d'usage red team

En engagement offensif, BloodHound est utilise apres l'obtention d'un premier foothold. Le workflow type :

1. Phase 1 - Collecte : execution de SharpHound en mode DCOnly ou Stealth pour minimiser les detections.
2. Phase 2 - Ingestion : import du ZIP dans BloodHound CE local (Docker on-VM red team).
3. Phase 3 - Analyse : marquage du compte initial comme Owned, lancement de la requete Shortest Paths from Owned to DA.
4. Phase 4 - Exploitation : pour chaque edge du chemin, choix de la technique (kerberoasting, NTLM relay, ADCS abuse, DCSync, password spraying).
5. Phase 5 - Iteration : marquage des nouveaux comptes compromis comme Owned et nouvelle analyse.

Pour approfondir, voir nos guides : Cartographie des chemins d'attaque AD avec BloodHound et Top 5 chemins d'attaque AD detectes par BloodHound.

Cas d'usage blue team

BloodHound n'est pas reserve aux attaquants. Les equipes defensives l'utilisent pour :

• Reduire la surface d'attaque : identifier les chemins inutiles vers Tier 0 et supprimer les delegations redondantes.
• Auditer les privileges : detecter les comptes service avec SPN inutilement, les delegations non contraintes, les ACL trop permissives.
• Hardening : prioriser les corrections par impact (combien de chemins disparaissent si je corrige cet edge ?).
• Monitoring continu : avec BHE, suivi des nouvelles expositions Tier 0 introduites lors des changements AD.
• Tests de regression securite : apres un projet de cleanup AD, comparer le graphe avant/apres.

Detection de BloodHound cote blue team

SharpHound et BloodHound.py generent des signatures detectables :

• Volume LDAP eleve : event ID 1644 ou 4662 sur les DC, requetes (objectClass=*) avec attribut filter etendu.
• SMB enum massif : connexions IPC$ vers de nombreuses machines en peu de temps.
• Process telemetrie : SharpHound.exe, signatures YARA, hashes connus (MITRE ATT&CK T1087).
• Microsoft Defender for Identity : detection native Reconnaissance using directory services.
• EDR (CrowdStrike, SentinelOne, Defender for Endpoint) : signatures comportementales SharpHound et derives (BadHound, GhostHound).
• Hunting LDAP : KQL/Splunk sur les volumes anormaux d'evenements 4662 par compte source.

Cote red team, l'OPSEC SharpHound implique : utilisation de -c DCOnly, jitter eleve (--Throttle 1000 --Jitter 50), execution depuis une machine deja compromise, utilisation de versions modifiees ou d'alternatives Python.

Comparaison : BloodHound vs alternatives

BloodHound se distingue par la profondeur d'analyse de chemins que les outils de checklist (PingCastle, PurpleKnight) ne peuvent pas offrir. Inversement, PingCastle est plus rapide pour un audit one-shot avec rapport executif.

Versions et compatibilite

• BloodHound CE 5.0+ (2024-2026) : Neo4j 5.x, support ADCS edges (ESC1-ESC15), AzureHound integre, API REST stable.
• BloodHound CE 4.3.x : transition depuis Legacy, premier support Tier Zero labeling.
• BloodHound Legacy 4.x : deprecie aout 2023. Ne recoit plus de mise a jour. Migration recommandee vers CE.
• SharpHound v2 : compatible CE uniquement. SharpHound v1 est deprecie.
• BloodHound.py v2 : aligne sur le format JSON CE.

Les fichiers JSON SharpHound v1 ne sont pas ingerables dans BloodHound CE — necessite une migration ou re-collecte.

Limites et pieges courants

• Performance sur grandes forets : > 500 000 objets entraine des temps de requete Cypher significatifs. Ajuster dbms.memory.heap.max_size de Neo4j.
• Faux positifs : certaines edges (HasSession, AdminTo) refletent un instant T. Une session expiree reste dans le graphe jusqu'a re-collecte.
• OPSEC SharpHound : le mode -c All declenche quasi-systematiquement Defender for Identity. Privilegier DCOnly + jitter.
• Stockage credentials : SharpHound n'extrait pas de mots de passe, mais les ZIP contiennent des metadonnees sensibles a proteger.
• Edges manquants : Bloodhound.py ne collecte pas tous les attributs Cert Template (preferer SharpHound + Certify pour ADCS).
• Couverture trust : les trusts cross-forest necessitent une collecte par foret distincte puis fusion.

MITRE ATT&CK mapping

L'usage de BloodHound (cote attaquant) couvre principalement les techniques de Discovery du framework MITRE ATT&CK :

• T1087.002 — Account Discovery: Domain Account : enumeration LDAP des Users et Groups.
• T1069.002 — Permission Groups Discovery: Domain Groups : enumeration des memberships.
• T1018 — Remote System Discovery : enumeration SMB/LDAP des Computers.
• T1482 — Domain Trust Discovery : cartographie des trusts inter-forets.
• T1615 — Group Policy Discovery : enumeration des GPO et de leurs liens.
• T1033 — System Owner/User Discovery : enumeration des sessions actives.

BHE et BHCE peuvent etre integres dans des plans purple team en associant chaque edge critique a une technique ATT&CK pour faciliter le mapping detection/remediation.

Liens et ecosysteme

BloodHound s'integre avec un ecosysteme d'outils complementaires :

• NTLM Relay moderne — exploitation des chemins HasSession et delegation.
• Kerberoasting — exploitation des comptes hasspn:true identifies par BloodHound.
• ADCS ESC1 a ESC15 — chemins ADCS materialises par les edges ADCSESCx.
• Pentest Active Directory — methodologie pentest AD complete integrant BloodHound.
• Glossaire Active Directory — definitions des termes AD utilises dans le graphe.

Ressources externes officielles : github.com/SpecterOps/BloodHound (depot principal), bloodhound.specterops.io (documentation), specterops.io (editeur, BHE).

FAQ

BloodHound CE est-il vraiment gratuit ?

Oui. BloodHound Community Edition est publie sous licence Apache 2.0 sur le depot GitHub de SpecterOps. Vous pouvez le deployer en interne, l'integrer dans vos pipelines DevSecOps et l'utiliser commercialement (prestations pentest, audits) sans frais. Seule BloodHound Enterprise est commerciale et facturee a l'utilisateur ou par taille de tenant. CE recoit des mises a jour regulieres et le moteur graphe est identique a BHE.

Comment detecter SharpHound ou un usage malveillant de BloodHound ?

Activez l'audit LDAP detaille (Directory Service Access, events 4662 et 1644) sur les controleurs de domaine et configurez des alertes sur les volumes anormaux par compte. Microsoft Defender for Identity dispose d'une detection native Reconnaissance using directory services. Cote EDR, des regles YARA SharpHound et des indicateurs comportementaux (process .NET avec acces LDAP massif, ouverture IPC$ vers de nombreux endpoints) sont disponibles dans CrowdStrike Falcon, SentinelOne et Defender for Endpoint. Surveillez aussi les sessions Kerberos atypiques et les acces LDAP avec attributs etendus.

BloodHound vs PingCastle : lequel choisir ?

Les deux sont complementaires. PingCastle excelle pour un audit one-shot avec un rapport executif et un score de risque clair, ideal pour les RSSI et la gouvernance. BloodHound excelle pour l'analyse en profondeur des chemins d'attaque et l'identification des actions de remediation a fort impact. En pratique : utilisez PingCastle pour le scoring et le reporting de direction, et BloodHound pour le travail technique de hardening et la priorisation des correctifs ACL/delegations.

Quelle est la meilleure OPSEC pour utiliser BloodHound en red team ?

Privilegiez SharpHound -c DCOnly qui evite l'enumeration SMB (HasSession, LoggedOn) et reduit drastiquement les detections. Ajoutez --Throttle 1000 --Jitter 50 pour ralentir et randomiser les requetes. Executez le collector depuis une machine deja legitimement compromise (pas un asset red team brut). Pour les environnements lourdement monitores, preferez BloodHound.py depuis votre infrastructure attaquante avec un compte basique, ou des collectors custom moins signaturables. Enfin, exfiltrez le ZIP via un canal C2 deja etabli.

BloodHound supporte-t-il Azure AD / Entra ID ?

Oui, depuis BloodHound CE 4.x via le collector AzureHound. AzureHound enumere via Microsoft Graph et Azure Resource Manager les Tenants, Subscriptions, Users, Groups, Service Principals, App Registrations, Directory Roles et roles RBAC. Les edges specifiques Azure (AZGlobalAdmin, AZPrivilegedRoleAdmin, AZRunAs, AZHasRole, AZAddSecret, AZAddOwner, etc.) modelisent les chemins d'escalade Entra ID. Pour un environnement hybride, ingerez les donnees AzureHound et SharpHound dans la meme instance pour visualiser les chemins traversant la frontiere AD/Entra.

BloodHound peut-il etre utilise sans Neo4j local ?

Non, Neo4j est le moteur graphe sous-jacent et indispensable. Cependant, BloodHound CE simplifie le deploiement via Docker Compose : un seul docker compose up -d lance Neo4j, PostgreSQL, l'API et le frontend. Vous pouvez aussi utiliser BloodHound Enterprise (BHE) qui est entierement SaaS — Neo4j est heberge cote SpecterOps. Pour des deployments offline air-gapped, le mode Docker reste la solution privilegiee.

Bonnes pratiques de deploiement BloodHound CE

Pour une utilisation operationnelle pertinente, plusieurs principes structurent un deploiement BloodHound mature :

• Isolation reseau : BloodHound CE manipule des donnees AD extremement sensibles (relations de privileges, comptes Tier 0). Deployez l'instance sur un reseau de gestion dedie, jamais expose a Internet, avec authentification forte (MFA via reverse-proxy SSO).
• Segregation des donnees : un projet BloodHound par environnement (production, recette, lab) pour eviter la pollution croisee des graphes.
• Backup Neo4j : exportez regulierement les bases Neo4j et PostgreSQL afin de comparer les graphes dans le temps et detecter les regressions de hardening.
• Versionnement des collectes : conservez les ZIP SharpHound horodates pour analyser l'evolution de la surface d'attaque (un cleanup AD doit faire baisser le nombre de chemins vers Tier 0).
• Integration CI/CD : automatisez la collecte hebdomadaire via une tache planifiee SharpHound + ingestion API REST BloodHound, puis exportez les metriques (chemins vers DA, comptes kerberoastable) vers un dashboard Grafana ou un SIEM.
• Hardening Neo4j : changez le mot de passe par defaut, restreignez l'acces au port 7687 (Bolt) en localhost uniquement, activez TLS pour les connexions distantes.

Integration avec un programme de threat-informed defense

BloodHound prend toute sa valeur lorsqu'il s'integre dans un programme defense oriente menace. Concretement, chaque edge identifiee comme exploitable doit etre cartographiee a une technique MITRE ATT&CK, a un controle de detection (regle SIEM, signature EDR) et a un controle de prevention (durcissement ACL, suppression delegation, rotation credentials).

Cette approche transforme BloodHound d'un simple outil de cartographie en pierre angulaire d'un cycle identify-protect-detect-respond. Les organisations matures publient ainsi un tableau de bord d'exposition mensuel exploitant les metriques BHCE/BHE : nombre de principals exposes a Tier 0, ratio comptes Tier 0 ayant des sessions sur Tier 1/2, evolution du shortest path length moyen, comptes avec SPN inutiles, delegations non contraintes restantes, comptes sans expiration de mot de passe, etc.

Conclusion

BloodHound reste, en 2026, l'outil de reference pour comprendre et reduire la surface d'attaque Active Directory et Azure AD. Sa philosophie graphe, ses pre-built queries Cypher et son ecosysteme de collectors (SharpHound, BloodHound.py, AzureHound) en font un compagnon indispensable autant pour les red teamers que pour les defenseurs. La transition Legacy vers CE est desormais aboutie ; les organisations qui n'ont pas encore migre devraient le faire pour beneficier des nouvelles edges (ADCS ESC1-ESC15, Shadow Credentials via AddKeyCredentialLink, Azure RBAC) et du modele Tier Zero automatise. Au-dela de l'outil, BloodHound incarne un changement de paradigme : passer de l'audit AD descriptif (« voici la liste des admins ») a l'analyse offensive predictive (« voici les chemins par lesquels un attaquant compromettra le domaine »). Pour aller plus loin, explorez nos guides associes sur le mapping des chemins d'attaque, le comparatif des collectors 2026 et le top 5 des chemins d'attaque AD les plus frequemment detectes.