Golden Ticket : attaque Kerberos par faux TGT

Le Golden Ticket désigne une attaque Kerberos consistant à forger un faux TGT (Ticket Granting Ticket) signé avec le hash NTLM du compte KRBTGT du domaine Active Directory. Ce compte est le seul à signer tous les tickets Kerberos du domaine. Un attaquant qui obtient ce hash peut créer un TGT arbitraire, pour n'importe quel utilisateur, avec n'importe quel groupe ou privilège, y compris Domain Admins. Le ticket forgé est localement valide sans interaction avec un contrôleur de domaine, car le KDC (Key Distribution Center) valide la signature cryptographique, pas le contenu. L'attaque a été popularisée par Benjamin Delpy via Mimikatz. Elle est classée dans les techniques de persistence et d'élévation de privilèges (MITRE ATT&CK T1558.001). Sa dangerosité réside dans sa durée de vie configurable : un Golden Ticket peut être émis avec une validité de dix ans, rendant la compromission très difficile à éradiquer sans réinitialiser KRBTGT deux fois de suite sur l'ensemble du domaine.

La détection d'un Golden Ticket est difficile car le ticket forgé est cryptographiquement valide. Plusieurs indicateurs doivent alerter le SOC. L'événement Windows 4769 (demande de service Kerberos) avec un ticket présentant une durée de vie anormalement longue est un signal fort. L'événement 4768 peut être absent si l'attaquant injecte directement le TGT sans passer par le KDC. Un écart entre la durée de vie du TGT et la politique Kerberos du domaine (MaxTicketAge, généralement dix heures) est détectable via les logs du contrôleur de domaine. Microsoft Defender for Identity (anciennement ATA) dispose d'une règle native 'Golden Ticket activity' qui corrèle ces anomalies. Côté SIEM, une règle de corrélation doit cibler les tickets Kerberos dont la valeur EncTicketPart.endtime dépasse le seuil configuré en GPO. L'outil Kerberoast Detector et les règles Sigma dédiées (sigma/rules/windows/builtin/security/win_security_susp_kerberos_manipulation) complètent ce dispositif. La présence de Mimikatz ou Rubeus dans les artefacts mémoire (via EDR) reste souvent le seul signal fiable en post-exploitation immédiate.

L'exploitation d'un Golden Ticket nécessite trois prérequis : le SID du domaine, le nom de domaine NetBIOS, et le hash NTLM du compte KRBTGT. Ces éléments s'obtiennent avec Mimikatz via la commande 'lsadump::dcsync /user:krbtgt' après compromission d'un compte Domain Admin. La forge du ticket s'effectue avec 'kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt: /ticket:golden.kirbi'. Le ticket est ensuite injecté en mémoire avec 'kerberos::ptt golden.kirbi', permettant un mouvement latéral immédiat vers tout service du domaine. Rubeus propose une syntaxe équivalente plus discrète : 'Rubeus.exe golden /rc4: /domain:... /sid:... /user:...' suivi d'un 'ptt'. Côté contre-mesures, la double réinitialisation du mot de passe KRBTGT (deux rotations espacées d'au moins dix heures) invalide tous les tickets forgés existants. Le principe du tiering AD (isolation des comptes Tier 0) limite l'accès initial au hash KRBTGT. La surveillance des DCSyncs non autorisés (événement 4662 sur l'objet domaine) est indispensable pour détecter la phase de collecte précédant la forge.