Golden Ticket est une attaque de persistance Active Directory qui consiste à forger un Ticket Granting Ticket (TGT) Kerberos arbitraire en signant celui-ci avec le hash NTLM ou les clés AES du compte de service krbtgt du domaine. Référencée sous l'identifiant T1558.001 dans le framework MITRE ATT&CK (catégorie Steal or Forge Kerberos Tickets, tactique Credential Access), cette technique a été révélée publiquement en 2014 par Benjamin Delpy via le module kerberos::golden de Mimikatz. Le Golden Ticket exploite une caractéristique fondamentale du protocole Kerberos d'Active Directory : le Key Distribution Center (KDC) ne valide pas l'existence ni le statut des comptes encodés dans un TGT — il vérifie uniquement la signature cryptographique réalisée avec la clé du compte krbtgt. Posséder ce hash permet donc à l'attaquant de fabriquer un ticket impersonnant n'importe quel utilisateur, avec n'importe quels groupes (Domain Admins, Enterprise Admins, Schema Admins), pour une durée arbitraire pouvant atteindre dix ans. Conséquence : un Golden Ticket forgé survit aux réinitialisations de mots de passe et aux désactivations de comptes, offrant une persistance Domain Admin durable tant que le hash krbtgt n'est pas régénéré deux fois consécutivement. Cette page entity-first détaille le fonctionnement Kerberos, les pré-requis (compromission krbtgt via DCSync), la fabrication avec Mimikatz, Rubeus et Impacket ticketer.py, la différence avec le Silver Ticket, la détection (Event 4769, anomalies, Defender for Identity) et les mitigations (rotation krbtgt double, AES-only).

L'essentiel à retenir sur le Golden Ticket

  • Identifiant MITRE : T1558.001 — Steal or Forge Kerberos Tickets: Golden Ticket.
  • Protocole abusé : Kerberos v5 (RFC 4120), service KDC, signature TGT avec clé du compte krbtgt.
  • Pré-requis : compromission préalable du hash NTLM ou des clés AES128/AES256 du compte krbtgt (typiquement via DCSync ou extraction NTDS.dit).
  • Outils de référence : Mimikatz (kerberos::golden), Rubeus (asktgt/golden), Impacket ticketer.py.
  • Validité par défaut : 10 ans (paramètre Mimikatz par défaut), modifiable via /endin et /renewmax.
  • Impersonation : tout utilisateur, tous groupes RID arbitraires, contournement des stratégies RBAC dépendant de l'authentification.
  • Différence Silver Ticket : Golden Ticket = TGT signé krbtgt, accès à tous services ; Silver Ticket = TGS signé hash service, accès à un service unique.
  • Persistance : survit aux changements de mots de passe utilisateurs et désactivations de comptes ; seule la rotation double de krbtgt l'invalide.
  • Détection clé : Event 4769 anomalies (mismatch domain/RID, durée anormale > MaxRenewalAge GPO, AccountName inexistant), Defender for Identity règle dédiée.
  • Mitigation : double rotation krbtgt espacée de 24-48h, configuration AES-only, monitoring 4769, modèle Tier 0, Protected Users.

Définition du Golden Ticket

Un Golden Ticket est un Ticket Granting Ticket (TGT) Kerberos forgé hors-bande par un attaquant ayant obtenu le matériel cryptographique du compte krbtgt du domaine. Contrairement à un TGT légitime émis par le Key Distribution Center (KDC) après authentification réussie d'un utilisateur, un Golden Ticket est entièrement fabriqué côté attaquant : son contenu (PAC, groupes, durée, identifiants) est arbitraire et ne reflète pas l'état réel des objets AD. La seule contrainte cryptographique est que la signature finale soit valide vis-à-vis du hash krbtgt connu de l'attaquant.

Le terme "Golden" reflète la valeur extrême de cette attaque : elle confère un accès doré, total et durable, à l'ensemble du domaine. La technique est référencée par MITRE ATT&CK sous le code T1558.001 dans la catégorie Steal or Forge Kerberos Tickets, sous-technique de T1558, et figure parmi les attaques de persistance les plus utilisées dans les compromissions AD documentées par les CSIRT et CERT depuis 2015.

Le Golden Ticket se distingue du Silver Ticket (T1558.002) par la nature du ticket forgé : le Golden Ticket est un TGT, c'est-à-dire un ticket qui permet ensuite de demander des Service Tickets (TGS) auprès du KDC pour n'importe quel service du domaine ; le Silver Ticket est directement un TGS forgé pour un service unique, ne sollicitant pas le KDC mais limité à ce service. Le Golden Ticket est donc universel et persistant, tandis que le Silver Ticket est furtif et ciblé.

Histoire et contexte d'apparition

Kerberos a été conçu au MIT dans les années 1980 et adopté par Microsoft comme socle d'authentification d'Active Directory dès Windows 2000. Le protocole repose sur un modèle de confiance centralisé où le KDC signe les tickets avec sa clé maître, partagée uniquement avec le compte krbtgt. En 2014, le chercheur français Benjamin Delpy (gentilkiwi), auteur de Mimikatz, intègre le module kerberos::golden à son outil et formalise publiquement l'attaque lors de Black Hat USA 2014 puis BlueHat IL 2015. Microsoft confirme qu'aucune correction n'est possible sans casser Kerberos.

Jalons historiques majeurs :

  • 2000 : Microsoft adopte Kerberos comme protocole primaire d'AD (Windows 2000).
  • 2014 : intégration de kerberos::golden dans Mimikatz, démos publiques.
  • 2014-2015 : Sean Metcalf (adsecurity.org) publie les analyses techniques de référence.
  • 2015 : script Microsoft New-KrbtgtKeys.ps1 pour la double rotation.
  • 2018 : Microsoft ATA puis Defender for Identity intègrent la détection Golden Ticket.
  • 2019 : sortie de Rubeus (Will Schroeder, GhostPack), implémentation .NET native.
  • 2018-2024 : campagnes Sandworm (GRU/APT44), Volt Typhoon, ransomware operators (Conti, LockBit) documentés exploitant Golden Ticket post-DCSync.

Principe technique : Kerberos, KDC et le compte krbtgt

Pour comprendre le Golden Ticket, il faut maîtriser le flux Kerberos d'authentification AD. Le protocole Kerberos v5 implémenté par Microsoft repose sur trois acteurs : le client (utilisateur ou machine), le Key Distribution Center (KDC) hébergé sur chaque contrôleur de domaine, et le service cible (CIFS, HOST, LDAP, HTTP, MSSQLSvc, etc.). Le KDC se subdivise en deux composants logiques : l'Authentication Service (AS) qui émet les TGT, et le Ticket Granting Service (TGS) qui émet les Service Tickets.

Le flux standard d'authentification suit cinq étapes :

  1. AS-REQ : le client envoie une requête au KDC avec un timestamp chiffré par la clé dérivée de son mot de passe (preuve de connaissance).
  2. AS-REP : le KDC valide la requête et retourne un TGT signé avec la clé du compte krbtgt, contenant les informations d'identité et d'autorisation (PAC).
  3. TGS-REQ : le client présente son TGT au KDC pour obtenir un Service Ticket vers un service cible (ex: CIFS/fileserver01).
  4. TGS-REP : le KDC vérifie la signature krbtgt du TGT, puis émet un TGS signé avec le hash du compte de service cible.
  5. AP-REQ : le client présente le TGS au service, qui valide la signature avec son propre hash et accorde l'accès.

Le compte krbtgt est un compte machine spécial créé automatiquement à la promotion du premier DC d'un domaine. Son mot de passe (et donc le hash NTLM et les clés AES dérivées) sert à signer tous les TGT émis par les KDCs du domaine. Ce compte ne peut pas se connecter, est désactivé par défaut, et son mot de passe n'est pas changé automatiquement par les politiques GPO.

L'attaque Golden Ticket exploite une asymétrie fondamentale : le KDC fait confiance par défaut à la signature krbtgt et n'effectue aucune vérification supplémentaire (existence du compte impersonné, statut activé/désactivé, validité des groupes). Quand un attaquant fabrique un TGT signé avec la clé krbtgt qu'il possède, le KDC accepte ce TGT comme authentique et émet sans broncher des TGS pour n'importe quel service.

Pré-requis : compromission du hash krbtgt

Le seul pré-requis du Golden Ticket — mais c'est un pré-requis majeur — est la possession du hash NTLM ou des clés Kerberos AES128/AES256 du compte krbtgt. Sans ce matériel cryptographique, aucune forge n'est possible. L'obtention de ce hash constitue donc l'étape critique de la chaîne d'attaque.

Les voies d'obtention typiques sont :

  • DCSync (T1003.006) : extraction à distance via abus du protocole MS-DRSR. C'est de loin la méthode la plus utilisée car elle nécessite uniquement les permissions Replicating Directory Changes, fréquemment obtenues via Domain Admins, ACL abuse ou comptes de service hérités.
  • Extraction NTDS.dit (T1003.003) : copie offline de la base AD via ntdsutil, vssadmin ou ShadowCopy, suivie d'une extraction des hashes avec secretsdump.py ou DSInternals.
  • Extraction LSASS sur DC (T1003.001) : si l'attaquant dispose d'un accès interactif sur un DC (compromission Domain Admin), il peut dumper LSASS et extraire les clés Kerberos en mémoire.
  • DCShadow (T1207) : technique avancée où l'attaquant enregistre temporairement un faux DC pour répliquer le compte krbtgt — nécessite des privilèges très élevés et laisse moins de traces.
  • Compromission de sauvegarde : récupération d'une sauvegarde de DC ou export NTDS sur un partage non sécurisé.

Une fois le hash obtenu, la forge du Golden Ticket peut être exécutée depuis n'importe quelle machine, sans aucune connexion réseau immédiate au DC : la fabrication est purement cryptographique et locale. Le ticket forgé est ensuite injecté en mémoire (Pass-the-Ticket) ou utilisé via un fichier .kirbi/.ccache.

Fabrication avec Mimikatz : kerberos::golden

L'implémentation de référence reste le module kerberos::golden de Mimikatz. Commande type :

  • kerberos::golden /domain:corp.local /sid:S-1-5-21-... /rc4:<ntlm_krbtgt> /id:500 /user:Administrator /groups:512,513,518,519,520 /endin:600 /renewmax:10080 /ptt

Paramètres critiques :

  • /domain : nom DNS du domaine cible.
  • /sid : SID du domaine (sans RID final), via whoami /user ou Get-ADDomain.
  • /rc4 : hash NTLM krbtgt (déclenche alertes RC4-deprecated sur AD modernes).
  • /aes256 ou /aes128 : clés AES krbtgt — variantes préférées en environnements AES-only (Encryption Type 18 vs 23).
  • /id : RID impersonné (500 = Administrator).
  • /user : nom impersonné (peut être inexistant — le KDC ne vérifie pas).
  • /groups : RID des groupes injectés au PAC. Standard Domain Admin : 512, 513, 518, 519, 520.
  • /endin : durée de validité (défaut Mimikatz = 10 ans). Souvent réduit à 600 (10h) pour mimer un ticket légitime.
  • /renewmax : durée renouvellement max, à aligner sur GPO MaxRenewalAge (défaut 7 jours = 10080 min).
  • /ptt : Pass-the-Ticket — injection directe en mémoire de la session courante.
  • /ticket:<path> : sauvegarde en fichier .kirbi pour usage différé.

Ticket injecté, l'attaquant accède immédiatement à toutes ressources : dir \\dc01\c$, psexec, LDAP, RDP — sans besoin de credentials supplémentaires.

Fabrication avec Rubeus

Rubeus (Will Schroeder / GhostPack) est l'équivalent .NET natif de Mimikatz pour Kerberos, sans dépendance externe et facilement obfusqué via Cobalt Strike execute-assembly.

Commandes signature :

  • Rubeus.exe golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /rc4:<hash_krbtgt> /id:500 /groups:512,513,518,519,520 /ptt
  • Rubeus.exe golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /aes256:<aes256_krbtgt> /id:500 /endin:10:00:00 /renewmax:7d
  • Rubeus.exe ptt /ticket:golden.kirbi — injection d'un ticket pré-forgé.
  • Rubeus.exe describe /ticket:<base64> — analyse forensique d'un ticket.

Rubeus offre aussi asreproast, kerberoast, s4u pour délégation contrainte abusive, tgtdeleg — outil de prédilection des red teams modernes (CRTO, OSEP).

Fabrication avec Impacket ticketer.py

Côté Linux/Python, ticketer.py du projet Impacket (Alberto Solino, Fortra) est le standard depuis Kali ou Parrot.

Commandes signature :

  • ticketer.py -nthash <ntlm_krbtgt> -domain-sid S-1-5-21-... -domain corp.local Administrator
  • ticketer.py -aesKey <aes256_krbtgt> -domain-sid S-1-5-21-... -domain corp.local Administrator
  • ticketer.py -nthash <hash> -domain-sid S-1-5-21-... -domain corp.local -groups 512,513,518,519,520 -duration 87600 Administrator
  • ticketer.py ... -extra-sid S-1-5-21-OTHER-519 Administrator — cross-forest via SID History (T1134.005).

Le ticket est sauvegardé au format .ccache, utilisé via KRB5CCNAME pour les outils Impacket : export KRB5CCNAME=/tmp/Administrator.ccache && psexec.py -k -no-pass corp.local/Administrator@dc01.corp.local.

Propriétés du Golden Ticket : 10 ans, tous groupes, contournement RBAC

Trois propriétés distinctives expliquent la dangerosité du Golden Ticket.

Validité de 10 ans par défaut : Mimikatz force endin=87600h et renewmax=87600h. Cette durée dépasse la vie typique d'un employé ou d'un poste. Tant que le hash krbtgt n'est pas régénéré deux fois consécutives, le ticket reste valide. Cette anomalie temporelle reste l'un des indicateurs de détection les plus fiables, les tickets légitimes respectant les GPO MaxTicketAge (10h) et MaxRenewalAge (7 jours).

Injection arbitraire de groupes : le PAC contient les RIDs choisis par l'attaquant. Combinaison classique 512/513/518/519/520 = Domain Admins + Enterprise Admins + Schema Admins. Le RID 519 peut aussi être injecté en SID History pour franchir trusts inter-domaines/inter-forêts.

Contournement RBAC : toutes les autorisations AD/Windows reposent sur SID + groupes (PAC). Le Golden Ticket fournit un PAC entièrement contrôlé par l'attaquant, contournant ACL NTFS/Share, permissions LDAP, autorisations SQL Server auth Windows, délégations IIS. Seules les protections cryptographiques indépendantes (BitLocker TPM, MFA cloud) résistent. Le ticket survit aux changements de mot de passe et aux désactivations de comptes car il ne nécessite pas de re-validation auprès du KDC.

Différence avec Silver Ticket et autres forges Kerberos

Le paysage des forges Kerberos comporte plusieurs variantes :

Silver Ticket (T1558.002) : forge directe d'un TGS signé avec le hash du compte du service cible (et non du krbtgt). Ne sollicite pas le KDC et accède directement au service. Plus furtif (aucun Event 4768/4769) mais limité à un service unique (CIFS, HOST, LDAP, HTTP, MSSQLSvc).

Diamond Ticket : variante avancée où l'attaquant demande un TGT légitime puis modifie son PAC avec la clé krbtgt. Plus furtif (Events 4768 d'origine légitimes). Implémenté dans Rubeus (diamond).

Sapphire Ticket : variante 2022 (Charlie Bromberg) combinant S4U2self avec demande forgée pour produire un TGT au PAC légitime côté KDC.

Skeleton Key (T1556.001) : patch LSASS sur DC pour accepter un mot de passe maître. Persistance locale plus invasive.

SID History abuse : injection de SID externe pour franchir trust inter-forêts (en exploitant l'absence de SID Filtering).

Détection : Event 4769 et anomalies PAC

La détection native du Golden Ticket sous Windows repose principalement sur l'Event ID 4769 du journal Security ("A Kerberos service ticket was requested") généré par chaque KDC à chaque demande TGS-REQ. Bien qu'un Golden Ticket forgé hors-bande ne génère pas d'Event 4768 (TGT request), toute utilisation du Golden Ticket pour demander un Service Ticket génère obligatoirement un Event 4769 — c'est cette friction qui ouvre la porte à la détection.

Les anomalies caractéristiques d'un Event 4769 issu d'un Golden Ticket :

  • Absence d'Event 4768 préalable : aucune authentification AS-REQ correspondant à l'utilisateur source dans la fenêtre temporelle du TGT (typiquement aucune trace dans les 10 dernières heures).
  • Mismatch domain / RID : le SID encodé dans le PAC ne correspond pas à un compte AD existant, ou l'utilisateur référencé n'a pas le RID correspondant.
  • AccountName inexistant : le champ TargetUserName/SubjectUserName référence un utilisateur supprimé ou jamais existant.
  • Durée anormale : TicketOptions ou champs internes indiquent une validité supérieure à MaxTicketAge GPO (10h par défaut) ou MaxRenewalAge (7 jours).
  • Encryption Type RC4 (0x17) : alors que l'environnement est censé être AES-only (clés Kerberos uniquement AES128/256), un ticket RC4 trahit une forge ancienne ou non mise à jour.
  • Mismatch FQDN cible : ServiceName référençant un service inhabituel ou inexistant.
  • Anomalie PAC : checksums PAC malformés ou groupes incohérents (RID 519 sur compte ordinaire).

La règle de détection canonique consiste à corréler les Events 4769 sans Event 4768 préalable pour le même utilisateur et la même session, sur une fenêtre glissante de 10h. Cette corrélation est non triviale en raison du volume (un environnement de 10 000 utilisateurs génère typiquement plusieurs millions d'Events 4769/jour), d'où l'intérêt des solutions XDR/SIEM dédiées.

Pré-requis de configuration GPO :

  • Audit Policy > Account Logon > Audit Kerberos Service Ticket Operations = Success and Failure.
  • Audit Policy > Account Logon > Audit Kerberos Authentication Service = Success and Failure (capture Events 4768).
  • Forwarding Windows Event Forwarding (WEF) ou agent SIEM (Splunk UF, Elastic Beats, Sentinel AMA).

Détection avancée : Defender for Identity, Entra Identity Protection, Sentinel

Plusieurs solutions XDR/SIEM offrent une détection comportementale Golden Ticket plus fiable que la détection brute Event 4769.

Microsoft Defender for Identity (anciennement Azure ATP) intègre depuis 2018 la règle Suspected Golden Ticket usage avec heuristiques : encryption downgrade (RC4 en environnement AES), nonexistent account, time anomaly (durée > MaxTicketAge), RBCD inconsistency. Intégration native avec Microsoft Defender XDR.

Microsoft Entra Identity Protection ne détecte pas directement le Golden Ticket on-premise mais corrèle les signaux hybrides (connexions Entra Connect anormales, token theft cloud).

Microsoft Sentinel propose des analytic rules KQL natives, exemple :

  • SecurityEvent | where EventID == 4769 | where TicketEncryptionType == "0x17" | join kind=leftanti (SecurityEvent | where EventID == 4768) on TargetUserName | where TimeGenerated > ago(10h)

Splunk ES, Elastic Security, QRadar, Exabeam, ArcSight incluent des règles équivalentes basées sur 4768/4769. Zeek, Vectra, Darktrace, ExtraHop automatisent l'analyse réseau Kerberos.

Mitigation : double rotation krbtgt et configuration AES-only

La défense contre le Golden Ticket repose sur trois piliers : empêcher l'obtention du hash krbtgt (cf. mitigation DCSync), invalider rapidement les Golden Tickets potentiels via rotation, et durcir la configuration Kerberos pour faciliter la détection.

Double rotation krbtgt : le script Microsoft New-KrbtgtKeys.ps1 automatise la rotation du compte krbtgt. La première rotation change le mot de passe krbtgt et invalide tous les TGT existants utilisant l'ancien hash — mais Active Directory conserve l'ancienne clé en mémoire pendant un cycle de réplication pour ne pas casser les sessions en cours. La seconde rotation, effectuée 24 à 48 heures après la première (le temps que la réplication soit complète sur tous les DCs et que l'ancien hash soit définitivement écrasé), invalide définitivement tout Golden Ticket forgé depuis l'ancien hash. Calendrier recommandé : 2 rotations à 24-48h d'intervalle, tous les 6 mois, et systématiquement après tout incident de sécurité ou suspicion de compromission krbtgt.

Configuration AES-only : configuration des comptes utilisateurs et machines pour ne supporter que les clés AES128/AES256 Kerberos (attribut msDS-SupportedEncryptionTypes à 0x18 ou 0x1C, désactivation explicite RC4 via GPO Network security: Configure encryption types allowed for Kerberos). Tout Event 4769 avec TicketEncryptionType = 0x17 (RC4-HMAC) devient alors un IoC à très haute fidélité.

Modèle Tier 0/1/2 : strict, il garantit que les comptes Domain Admin (capables de DCSync krbtgt) ne sont jamais utilisés sur des stations utilisateurs. Combiné aux Authentication Policies/Silos, il empêche le vol de credentials.

Protected Users : les comptes admin membres ne peuvent pas être Pass-the-Hash, ne mettent pas en cache leurs credentials, et utilisent uniquement Kerberos AES.

Monitoring 4769 corrélé 4768 : déploiement d'une règle SIEM corrélant Event 4769 sans Event 4768 préalable, alerte sur les anomalies. Forwarding centralisé indispensable.

Audit ACL DRS : voir la mitigation DCSync — empêcher l'extraction du hash krbtgt en amont.

Microsoft Defender for Identity : déploiement de capteurs sur tous les DCs pour télémétrie Kerberos centralisée.

Indicateurs de compromission (IoC) typiques

Lors d'une réponse à incident, plusieurs IoC orientent vers un Golden Ticket :

  • Event 4769 sans Event 4768 préalable pour le même TargetUserName sur les 10 dernières heures.
  • TicketEncryptionType 0x17 (RC4) dans un environnement AES-only.
  • TargetUserName inexistant, supprimé ou jamais créé.
  • Mismatch SID/RID : PAC ne correspondant pas au RID du compte.
  • Process Sysmon Event 1 : mimikatz.exe, Rubeus.exe, ticketer.py, SafetyKatz.exe.
  • Fichiers .kirbi ou .ccache sur disque : golden.kirbi, Administrator.ccache.
  • Volumétrie 4624 type 3 avec compte Administrator depuis station user.
  • Persistance dans le temps : usage du même TGT sur plusieurs jours/semaines.

La corrélation temporelle (DCSync krbtgt + BloodHound + Golden Ticket sous 24-48h + Pass-the-Ticket) est le pattern canonique des compromissions APT et ransomware documentées dans Mandiant M-Trends et CrowdStrike Global Threat Report.

CVE et incidents notables : Sandworm, Volt Typhoon, ransomware

Le Golden Ticket, à l'instar du DCSync, n'a aucun CVE associé car il abuse une fonctionnalité légitime de Kerberos. Microsoft ne peut pas le "patcher" sans casser le protocole. Cependant, plusieurs CVE conduisent vers Golden Ticket par escalade :

  • CVE-2020-1472 (Zerologon) : exploitation de Netlogon pour réinitialiser le mot de passe machine d'un DC, puis DCSync krbtgt, puis Golden Ticket.
  • CVE-2021-42278 / CVE-2021-42287 (NoPac/SamAccountName spoofing) : abus de la promotion implicite SAM/UPN pour obtenir un TGT impersonnant un Domain Admin, équivalent fonctionnel du Golden Ticket.
  • CVE-2022-26923 (Certifried/ADCS) : abus de modèles de certificat ADCS pour obtenir un TGT Domain Admin.

Les incidents notables exploitant Golden Ticket :

  • Sandworm (GRU/APT44) : campagnes 2018-2024 contre des cibles ukrainiennes et OTAN, persistance multi-années via Golden Ticket sur AD compromis.
  • NotPetya (2017) : usage initial via Mimikatz pour extraction krbtgt avant propagation EternalBlue.
  • SolarWinds / Solorigate (2020) : variante cloud (Golden SAML, T1606.002) inspirée du même principe sur ADFS.
  • Conti, REvil, LockBit affiliates (2021-2024) : persistance avant déploiement ransomware, double extorsion.
  • Volt Typhoon (2023-2026) : APT chinois, ciblage CNI américaines avec persistance discrète multi-mois via Golden Ticket post-NoPac.
  • FIN6, Indrik Spider (Evil Corp) : opérations cybercriminelles documentées par CrowdStrike et Mandiant.

Notez que la défense Golden Ticket est étroitement liée à la défense DCSync : couper l'accès au hash krbtgt en amont (audit ACL DRS, Tier 0, MDI) est plus efficace que de chercher à invalider les tickets a posteriori.

Mapping MITRE ATT&CK et frameworks de référence

Le Golden Ticket est officiellement référencé sous T1558.001, sous-technique de T1558 (Steal or Forge Kerberos Tickets), tactique Credential Access (TA0006). La fiche attack.mitre.org/techniques/T1558/001 documente :

  • Procedure examples : APT32, APT41, FIN6, Indrik Spider, Sandworm Team, Volt Typhoon, Wizard Spider.
  • Software : Mimikatz (S0002), Empire (S0363), Impacket (S0357), Rubeus.
  • Mitigations : M1015, M1026, M1027, M1041.
  • Detections : DS0026, DS0028, DS0002.

Frameworks complémentaires : NIST SP 800-53 Rev.5 (AC-2, AC-6, AU-2, IA-2, SI-4), CIS Controls v8 (Controls 5, 6, 8, 16), ANSSI guide ADM (rotation krbtgt, AES-only), Microsoft SPA (Tier model, Authentication Policies, Protected Users), MITRE D3FEND (D3-CR Credential Rotation).

Kits red team et frameworks offensifs

L'écosystème offensif Golden Ticket s'est enrichi avec l'industrialisation des opérations red team. Au-delà du trio canonique (Mimikatz, Rubeus, ticketer.py), de nombreux kits intègrent la technique :

  • Cobalt Strike : Aggressor scripts pour Golden Ticket via BOF, execute-assembly de Rubeus en mémoire pure.
  • Empire / Starkiller : module PowerShell credentials/mimikatz/golden_ticket.
  • BloodHound : voir notre guide BloodHound — chemins vers compte capable de DCSync krbtgt.
  • SafetyKatz, SharpKatz : portages .NET de Mimikatz, exécution via execute-assembly.
  • NetExec (ex-CrackMapExec) : automatisation de la chaîne DCSync + Golden Ticket.
  • Impacket : suite complète Linux (ticketer.py, getTGT.py, psexec.py).
  • Sliver, Mythic, Brute Ratel : C2 modernes supportant la gestion de tickets Kerberos.

Côté défense : PingCastle, Purple Knight (Semperis), BloodHound CE/Enterprise, ADRecon, et Microsoft Defender for Identity + Sentinel pour la détection runtime.

FAQ — Questions fréquentes sur le Golden Ticket

À quelle fréquence faut-il faire tourner le compte krbtgt ?

La recommandation Microsoft et ANSSI est une double rotation tous les 6 mois, avec une seconde rotation 24 à 48 heures après la première (le temps de propagation complète de la réplication sur tous les DCs). Cette périodicité limite la fenêtre d'exploitation d'un Golden Ticket forgé à 6 mois maximum dans le pire cas. Après tout incident suspect (compromission Domain Admin, DCSync détecté, fuite de credentials d'admin), une double rotation immédiate est impérative. Le script Microsoft New-KrbtgtKeys.ps1 automatise la procédure et inclut les vérifications de réplication. Attention : trop de rotations rapprochées peuvent générer des problèmes Kerberos transitoires sur les comptes machine et services. La rotation doit être planifiée avec validation des sauvegardes AD préalables et tests sur environnement représentatif.

Microsoft Defender for Identity détecte-t-il vraiment le Golden Ticket ?

Oui, Defender for Identity (anciennement Azure ATP) inclut depuis 2018 plusieurs règles natives ciblant le Golden Ticket : Suspected Golden Ticket usage (encryption downgrade) détecte les TGT RC4 dans environnements AES, Suspected Golden Ticket usage (nonexistent account) détecte les TGT impersonnant des comptes inexistants, Suspected Golden Ticket usage (ticket anomaly) détecte les anomalies de durée et de PAC. La détection est très fiable car MDI dispose de la télémétrie Kerberos complète des DCs et corrèle avec d'autres signaux (DCSync préalable, énumération LDAP). En 2026, la solution est intégrée dans Microsoft Defender XDR et fournit également des recommandations proactives sur la configuration Kerberos. MDI nécessite l'installation de capteurs sur les DCs et une licence E5/A5 ou Defender for Identity standalone.

Quelle est la contre-mesure ultime contre le Golden Ticket ?

Aucune contre-mesure unique : la défense est nécessairement défense en profondeur. Piliers indispensables : (1) empêcher l'extraction du hash krbtgt via mitigation DCSync (audit ACL DRS, Tier 0), (2) double rotation krbtgt tous les 6 mois et après incident, (3) configuration Kerberos AES-only (msDS-SupportedEncryptionTypes, désactivation RC4), (4) détection comportementale via Defender for Identity, Sentinel, Splunk ES sur Events 4768/4769, (5) isolation des comptes privilégiés via Authentication Policies/Silos et Protected Users, (6) audits réguliers via PingCastle, Purple Knight, BloodHound CE.

Que faire après un Golden Ticket détecté ?

Protocole strict d'urgence : (1) isolation des hosts compromis et conservation forensique mémoire, (2) double rotation krbtgt immédiate sous 24-48h pour invalider tous les Golden Tickets actifs, (3) réinitialisation des mots de passe de tous les comptes Tier 0 et comptes de service critiques, (4) investigation forensique sur la chaîne amont (BloodHound, DCSync, Kerberoasting, ADCS, NoPac, Zerologon), (5) hunt sur tous les DCs pour autres persistances (Skeleton Key, AdminSDHolder, DCShadow), (6) révocation des certificats ADCS émis pendant la fenêtre de compromission, (7) communication CSIRT/CERT et notification ANSSI/CNIL si données personnelles compromises.

Le Golden Ticket fonctionne-t-il sur Microsoft Entra ID (Azure AD) ?

Non, le Golden Ticket est strictement une attaque Active Directory on-premises reposant sur Kerberos v5 et le compte krbtgt local. Entra ID utilise OAuth 2.0, OpenID Connect et SAML. Des attaques équivalentes existent dans le cloud : Golden SAML (T1606.002) compromettant le certificat ADFS, token theft (Pass-the-PRT, Pass-the-Cookie), abus d'application enterprise. En architecture hybride, un Golden Ticket on-premise compromettant le compte MSOL_xxx peut atteindre Entra ID par rebond. La défense passe par la séparation des privilèges hybrides, comptes cloud-only pour Global Admins, et MFA résistant au phishing (FIDO2).

Pour aller plus loin : ressources et articles approfondis

Pour approfondir la maîtrise des attaques Active Directory et la défense contre le Golden Ticket, consultez nos guides spécialisés :

Ressources externes officielles :