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é.