Golden ticket vs silver ticket : création, portée et détection

Concept

Dans les attaques Kerberos de post-exploitation, la forge de tickets permet à un attaquant de s’affranchir totalement du processus d’authentification standard pour générer des preuves d’accès arbitraires :

Golden ticket (ticket d’or) : l’attaquant usurpe l’identité du KDC lui-même. En utilisant la clé symétrique du compte krbtgt, il fabrique un TGT valide contenant un PAC sur-mesure (ex: ajoutant le RID 512 Domain Admins).
Silver ticket (ticket d’argent) : l’attaquant usurpe le service d’authentification vis-à-vis d’une application spécifique (ex: CIFS, MSSQL, HTTP). En utilisant la clé du compte exécutant ce service, il fabrique directement le TGS final présenté à l’application.

Pourquoi c’est important en DFIR

Savoir différencier un Golden Ticket d’un Silver Ticket est déterminant pour orienter la réponse à incident :

Périmètre de compromission :
- Découvrir un Golden Ticket signifie que le compte krbtgt a été volé $\rightarrow$ le domaine entier est compromis au niveau Tier 0.
- Découvrir un Silver Ticket signifie que seul le secret de ce serveur précis a été compromis $\rightarrow$ le domaine n’est pas nécessairement tombé.
Visibilité dans les journaux :
- Le Golden Ticket génère des demandes de TGS légitimes en apparence auprès des DC (Event ID 4769), mais aucun Event ID 4768 (demande de TGT) ne précède ces demandes !
- Le Silver Ticket est présenté directement au serveur de ressource. Aucun événement n’apparaît sur les contrôleurs de domaine. Seul le serveur cible consigne l’Event ID 4624.
Procédure de remédiation :
- Pour révoquer un Golden Ticket : il faut réinitialiser le mot de passe du compte krbtgt deux fois consécutives (en respectant le délai de réplication).
- Pour révoquer un Silver Ticket : il faut réinitialiser le mot de passe du compte de service concerné (ou le compte d’ordinateur de la machine).

Comment ça fonctionne

Matrice comparative technique en DFIR

Caractéristique	Golden Ticket	Silver Ticket
Nature du ticket	TGT (`krbtgt`)	TGS (Service Ticket)
Clé cryptographique requise	Hash NTLM ou clé AES de `krbtgt`	Hash NTLM ou clé AES du compte de service
Portée d’accès	Tous les services du domaine / Forêt	Strictement le service cible (CIFS, SQL, etc.)
Contact avec le DC ?	Oui (pour demander des TGS via le TGT)	Non (aucun contact avec le DC)
Signature KDC du PAC	Valide (signée avec la vraie clé krbtgt)	Fausse (signature bidon ou absente)
Durée de validité par défaut	10 ans (par défaut dans Mimikatz)	10 ans (par défaut dans Mimikatz)
Traces sur le DC	Event 4769 sans Event 4768 préalable	Aucune trace sur le DC
Traces sur le serveur cible	Event 4624 (Logon Type 3 Kerberos)	Event 4624 (Logon Type 3 Kerberos)
Remédiation	Double réinitialisation de `krbtgt`	Réinitialisation du mot de passe du service

Ce qui est possible

Forger un golden ticket avec un nom d’utilisateur qui n’existe pas dans l’AD : l’attaquant peut créer un TGT pour administrateur_fantome. Le KDC délivrera les TGS sans vérifier l’existence du compte dans la base LDAP (sauf si la validation de compte est activée ou lors de referrals inter-forêts).
Conserver un golden ticket actif pendant 10 ans : les outils offensifs positionnent par défaut une date d’expiration très lointaine.
Détecter un silver ticket si le service valide le PAC : si le service applicatif interroge le DC via Netlogon pour valider la KDC Signature, le DC détecte la fausse signature et rejette le Silver Ticket.

Ce qui n’est pas possible

Utiliser un silver ticket sur un autre serveur : le Silver Ticket est chiffré avec la clé du service A. S’il est présenté au service B, celui-ci échoue à le déchiffrer (KRB_AP_ERR_MODIFIED / 0x29).
Surveiller les silver tickets depuis le SIEM si seuls les DC sont audités : le Silver Ticket ne touchant jamais le KDC, il est totalement invisible sans collecte des logs des serveurs membres.
Révoquer un golden ticket en changeant le mot de passe de l’utilisateur usurpé : le Golden Ticket utilise la clé de krbtgt, pas celle de l’utilisateur. Seule la rotation de krbtgt invalide le TGT.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« Nous avons vu un Golden Ticket dans les logs du serveur web. »	Faux. Le serveur web ne reçoit que des TGS (Silver Tickets ou TGS légitimes). Le Golden Ticket (TGT) n’est présenté qu’au KDC.
« Réinitialiser krbtgt une seule fois suffit pour bloquer les Golden Tickets. »	Active Directory conserve en mémoire la clé `krbtgt` précédente pour éviter d’invalider brutalement les sessions légitimes. Il faut impérativement réinitialiser deux fois avec un intervalle entre les deux.
« Un Silver Ticket génère un Event 4769 sur le DC. »	Non. Le Silver Ticket est directement injecté sur le serveur cible sans passer par le DC.

Exemple concret d’investigation

Dans une réponse à incident, l’analyste DFIR enquête sur un serveur de fichiers FS01 chiffré par un ransomware :

Sur FS01 : L’Event ID 4624 montre une ouverture de session réseau à 01:45 UTC sous le compte CORP\AdminTemp via Kerberos.
Sur les contrôleurs de domaine :
- L’analyste cherche l’Event 4768 (TGT) pour AdminTemp à cette heure : aucun résultat.
- L’analyste cherche l’Event 4769 (TGS) pour cifs/FS01 : aucun résultat.
Diagnostic : la connexion sur FS01 a été réalisée avec un Silver Ticket forgé avec le mot de passe du compte d’ordinateur FS01$ extrait précédemment de la SAM ou de LSASS. Le DC a été complètement court-circuité.

Artefacts et traces forensiques

Journaux de sécurité DC (détection de golden ticket) :
- Anomalie 4769 sans 4768 : demande de TGS pour un compte sans demande préalable de TGT dans les 10 heures précédentes.
- Type de chiffrement anormal : usage de 0x17 (RC4) dans les événements 4769 alors que le domaine tourne en AES-256 (0x12).
- Nom de compte inexistant : event 4769 émis pour un utilisateur introuvable dans l’annuaire LDAP.
Journaux de sécurité du serveur membre (détection de silver ticket) :
- Event ID 4624 : logon Type 3 Kerberos survenant sans aucune trace correspondante d’Event 4769 sur les DC du domaine.
Artefacts en mémoire (endpoint triage) :
- Inspection des tickets via klist ou Rubeus : durée de validité anormale (ex: validité de 10 ans au lieu des 10 heures standard de la stratégie Kerberos).

Méthodes d’investigation

Corréler les événements 4768 et 4769 sur les DC : Détecter les comptes demandant des TGS sans avoir préalablement négocié leur TGT auprès d’un KDC de la forêt.
Auditer les durées de validité des tickets en mémoire : Rechercher sur les machines suspectes les tickets présentant une fin de validité située plusieurs mois ou années dans le futur.
Vérifier les réinitialisations de krbtgt : Vérifier l’attribut pwdLastSet du compte krbtgt pour confirmer si une double rotation a été exécutée post-incident.

Outils d’investigation

Rubeus :
Fenêtre de terminal
```
Rubeus.exe triage
Rubeus.exe klist
```

PowerShell / Get-WinEvent (chasse aux golden tickets) :

# Identifier les TGS chiffrés en RC4
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769} |
  Where-Object { $_.Properties[2].Value -eq '0x17' } |
  Select-Object TimeCreated, @{N='User';E={$_.Properties[4].Value}}, @{N='Service';E={$_.Properties[0].Value}}

Points clés à retenir

Golden ticket = TGT forgé avec krbtgt $\rightarrow$ compromission totale de tout le domaine.
Silver ticket = TGS forgé avec la clé du service $\rightarrow$ compromission limitée à ce service, invisible sur le DC.
La signature du Golden Ticket est une demande de TGS (4769) sans émission préalable de TGT (4768).
La remédiation d’un Golden Ticket exige impérativement une double réinitialisation de krbtgt.