BloodHound : Cartographie des Chemins d'Attaque Active

Active Directory reste le coeur de l'infrastructure d'identité de plus de 90 % des entreprises du Fortune 1000. Chaque relation entre un utilisateur, un groupe, un ordinateur ou une GPO constitue potentiellement un maillon dans une chaîne d'attaque menant au Domain Admin. BloodHound est l'outil qui révèle ces chaînes invisibles -- transformant la complexité d'un annuaire de milliers d'objets en un graphe navigable où chaque chemin d'attaque devient visible, mesurable et remédiable. Ce guide approfondi examine en detail les aspects fondamentaux et avances de BloodHound, en proposant une analyse structuree et documentee des enjeux actuels. Les professionnels y trouveront des recommandations concretes, des methodologies eprouvees et des retours d'experience terrain directement applicables en environnement de production. L'analyse integre les dernieres evolutions technologiques, les tendances emergentes du secteur et les meilleures pratiques recommandees par les experts du domaine.

Développé initialement par @_wald0, @CptJesus et @harmj0y de l'équipe SpecterOps, BloodHound utilise la théorie des graphes pour modéliser les relations de contrôle dans Active Directory. Contrairement aux scanners de vulnérabilités traditionnels qui identifient des problèmes ponctuels, BloodHound révèle les chemins composites -- des enchaînements de permissions apparemment inoffensives qui, combinées, permettent à un attaquant de progresser d'un compte utilisateur standard jusqu'aux privilèges Domain Admin. Pour plus d'informations, consultez les ressources de ANSSI.

Le constat est alarmant : dans nos audits Active Directory, nous identifions en moyenne 47 chemins d'attaque exploitables vers le Domain Admin dans une infrastructure de taille moyenne (5 000 objets). Certains de ces chemins exploitent des configurations vieilles de plus de dix ans, jamais auditées, jamais remises en question. BloodHound rend ces risques tangibles -- et surtout actionnables. Pour plus d'informations, consultez les ressources de MITRE ATT&CK.

Cet article constitue un guide complet pour maîtriser BloodHound Community Edition (CE) en 2026 : de l'installation aux requêtes Cypher avancées, en passant par les collecteurs, les chemins d'attaque critiques, et surtout les stratégies de remédiation. Que vous soyez pentesteur, auditeur ou défenseur, ce guide vous fournira les connaissances nécessaires pour exploiter pleinement la puissance de cet outil.

Point clé : BloodHound n'est pas un outil d'exploitation. Il ne compromet aucun système. Il collecte des informations accessibles à tout utilisateur authentifié du domaine et les organise pour révéler les chemins d'attaque latents. C'est un outil d'analyse, aussi précieux pour les attaquants que pour les défenseurs.

2. Théorie des graphes appliquée à Active Directory

2.1 Noeuds, arêtes et relations de contrôle

La théorie des graphes fournit le cadre mathématique parfait pour modéliser la sécurité d'Active Directory. Dans le modèle BloodHound, chaque objet AD est représenté comme un noeud (node) et chaque relation de contrôle ou de permission constitue une arête (edge) orientée entre deux noeuds.

Les types de noeuds principaux dans le graphe BloodHound sont :

Type de noeud	Représente	Exemples d'attributs collectés
User	Compte utilisateur AD	SID, UPN, adminCount, servicePrincipalName, lastLogon
Group	Groupe de sécurité	SID, membres, memberOf, adminCount
Computer	Compte ordinateur	OS, sessions actives, LocalAdmin, services
Domain	Domaine AD	Functional level, trusts, policies
GPO	Group Policy Object	GUID, liens OU, permissions d'écriture
OU	Unité d'Organisation	Distinguished Name, GPO linkées, ACL
Container	Conteneur AD	Distinguished Name, objets enfants

Les arêtes (edges) représentent les relations de contrôle entre ces noeuds. BloodHound CE reconnaît plus de 30 types d'arêtes, dont les plus critiques sont :

• MemberOf : appartenance à un groupe (transitif -- un membre d'un groupe membre de Domain Admins hérite des privilèges)
• AdminTo : droits d'administration locale sur un ordinateur
• HasSession : session active d'un utilisateur sur un ordinateur (permet le credential harvesting)
• GenericAll : contrôle total sur un objet (modification d'attributs, réinitialisation de mot de passe, etc.)
• GenericWrite : écriture d'attributs arbitraires (permet le Targeted Kerberoasting via modification de SPN)
• WriteDacl : modification de la DACL d'un objet (permet de s'octroyer n'importe quel droit)
• WriteOwner : modification du propriétaire d'un objet (le propriétaire peut modifier la DACL)
• ForceChangePassword : réinitialisation du mot de passe sans connaître l'actuel
• DCSync : droits de réplication (DS-Replication-Get-Changes + DS-Replication-Get-Changes-All) permettant l'extraction de tous les hashes
• GPLink : liaison d'une GPO à une OU (contrôle des paramètres appliqués aux objets de l'OU)

2.2 Le concept de chemin d'attaque (Attack Path)

Un chemin d'attaque est une séquence ordonnée de noeuds et d'arêtes qui permet à un attaquant de progresser d'un point de départ (typiquement un compte utilisateur compromis) vers un objectif (typiquement le groupe Domain Admins). L'algorithme de plus court chemin (Shortest Path, basé sur Dijkstra ou BFS) est fondamental dans BloodHound car il identifie la route la plus directe vers l'objectif.

Prenons un exemple concret. Un attaquant compromet le compte jdupont (utilisateur standard du département comptabilité). BloodHound révèle la chaîne suivante :

# Chemin d'attaque composite - Exemple réel anonymisé
jdupont (User)
  --[MemberOf]--> GRP-Comptabilite (Group)
    --[GenericWrite]--> svc-backup (User) 
      # Targeted Kerberoasting : modification du SPN
      --[MemberOf]--> GRP-Backup-Operators (Group)
        --[AdminTo]--> SRV-DC02 (Computer)
          # Accès admin local au DC secondaire
          --[HasSession]--> admin-tier0 (User)
            # Credential harvesting via Mimikatz
            --[MemberOf]--> Domain Admins (Group)
              # Compromission totale du domaine

Une compromission d'un seul poste de travail pourrait-elle mener à votre contrôleur de domaine ?

2. Théorie des graphes appliquée à Active Directory : analyse approfondie

Ce chemin exploite cinq relations distinctes, chacune apparemment bénigne quand examinée isolément. Le groupe Comptabilité ayant GenericWrite sur un compte de service ? Probablement une délégation administrative mal configurée. Le compte de service dans Backup Operators ? Une décision d'administration système. Backup Operators ayant AdminTo sur un DC ? Un comportement attendu. Un administrateur Tier 0 ayant une session sur ce DC ? Absolument normal. Mais la combinaison de ces relations crée un chemin direct de la comptabilité au Domain Admin en quatre étapes.

2.3 Métriques de graphe pour prioriser la remédiation

La théorie des graphes offre des métriques puissantes pour quantifier le risque et prioriser les actions correctives :

• Shortest Path Count : nombre de chemins les plus courts vers Domain Admin depuis chaque noeud. Un noeud avec 50 shortest paths est prioritaire par rapport à un noeud avec 2.
• Betweenness Centrality : mesure la fréquence à laquelle un noeud apparaît sur les chemins les plus courts entre d'autres paires de noeuds. Un noeud à haute centralité est un point de passage critique -- le supprimer élimine de nombreux chemins d'attaque simultanément.
• Degree Centrality : nombre d'arêtes entrantes et sortantes d'un noeud. Un compte avec un degree élevé a de nombreuses relations de contrôle -- c'est une cible de choix et un point de remédiation prioritaire.
• Tier Reachability : pourcentage d'objets Tier 0 (Domain Admins, Domain Controllers, KRBTGT, etc.) atteignables depuis un noeud donné. Métrique directe du risque de compromission totale.

3. BloodHound Community Edition : installation et architecture

3.1 Architecture de BloodHound CE

BloodHound Community Edition (CE), sorti en 2023, représente une réécriture complète de l'outil historique. L'architecture repose désormais sur :

• PostgreSQL : base de données relationnelle pour les métadonnées, les configurations et l'indexation
• Neo4j : base de données graphe pour le stockage et l'interrogation des relations AD via le langage Cypher
• API REST : backend en Go fournissant une API complète pour l'interaction programmatique
• Interface Web React : UI moderne remplaçant l'ancienne application Electron, accessible via navigateur
• Docker Compose : déploiement conteneurisé simplifiant l'installation et les mises à jour

3.2 Installation via Docker Compose

L'installation de BloodHound CE se fait en quelques commandes. Voici la procédure complète sur un système Linux (Ubuntu/Debian) :

# Prérequis : Docker et Docker Compose
sudo apt update && sudo apt install -y docker.io docker-compose-plugin

# Cloner le dépôt BloodHound CE
git clone https://github.com/SpecterOps/BloodHound.git
cd BloodHound

# Lancer avec Docker Compose
sudo docker compose up -d

# Vérifier que les conteneurs sont actifs
sudo docker compose ps
# Résultat attendu :
# bloodhound-1    Running   0.0.0.0:8080->8080/tcp
# neo4j-1         Running   0.0.0.0:7687->7687/tcp  
# postgres-1      Running   0.0.0.0:5432->5432/tcp

# Récupérer le mot de passe admin initial
sudo docker compose logs bloodhound-1 2>&1 | grep "Initial Password"
# Initial Password Set To: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

L'interface est accessible sur http://localhost:8080. Connectez-vous avec l'utilisateur admin et le mot de passe initial, puis changez-le immédiatement.

3.3 Configuration avancée

Pour les environnements de grande taille (plus de 50 000 objets), ajustez les paramètres de performance dans le fichier docker-compose.yml :

# docker-compose.yml - Configuration optimisée pour grands domaines
services:
  neo4j:
    environment:
      - NEO4J_server_memory_heap_max__size=4G
      - NEO4J_server_memory_pagecache_size=2G
      - NEO4J_db_transaction_timeout=120s
    volumes:
      - neo4j-data:/data
    deploy:
      resources:
        limits:
          memory: 8G
          
  postgres:
    environment:
      - POSTGRES_SHARED_BUFFERS=512MB
      - POSTGRES_WORK_MEM=64MB
    volumes:
      - postgres-data:/var/lib/postgresql/data

4. Collecteurs : SharpHound, RustHound et AzureHound

4.1 SharpHound : le collecteur de référence

SharpHound est le collecteur officiel de BloodHound, écrit en C#. Il interroge Active Directory via LDAP, collecte les sessions actives via NetSessionEnum/NetWkstaUserEnum, énumère les administrateurs locaux via SAM-R, et résout les ACL sur les objets sensibles. Les données collectées sont exportées en fichiers JSON compressés (ZIP) pour ingestion dans BloodHound.

Les méthodes de collecte (paramètre -c) déterminent l'étendue des données rassemblées :

# Collecte complète recommandée pour un audit
SharpHound.exe -c All --zipfilename audit_domaine_2026

# Collecte légère pour un premier aperçu rapide
SharpHound.exe -c Default --zipfilename quick_scan

# Collecte ciblée sessions uniquement (pour mise à jour)  
SharpHound.exe -c Session --zipfilename sessions_update

# Collecte avec authentification alternative
SharpHound.exe -c All -d corp.local --ldapusername auditor --ldappassword 'P@ssw0rd!'

# Collecte multi-domaines (forêt)
SharpHound.exe -c All --searchforest --zipfilename forest_audit

# Collecte furtive (délai entre requêtes)
SharpHound.exe -c All --throttle 1000 --jitter 20

Méthode	Données collectées	Impact réseau	Durée typique (5000 objets)
Default	Groupes, sessions, admins locaux, trusts	Moyen	5-10 min
All	Tout : ACL, GPO, SPNs, containers, etc.	Élevé	15-30 min
Session	Sessions actives uniquement	Faible	2-5 min
ACL	Listes de contrôle d'accès	Moyen	10-20 min
ObjectProps	Propriétés des objets (SPN, descriptions)	Faible	3-5 min
GPOLocalGroup	Groupes locaux configurés via GPO	Moyen	5-15 min

4.2 RustHound : le collecteur cross-platform

RustHound est un collecteur alternatif écrit en Rust par @NH-RED-TEAM. Son principal avantage est la portabilité cross-platform : il fonctionne nativement sur Linux, macOS et Windows, ce qui le rend idéal pour les pentesters travaillant depuis une machine Linux (Kali, Parrot) sans avoir besoin de compiler du C# ou d'utiliser Mono.

# Installation RustHound
cargo install rusthound
# ou télécharger le binaire pré-compilé depuis GitHub

# Collecte depuis Linux avec authentification LDAP
rusthound -d corp.local -u auditor -p 'P@ssw0rd!' -o /tmp/audit_bh
# Génère des fichiers JSON compatibles BloodHound CE

# Collecte avec LDAPS (recommandé)
rusthound -d corp.local -u auditor -p 'P@ssw0rd!' \
  --ldaps --dc-ip 10.0.0.1 -o /tmp/audit_bh

# Collecte ciblée par OU
rusthound -d corp.local -u auditor -p 'P@ssw0rd!' \
  --ldap-filter "(distinguishedName=*OU=Servers*)" -o /tmp/servers_bh

4.3 AzureHound : extension au cloud

Votre Active Directory résisterait-il à une attaque Kerberoasting ?

4. Collecteurs : SharpHound, RustHound et AzureHound : analyse approfondie

AzureHound étend la couverture de BloodHound à Microsoft Entra ID (Azure AD) et aux ressources Azure. Il collecte les relations entre les objets cloud : utilisateurs Entra ID, groupes, applications, service principals, rôles RBAC Azure, abonnements, resource groups, et Key Vaults. Pour une compréhension approfondie de la sécurité Entra ID, consultez notre article sur la sécurisation d'Entra ID avec Conditional Access.

# Installation AzureHound
# Télécharger depuis https://github.com/BloodHoundAD/AzureHound/releases

# Collecte avec authentification interactive
azurehound -t tenant-id list --tenant corp.onmicrosoft.com -o azure_data.json

# Collecte avec Service Principal
azurehound list -t tenant-id -a app-id -s 'client-secret' -o azure_data.json

# Collecte complète (toutes les ressources)
azurehound list --tenant corp.onmicrosoft.com -o azure_full.json

4.4 Ingestion des données dans BloodHound CE

L'ingestion des fichiers collectés dans BloodHound CE se fait via l'interface web ou l'API REST :

# Ingestion via l'interface web :
# 1. Connectez-vous à http://localhost:8080
# 2. Cliquez sur l'icône "Upload" (flèche vers le haut)
# 3. Sélectionnez le fichier ZIP généré par SharpHound/RustHound
# 4. L'ingestion commence automatiquement

# Ingestion via API REST (pour automatisation)
curl -X POST "http://localhost:8080/api/v2/file-upload" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -F "file=@audit_domaine_2026.zip"

# Vérification de l'ingestion
curl -s "http://localhost:8080/api/v2/bloodhound-stats" \
  -H "Authorization: Bearer YOUR_TOKEN" | jq .
# Résultat : nombre de noeuds, arêtes, sessions importées

5. Requêtes Cypher : interroger le graphe AD

5.1 Fondamentaux du langage Cypher

Cypher est le langage de requête natif de Neo4j, conçu spécifiquement pour interroger des graphes. Sa syntaxe visuelle rend la formulation de requêtes intuitive : les noeuds sont représentés par des parenthèses (), les arêtes par des crochets [] et des flèches ->, et les chemins par l'enchaînement de ces éléments.

// Syntaxe de base Cypher
// (noeud:Label {propriété: valeur})-[relation:TYPE]->(autre_noeud)

// Trouver tous les utilisateurs du domaine
MATCH (u:User) WHERE u.domain = "CORP.LOCAL" RETURN u.name

// Trouver tous les membres du groupe Domain Admins
MATCH (u)-[:MemberOf*1..]->(g:Group {name: "DOMAIN ADMINS@CORP.LOCAL"})
RETURN u.name, labels(u)

// Le *1.. signifie "une ou plusieurs relations MemberOf"
// (membership récursive à travers les groupes imbriqués)

5.2 Requêtes d'analyse critiques

Voici les requêtes Cypher les plus importantes pour un audit Active Directory. Chacune révèle un aspect critique de la posture de sécurité :

Shortest Path vers Domain Admin

// Plus court chemin de tout utilisateur vers Domain Admins
MATCH p=shortestPath(
  (u:User {enabled: true})-[*1..]->(g:Group {name: "DOMAIN ADMINS@CORP.LOCAL"})
)
WHERE u.name <> "ADMINISTRATOR@CORP.LOCAL"
  AND NOT u.name CONTAINS "ADMIN"
RETURN p
ORDER BY length(p) ASC
LIMIT 20

Utilisateurs Kerberoastable avec chemins vers DA

// Utilisateurs avec SPN (Kerberoastable) ayant un chemin vers DA
MATCH (u:User {hasspn: true, enabled: true})
WHERE u.name <> "KRBTGT@CORP.LOCAL"
MATCH p=shortestPath((u)-[*1..]->(g:Group {name: "DOMAIN ADMINS@CORP.LOCAL"}))
RETURN u.name, u.serviceprincipalnames, length(p) as PathLength
ORDER BY PathLength ASC

Droits DCSync

// Objets avec droits DCSync (DS-Replication-Get-Changes-All)
MATCH (n)-[:DCSync|GetChangesAll*1..]->(d:Domain)
WHERE NOT n.name CONTAINS "DOMAIN CONTROLLERS"
  AND NOT n.name CONTAINS "DOMAIN ADMINS"
RETURN n.name, labels(n), d.name
ORDER BY n.name

Délégation OU abusive

// Utilisateurs non-admin avec GenericAll/WriteDacl sur des OU contenant des comptes privilégiés
MATCH (u:User)-[r:GenericAll|WriteDacl|WriteOwner|GenericWrite]->(ou:OU)
WHERE NOT (u)-[:MemberOf*1..]->(:Group {name: "DOMAIN ADMINS@CORP.LOCAL"})
MATCH (privileged)-[:MemberOf*1..]->(:Group {admincount: true})
WHERE privileged.distinguishedname CONTAINS ou.distinguishedname
RETURN u.name, type(r), ou.name, privileged.name

Ordinateurs sans LAPS

// Ordinateurs Windows sans LAPS activé
MATCH (c:Computer)
WHERE c.haslaps = false 
  AND c.enabled = true
  AND c.operatingsystem CONTAINS "Windows"
RETURN c.name, c.operatingsystem, c.haslaps
ORDER BY c.name

Sessions actives sur les Domain Controllers

5. Requêtes Cypher : interroger le graphe AD : analyse approfondie

// Utilisateurs non Tier-0 ayant des sessions sur les DCs
MATCH (c:Computer)-[:MemberOf*1..]->(g:Group {name: "DOMAIN CONTROLLERS@CORP.LOCAL"})
MATCH (u:User)-[:HasSession]->(c)
WHERE NOT (u)-[:MemberOf*1..]->(:Group {name: "DOMAIN ADMINS@CORP.LOCAL"})
RETURN u.name, c.name
ORDER BY c.name

Chaînes AdminTo

// Chaînes de déplacement latéral via AdminTo
MATCH p=(u:User {enabled:true})-[:AdminTo*1..5]->(c:Computer)
WHERE (c)-[:MemberOf*1..]->(:Group {name: "DOMAIN CONTROLLERS@CORP.LOCAL"})
RETURN p
ORDER BY length(p) ASC
LIMIT 10

5.3 Requêtes personnalisées pour scénarios spécifiques

Au-delà des requêtes standard, voici des requêtes avancées que nous utilisons régulièrement lors de nos audits AD :

// Comptes de service avec mot de passe ancien (> 365 jours)
MATCH (u:User {hasspn: true, enabled: true})
WHERE u.pwdlastset < (datetime().epochSeconds - (365 * 86400))
RETURN u.name, 
  datetime({epochSeconds: toInteger(u.pwdlastset)}) as LastPwdChange,
  u.serviceprincipalnames
ORDER BY u.pwdlastset ASC

// Groupes avec permissions dangereuses sur le conteneur AdminSDHolder
MATCH (n)-[r:GenericAll|WriteDacl|WriteOwner|GenericWrite]->(c:Container)
WHERE c.distinguishedname CONTAINS "AdminSDHolder"
  AND NOT n.name CONTAINS "DOMAIN ADMINS"
RETURN n.name, type(r), c.distinguishedname

// Comptes avec le flag "Do not require Kerberos preauthentication" (AS-REP roasting)
MATCH (u:User {dontreqpreauth: true, enabled: true})
RETURN u.name, u.description, u.pwdlastset
ORDER BY u.name

6. Chemins d'attaque critiques

6.1 Shortest Path to Domain Admin

Le chemin le plus court vers le Domain Admin est la métrique reine d'un audit BloodHound. Il quantifie le nombre minimum d'étapes qu'un attaquant doit franchir pour passer d'un compte compromis à la compromission totale du domaine. Dans notre expérience, les résultats sont souvent alarmants :

• 1-2 étapes : Critique. Compromission quasi immédiate. Exemples : utilisateur standard dans un groupe avec GenericAll sur Domain Admins, ou administrateur local d'un DC.
• 3-4 étapes : Élevé. Exploitable en quelques heures par un attaquant compétent. Nécessite plusieurs pivots mais chaque étape est généralement automatisable.
• 5-7 étapes : Modéré. Exploitable en 1-2 jours. Chaque étape augmente le risque de détection, mais un attaquant patient peut y parvenir.
• 8+ étapes ou aucun chemin : Faible. L'infrastructure implémente probablement un modèle de tiering efficace.

6.2 Kerberoasting : les comptes de service vulnérables

Le Kerberoasting cible les comptes utilisateur possédant un Service Principal Name (SPN). Tout utilisateur authentifié peut demander un ticket de service Kerberos (TGS) pour n'importe quel SPN du domaine. Ce ticket est chiffré avec le hash NT du mot de passe du compte de service -- et peut être craqué offline sans laisser de trace significative dans les logs. Pour une analyse complète des techniques de cracking, consultez notre article sur les attaques sur les mots de passe.

BloodHound identifie automatiquement les comptes Kerberoastable et calcule leur proximité aux groupes à privilèges. La requête Cypher suivante identifie les cibles prioritaires :

// Kerberoastable users avec chemin vers des groupes admin
MATCH (u:User {hasspn: true, enabled: true})
WHERE u.name <> "KRBTGT@CORP.LOCAL"
OPTIONAL MATCH p=shortestPath((u)-[*1..]->(g:Group {admincount: true}))
RETURN u.name, u.serviceprincipalnames, 
  CASE WHEN p IS NOT NULL THEN length(p) ELSE -1 END as PathToAdmin,
  u.pwdlastset
ORDER BY PathToAdmin ASC

6.3 DCSync : le Graal de l'attaquant

L'attaque DCSync exploite le protocole de réplication Active Directory (MS-DRSR / DRSUAPI) pour extraire les hashes de mot de passe de n'importe quel compte du domaine, y compris le KRBTGT (ce qui permet ensuite la création de Golden Tickets). Les droits nécessaires sont DS-Replication-Get-Changes et DS-Replication-Get-Changes-All sur l'objet domaine. Pour approfondir l'extraction des secrets AD, consultez notre article complémentaire sur NTDS.dit et la protection des secrets Active Directory.

6. Chemins d'attaque critiques : analyse approfondie

BloodHound représente ces droits via l'arête DCSync. La requête suivante identifie tous les objets non légitimes disposant de ces droits :

// Objets non légitimes avec droits DCSync
MATCH (n)-[:DCSync|GetChangesAll*1..]->(d:Domain)
WHERE NOT n.name STARTS WITH "DOMAIN CONTROLLERS"
  AND NOT n.name STARTS WITH "DOMAIN ADMINS"
  AND NOT n.name STARTS WITH "ENTERPRISE ADMINS"
  AND NOT n.name = "ADMINISTRATOR@" + d.name
RETURN DISTINCT n.name, labels(n), d.name as Domain
ORDER BY n.name

6.4 Abus de délégation OU

La délégation d'administration sur les OU est un mécanisme légitime qui permet de confier la gestion d'un sous-ensemble d'objets à des équipes spécifiques (helpdesk, équipes régionales, etc.). Cependant, une délégation mal configurée peut créer des chemins d'attaque directs. Les scénarios les plus dangereux identifiés par BloodHound :

• GenericAll sur une OU contenant des comptes Tier 0 : permet la réinitialisation de mot de passe des administrateurs, la modification de leurs attributs, voire la suppression de leur compte.
• WriteDacl sur une OU de servers : permet de modifier les ACL des serveurs contenus, s'octroyant des droits d'administration locale.
• WriteOwner sur des OU sensibles : le propriétaire d'une OU peut modifier sa DACL, s'octroyant ensuite n'importe quel droit sur les objets enfants.
• GPLink abuse : si un utilisateur peut lier des GPO à une OU, il peut déployer des scripts malveillants sur tous les ordinateurs de cette OU.

6.5 AS-REP Roasting et Shadow Credentials

Au-delà du Kerberoasting et du DCSync, BloodHound identifie d'autres chemins d'attaque avancés :

AS-REP Roasting cible les comptes dont le flag DONT_REQ_PREAUTH est activé. Ces comptes répondent aux requêtes AS-REQ sans pré-authentification, permettant de récupérer un blob chiffré avec le hash du mot de passe, craquable offline. BloodHound marque ces comptes avec la propriété dontreqpreauth: true.

Shadow Credentials exploite l'attribut msDS-KeyCredentialLink. Si un attaquant possède les droits d'écriture sur cet attribut (via GenericWrite ou GenericAll), il peut ajouter sa propre clé publique et s'authentifier en tant que cette identité via PKINIT. BloodHound CE identifie ces permissions comme des arêtes AddKeyCredentialLink.

7. Défenses : identifier et remédier les chemins d'attaque

7.1 Le modèle de Tiering (PAW / ESAE)

Le modèle de tiering (ou Enhanced Security Admin Environment -- ESAE) est la stratégie défensive la plus efficace pour éliminer les chemins d'attaque. Le principe est de segmenter l'infrastructure en trois niveaux :

Tier	Périmètre	Exemples d'objets	Règle fondamentale
Tier 0	Contrôle du domaine	Domain Controllers, KRBTGT, DA, EA, Schema Admins	Aucune relation de contrôle depuis Tier 1 ou 2
Tier 1	Serveurs et applications	Serveurs membres, comptes de service, admins serveur	Aucune relation de contrôle depuis Tier 2
Tier 2	Postes de travail et utilisateurs	Workstations, utilisateurs standard, helpdesk	Point d'entrée initial des attaquants

BloodHound est l'outil idéal pour valider l'implémentation du tiering. La requête suivante identifie les violations de tiering (relations cross-tier) :

// Violations de tiering : chemins de Tier 2 vers Tier 0
MATCH p=shortestPath(
  (source)-[*1..]->(target:Group {name: "DOMAIN ADMINS@CORP.LOCAL"})
)
WHERE NOT (source)-[:MemberOf*1..]->(:Group {admincount: true})
  AND labels(source) IN [["User"], ["Computer"]]
  AND source.enabled = true
RETURN source.name, labels(source), length(p) as PathLength
ORDER BY PathLength ASC
LIMIT 50

7.2 Stratégie de remédiation par priorité

La remédiation des chemins d'attaque doit suivre une approche méthodique basée sur l'impact maximum avec l'effort minimum. Nous recommandons la stratégie suivante :

Phase 1 -- Quick Wins (semaine 1-2) :

• Supprimer les droits DCSync non légitimes (impact immédiat, effort minimal)
• Désactiver les comptes avec DONT_REQ_PREAUTH ou retirer le flag
• Supprimer les SPN orphelins sur les comptes utilisateurs
• Retirer les sessions actives non autorisées sur les Domain Controllers

Phase 2 -- Remédiation structurelle (semaine 3-8) :

• Migrer les comptes de service vers des gMSA
• Nettoyer les ACL abusives sur les OU (GenericAll, WriteDacl, WriteOwner)
• Implémenter LAPS sur tous les postes et serveurs
• Revoir les appartenances aux groupes à privilèges (AdminCount audit)

Phase 3 -- Architecture (mois 3-6) :

• Implémenter le modèle de tiering complet
• Déployer des Privileged Access Workstations (PAW) pour les administrateurs Tier 0
• Configurer les Authentication Policies et Silos pour isoler les comptes Tier 0
• Mettre en place le monitoring continu avec des collectes BloodHound régulières

7.3 Monitoring continu avec BloodHound

La remédiation n'est pas un événement ponctuel mais un processus continu. Nous recommandons d'intégrer BloodHound dans le cycle de monitoring sécurité :

• Collecte hebdomadaire : exécuter SharpHound/RustHound une fois par semaine (planification via tâche planifiée ou cron)
• Dashboard de métriques : suivre l'évolution du nombre de chemins vers DA, du nombre de Kerberoastable users, et des violations de tiering semaine après semaine
• Alertes sur régression : détecter l'apparition de nouveaux chemins d'attaque (nouveau GenericAll accordé, nouveau SPN ajouté, etc.)
• Intégration SIEM : corréler les données BloodHound avec les logs SOC/SIEM pour une détection proactive

8. BloodHound dans le workflow pentest

8.1 Intégration dans la méthodologie d'audit

BloodHound s'intègre à chaque phase d'un pentest Active Directory. Voici notre workflow optimisé :

Phase de reconnaissance (jour 1) : Dès l'obtention d'un accès authentifié au domaine, lancer une collecte SharpHound -c All. Analyser les résultats pour identifier les chemins prioritaires et planifier la stratégie d'exploitation.

Phase d'exploitation (jours 2-4) : Suivre les chemins identifiés par BloodHound. À chaque nouveau compte compromis, relancer une collecte de sessions (-c Session) pour mettre à jour le graphe avec les nouvelles sessions disponibles. Le graphe s'enrichit à chaque pivot.

Phase de post-exploitation (jours 4-5) : Utiliser BloodHound pour documenter les chemins exploités, identifier les chemins alternatifs, et préparer les recommandations de remédiation.

8.2 Combinaison avec d'autres outils

BloodHound est encore plus puissant quand combiné avec d'autres outils de l'écosystème pentest AD :

Outil	Fonction	Synergie avec BloodHound
Impacket	Suite d'outils réseau Python	secretsdump.py pour DCSync, GetNPUsers.py pour AS-REP roasting
Rubeus	Manipulation Kerberos	Kerberoasting, delegation abuse sur les comptes identifiés par BH
Mimikatz	Credential harvesting	Extraction credentials sur les machines identifiées (HasSession)
Certipy	Attaques AD CS	ESC1-ESC8 sur les templates identifiés dans le graphe
CrackMapExec	Exécution latérale	Validation des chemins AdminTo identifiés par BloodHound
Hashcat	Cracking de hashes	Cracking des tickets Kerberos des comptes Kerberoastable

9. BloodHound vs PingCastle : complémentarité des approches

9.1 Philosophies différentes

BloodHound et PingCastle sont souvent comparés, mais ils répondent à des besoins différents et sont en réalité complémentaires :

Critère	BloodHound CE	PingCastle
Approche	Graphe de relations	Score de risque global
Focus	Chemins d'attaque exploitables	Conformité et bonnes pratiques
Audience principale	Pentesters, Red Team	Auditeurs, RSSI, Blue Team
Output	Graphe interactif + requêtes Cypher	Rapport HTML avec score (0-100)
Données collectées	Relations, sessions, ACL	Configuration, GPO, trusts, anomalies
Installation	Docker (Neo4j + PostgreSQL)	Exécutable standalone (.exe)
Licence	Apache 2.0 (Community Edition)	Gratuit (limitations) / Commercial
Force principale	Visualisation des chemins composites	Vue d'ensemble rapide du niveau de sécurité

9.2 Workflow combiné recommandé

Pour un audit AD complet, nous utilisons les deux outils de manière séquentielle :

1. PingCastle en premier : obtenir le score global, identifier les catégories de risque (Privileged Accounts, Trusts, Anomalies, Stale Objects). Le rapport PingCastle fournit un contexte rapide sur la maturité sécurité de l'AD.
2. BloodHound ensuite : approfondir les risques identifiés par PingCastle. Par exemple, si PingCastle signale des "Privileged Accounts with old passwords", BloodHound révèle si ces comptes ont des chemins vers des objets critiques.
3. Corrélation des résultats : combiner les recommandations des deux outils pour prioriser la remédiation. Un problème signalé par les deux outils est plus critique qu'un problème identifié par un seul.

10. Checklist d'audit Active Directory avec BloodHound

Cette checklist synthétise les points de contrôle essentiels à vérifier lors d'un audit AD avec BloodHound. Chaque point correspond à une requête Cypher ou une analyse spécifique dans l'interface :

Contrôles Tier 0 (Critiques)

• Nombre de membres (directs et transitifs) de Domain Admins, Enterprise Admins, Schema Admins
• Comptes avec droits DCSync non légitimes
• Sessions de comptes non Tier-0 sur les Domain Controllers
• Comptes dans AdminSDHolder sans justification
• Ancienneté du mot de passe KRBTGT (doit être changé tous les 180 jours)

Contrôles Kerberos

• Nombre de comptes Kerberoastable (hasspn=true)
• Comptes Kerberoastable avec chemins vers DA
• Ancienneté des mots de passe des comptes de service (> 365 jours = risque)
• Comptes avec DONT_REQ_PREAUTH (AS-REP roasting)
• Comptes avec delegation non contrainte (unconstrained delegation)

Contrôles ACL et délégation

• Objets non admin avec GenericAll/WriteDacl/WriteOwner sur des objets Tier 0
• Délégations OU abusives (cross-tier)
• Permissions AddKeyCredentialLink sur des comptes privilégiés (Shadow Credentials)
• Groupes avec AdminTo sur plus de 50 machines (excessive local admin)

Contrôles de sessions et déplacement latéral

• Sessions d'administration sur des workstations Tier 2 (violation de tiering)
• Ordinateurs sans LAPS activé
• Chaînes AdminTo traversant les tiers
• Comptes avec sessions RDP sur plus de 10 machines simultanément

Contrôles Azure/Entra ID (si AzureHound)

• Comptes on-premises synchronisés avec droits Global Admin dans Entra ID
• Applications avec permissions excessives (Application.ReadWrite.All, etc.)
• Chemins d'attaque hybrid (on-prem vers cloud ou cloud vers on-prem)

Pour approfondir ce sujet, consultez notre outil open-source ad-security-audit qui facilite l'audit de sécurité complet d'Active Directory.

Questions frequentes