Golden Ticket : Les Clés de Votre Domaine

Qu'est-ce qu'un Golden Ticket ?

Un Golden Ticket est un Ticket Granting Ticket (TGT) Kerberos forgé qui donne à un attaquant un accès illimité et persistant à toutes les ressources d'un domaine Active Directory, sans avoir besoin du mot de passe d'un utilisateur.

L'attaque exploite le compte KRBTGT, dont le hash est utilisé pour signer chaque TGT émis dans le domaine. Si un attaquant obtient ce hash, il peut fabriquer des TGT valides pour n'importe quel utilisateur, y compris les administrateurs du domaine, avec n'importe quelle appartenance à des groupes et n'importe quelle date d'expiration.

Le Golden Ticket est l'une des techniques post-exploitation les plus graves dans Active Directory : un seul hash volé se traduit par un contrôle illimité du domaine.

Comment ca fonctionne

L'authentification Kerberos repose sur un tiers de confiance : le Key Distribution Center (KDC), qui s'exécute sur chaque contrôleur de domaine.

Le flux normal :

1. Un utilisateur s'authentifie auprès du KDC et reçoit un TGT, signé avec le hash KRBTGT.
2. L'utilisateur présente le TGT pour obtenir des Service Tickets (TGS) pour des ressources spécifiques.
3. Les services valident le TGS et accordent l'accès.

Le compte KRBTGT est la racine de confiance pour chaque TGT du domaine. Aucun service ne valide les TGT directement auprès du KDC au moment de leur utilisation : ils font confiance à la signature. Un TGT forgé, signé avec le vrai hash KRBTGT, est donc indiscernable d'un ticket légitime.

⚠️ Point clé : Le KDC n'est consulté que lors de l'émission d'un TGT. Une fois émis, aucune vérification supplémentaire n'a lieu. Un ticket forgé contourne entièrement le KDC.

La Chaine d'Attaque

Etape 1 - Obtenir les droits Domain Admin (ou équivalent)

L'attaquant doit atteindre un niveau de privilège permettant de lire le hash KRBTGT. Cela signifie généralement compromettre un contrôleur de domaine directement, ou abuser d'un chemin comme DCSync.

Etape 2 - Extraire le Hash KRBTGT via DCSync

L'attaquant exécute une attaque DCSync avec Mimikatz ou Impacket pour extraire le hash NTLM du KRBTGT sans toucher le disque du DC :

# Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket (depuis Linux)
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:[email protected]

Etape 3 - Forger le Golden Ticket

Avec le hash KRBTGT et le SID du domaine, l'attaquant fabrique un TGT pour n'importe quel utilisateur :

# Mimikatz — forger et injecter directement dans la session courante
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH /ptt

Paramètres clés :

Etape 4 - Acces Total et Persistance

Le TGT forgé est accepté par tous les services du domaine. L'attaquant peut désormais :

• Accéder à n'importe quel partage de fichiers, session RDP, endpoint WMI ou service DCOM
• Créer de nouveaux comptes backdoor et les ajouter à des groupes privilégiés
• Pousser des GPO malveillantes sur toutes les machines
• Persister indéfiniment : les réinitialisations de mots de passe des comptes utilisateurs n'ont aucun effet

⚠️ Critique : Un Golden Ticket reste valide jusqu'à ce que le mot de passe KRBTGT soit changé deux fois. Réinitialiser tous les autres comptes du domaine ne change rien.

Détection

Les Golden Tickets sont difficiles à détecter car les TGT forgés ressemblent à du trafic Kerberos légitime. La détection repose sur l'analyse d'anomalies plutôt que sur la corrélation directe d'événements.

Event IDs Windows

Anomalies Comportementales

• Durée de vie du ticket supérieure à 10 heures - le maximum par défaut de Microsoft est 10h ; les tickets forgés ont souvent une durée de vie de plusieurs années
• Noms d'utilisateurs inexistants dans les événements Kerberos - les Golden Tickets peuvent être forgés pour des comptes qui n'existent pas dans l'AD
• Chiffrement RC4 alors que le domaine impose AES uniquement
• Demande TGS sans AS-REQ préalable - une demande de ticket de service sur un DC sans demande de TGT correspondante est un indicateur fort
• Mismatch de SID - le SID intégré dans le ticket ne correspond à aucun compte AD réel

Requete SIEM (Elastic KQL)

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

💡 Conseil : Imposez le chiffrement AES uniquement sur l'ensemble du domaine. Tout trafic Kerberos RC4 devient alors une alerte de haute confiance.

Remédiation

⚠️ Prérequis : Identifiez et containez le vecteur de compromission avant de changer le KRBTGT. Si l'attaquant dispose toujours des droits DCSync, la rotation ne sert à rien.

Réponse Immédiate

Changer le mot de passe KRBTGT deux fois, avec un délai entre les rotations égal à la durée de vie maximale des tickets Kerberos (par défaut : 10 heures).

Utilisez le script officiel de Microsoft, qui gère automatiquement les vérifications de réplication entre DCs :

# Télécharger et exécuter New-KrbtgtKeys.ps1
# https://github.com/microsoft/New-KrbtgtKeys.ps1

.\New-KrbtgtKeys.ps1 -Mode ModeSingle
# Attendre au moins 10 heures
.\New-KrbtgtKeys.ps1 -Mode ModeSingle

Durcissement

Comment EtcSec Détecte Cela

EtcSec vérifie les conditions qui rendent les attaques Golden Ticket possibles et persistantes dans votre environnement.

La détection GOLDEN_TICKET_RISK signale les environnements où le mot de passe du compte KRBTGT n'a pas été changé récemment, un indicateur direct qu'un Golden Ticket forgé antérieurement est peut-être encore valide.

Contrôles associés qui aggravent le risque :

• WEAK_KERBEROS_POLICY - paramètres de durée de vie et de renouvellement des tickets Kerberos qui étendent la fenêtre d'exposition
• KERBEROS_RC4_FALLBACK - chiffrement RC4 encore autorisé, ce qui facilite le forgeage et complique la détection
• UNCONSTRAINED_DELEGATION - comptes avec délégation non contrainte pouvant être utilisés pour capturer des TGT, précurseur courant des attaques Golden Ticket

ℹ️ Note : EtcSec vérifie automatiquement ces vulnérabilités lors de chaque audit AD. Lancez un audit gratuit pour vérifier si votre environnement est exposé.

Priorites de Revue

Golden Ticket : Les Clés de Votre Domaine doit etre traite comme une exposition reelle dans votre environnement Active Directory, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels groupes privilegies, comptes de service, ACL, liens GPO, trusts, delegations, templates de certificats et postes d'administration sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.

Controles Adjacents a Revoir

Quand un attaquant arrive dans votre environnement Active Directory, il ne s'arrete presque jamais au premier point faible. Autour de Golden Ticket : Les Clés de Votre Domaine, il cherche en general a enchainer avec comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.

Preuves et telemetry a collecter

Une bonne reponse a Golden Ticket : Les Clés de Votre Domaine repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre environnement Active Directory. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.

Lectures Connexes

Pour traiter ce sujet correctement, reliez-le a Délégation Kerberos : Non Contrainte à RBCD, Kerberoasting : Cracker les Mots de Passe des Comptes de Service, Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, Attaques de Confiance AD : Du Domaine Enfant à la Racine et AS-REP Roasting : Collecter des Hashes Sans Credentials. Cet ensemble montre comment les memes erreurs d'identite, de privileges et de configuration se combinent dans une revue reelle au lieu d'apparaitre comme des constats isoles.

• Délégation Kerberos : Non Contrainte à RBCD
• Kerberoasting : Cracker les Mots de Passe des Comptes de Service
• Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin
• Attaques de Confiance AD : Du Domaine Enfant à la Racine
• AS-REP Roasting : Collecter des Hashes Sans Credentials

Ces liens internes gardent la remediation centree sur le chemin d'attaque complet et pas seulement sur un controle pris separement.

Validation Operationnelle

Avant de clore la revue, rejouez les controles qui ont revele le risque et confirmez que le chemin d'abus n'existe plus du point de vue d'un attaquant. Verifiez les identites, privileges, exceptions, dependances et preuves de remediations en production plutot que de vous limiter a la documentation. Cette validation finale transforme une correction ponctuelle en reduction de risque durable.