TL;DR
Le Golden Ticket est la technique de persistance ultime sur un domaine Windows Active Directory. En extrayant le hash du compte KRBTGT, un attaquant peut forger des tickets Kerberos (TGT) valides pour n’importe quel utilisateur, avec n’importe quels privilèges, et une durée de vie pouvant atteindre 10 ans. Le contrôleur de domaine valide ces tickets sans méfiance, car ils sont signés avec son propre secret.
C’est pourquoi le Golden Ticket est considéré comme une compromission totale et durable du domaine, même après la réinitialisation du mot de passe d’un administrateur compromis.
10 ans
durée de vie maximale d’un Golden Ticket par défaut
2×
rotations KRBTGT nécessaires pour invalider les tickets existants
0
privilège que le ticket ne peut pas s’attribuer sur le domaine
Dans la hiérarchie des attaques ciblant Active Directory, le Golden Ticket occupe une place à part. Ce n’est pas une exploitation de vulnérabilité au sens classique du terme. C’est l’exploitation d’un mécanisme fondamental du protocole Kerberos, utilisé de façon détournée pour forger des preuves d’identité incontestables aux yeux du contrôleur de domaine.
La technique a été documentée publiquement par Benjamin Delpy, créateur de Mimikatz, en 2014. Elle a depuis été intégrée dans plusieurs frameworks offensifs et est connue et utilisée par des groupes d’attaquants étatiques et criminels. Le nom vient de l’image du « ticket en or » : une fois en possession du Golden Ticket, l’attaquant possède littéralement les clés du royaume.
Comprendre le Golden Ticket nécessite de maîtriser un concept central du protocole Kerberos : le rôle du compte KRBTGT. Contrairement au Kerberoasting ou au Pass-the-Hash, le Golden Ticket n’exploite pas une mauvaise configuration de sécurité. Il exploite la logique même de l’authentification Kerberos.
Protocole
Le compte KRBTGT : pourquoi c’est le secret le plus sensible du domaine
La clé qui signe tous les tickets Kerberos
Dans tout environnement Windows Active Directory, il existe un compte spécial nommé KRBTGT (Kerberos Ticket Granting Ticket). Ce compte n’est utilisé par aucun utilisateur humain. Son unique fonction est d’être le garant cryptographique de tous les TGT (Ticket Granting Tickets) émis sur le domaine.
Lorsqu’un utilisateur s’authentifie sur le domaine, le KDC (Key Distribution Center, c’est-à-dire le contrôleur de domaine) génère un TGT signé avec la dérivée cryptographique du mot de passe du compte KRBTGT. Ce TGT est ensuite présenté par l’utilisateur pour demander des tickets de service vers des ressources du domaine.
La propriété clé est la suivante : lorsque le KDC reçoit un TGT, il le valide en vérifiant sa signature avec le hash KRBTGT. Si la signature est correcte, le KDC considère le ticket comme légitime et en accepte le contenu (identité de l’utilisateur, groupes, privilèges) sans autre vérification. Il n’y a pas de validation de cohérence entre le contenu du ticket et les attributs réels du compte dans Active Directory.
⚠️ C’est cette absence de validation croisée qui rend le Golden Ticket possible structurellement. Si un attaquant possède le hash KRBTGT, il peut créer un TGT avec n’importe quel contenu, et le contrôleur de domaine le validera comme authentique.
Glossaire
Compte système dont la dérivée cryptographique (hash) signe tous les TGT du domaine. Son secret est le secret le plus critique de toute l’infrastructure Active Directory.
Ticket Granting Ticket. Preuve d’identité obtenue lors de l’authentification, signée par KRBTGT. Présenté au KDC pour demander des tickets de service.
Privilege Attribute Certificate. Structure intégrée dans le TGT décrivant les groupes et privilèges de l’utilisateur. Dans un Golden Ticket, l’attaquant écrit ce qu’il veut dans le PAC.
Technique permettant de répliquer les hashes de mots de passe depuis un contrôleur de domaine, comme si l’on était un autre DC. Requis pour extraire le hash KRBTGT.
Comment fonctionne le Golden Ticket
Du hash KRBTGT à la persistance totale sur le domaine
Le Golden Ticket se déroule en trois phases distinctes, dont seule la première requiert un accès temporaire à des droits élevés.
Flux d’attaque Golden Ticket : du premier accès jusqu’à la persistance totale sur le domaine
Obtenir les droits permettant l’extraction du hash KRBTGT
L’extraction du hash KRBTGT nécessite des droits équivalents à Domain Admin, ou plus précisément des droits suffisants pour effectuer une opération DCSync (réplication de l’annuaire). Ces droits peuvent être obtenus par diverses voies : compromission directe d’un compte administrateur de domaine, exploitation d’un chemin d’escalade de privilèges identifié via BloodHound, ou via une élévation de privilèges progressive. Cette phase est souvent la plus détectable : elle implique un accès à des ressources à haute valeur qui génèrent des journaux Windows.
Extraire le hash KRBTGT via DCSync
Depuis un compte disposant des droits de réplication (GetChangesAll sur la partition du domaine), l’attaquant effectue une opération DCSync qui demande au contrôleur de domaine de lui transmettre les données d’authentification d’un compte cible, comme s’il était lui-même un autre contrôleur de domaine. Cette opération est légitime dans le protocole de réplication AD, mais elle ne devrait être possible qu’entre contrôleurs de domaine. Le hash KRBTGT, ainsi que sa version AES, sont extraits sans que le compte KRBTGT soit jamais interrogé directement ou modifié.
Forger le Golden Ticket et l’utiliser
Avec le hash KRBTGT en main, l’attaquant peut générer un TGT arbitraire. Il choisit l’identité (par exemple un compte administrateur, réel ou fictif), définit les groupes dans le PAC (y compris Domain Admins, Enterprise Admins, Schema Admins), fixe la durée de vie du ticket (jusqu’à 10 ans), et signe l’ensemble avec le hash KRBTGT. Ce ticket est présenté au KDC, qui le valide, émet des tickets de service, et l’attaquant accède à n’importe quelle ressource du domaine.
🎯 La phase 3 peut être réalisée depuis une machine hors du domaine, sans connexion à aucun compte Windows. Il suffit d’injecter le ticket dans la session courante. C’est l’une des raisons pour lesquelles le Golden Ticket est si difficile à contenir une fois le hash KRBTGT compromis.
Variantes
Golden Ticket, Silver Ticket, Diamond Ticket
L’écosystème des tickets forgés Kerberos
Le Golden Ticket n’est pas la seule technique de falsification de tickets Kerberos. Voici comment il se positionne par rapport aux variantes les plus connues.
🥇 Golden Ticket
Forge un TGT signé avec le hash KRBTGT. Donne accès à toutes les ressources du domaine. Prérequis : hash KRBTGT (extraction via DCSync avec droits DA). Durée de vie jusqu’à 10 ans. Plus difficile à invalider.
🥈 Silver Ticket
Forge un ticket de service (ST) signé avec le hash d’un compte de service. Donne accès à un seul service (ex. CIFS, MSSQL). Prérequis : hash du compte de service uniquement. Plus discret : ne passe pas par le KDC pour être validé.
💎 Diamond Ticket
Modifie un TGT légitime existant plutôt que d’en créer un de zéro. Conserve les métadonnées temporelles et le PAC original, en ne modifiant que les groupes. Beaucoup plus difficile à détecter que le Golden Ticket classique.
Golden Ticket vs Silver Ticket : la distinction essentielle
La différence fondamentale est le périmètre d’impact. Un Silver Ticket ne peut accéder qu’au service auquel correspond le hash utilisé pour le forger. Il ne transite jamais par le KDC et ne génère donc aucun événement Kerberos côté contrôleur de domaine, le rendant presque invisible. Le Golden Ticket, lui, donne accès à tout le domaine mais génère des événements TGS côté KDC lors des demandes de tickets de service.
Détection
Détecter un Golden Ticket : ce que la Blue Team doit surveiller
Signaux faibles et corrélation d’événements
La détection du Golden Ticket est l’une des plus difficiles en forensique Windows, parce que les tickets forgés ressemblent à des tickets légitimes aux yeux du contrôleur de domaine. La surveillance Active Directory continue et une corrélation SIEM sont indispensables pour identifier les anomalies.
📋 ID 4769 avec anomalies
L’événement 4769 (Kerberos Service Ticket) est journalisé lors de chaque demande TGS. Les signaux suspects incluent : type de chiffrement inattendu (RC4 dans un environnement forcé AES), tickets demandés pour des SPN inhabituels, volume anormal de TGS depuis un compte.
🕐 Incohérence temporelle
Un TGT avec une date d’émission ou une durée de vie incompatible avec la politique Kerberos du domaine (défaut : 10h pour les TGT) est un indicateur fort. Des tickets avec des timestamps futuristes (années 2030-2035) sont quasi-impossibles à obtenir légitimement.
🔍 ID 4672 : privilèges inhabituels
L’événement 4672 (attribution de privilèges spéciaux) généré pour un compte qui n’est pas dans les groupes correspondants selon Active Directory suggère un ticket forgé. La corrélation entre les groupes du PAC du ticket et les groupes réels du compte en AD est le signal le plus fiable.
⚡ DCSync détectable
La phase d’extraction du hash KRBTGT via DCSync est la plus détectable. L’événement 4662 (accès objet avec droit Replicating Directory Changes) depuis un compte qui n’est pas un contrôleur de domaine est une alerte critique quasi-certaine.
🛡️ PAC validation
Activer la validation du PAC (Kerberos PAC Validation) permet au serveur de service de vérifier auprès du KDC que le PAC du ticket est cohérent avec les attributs réels du compte. Cette option protège contre les PAC modifiés, au prix d’un léger overhead.
🍯 Honeytokens Kerberos
Créer des comptes fictifs avec des SPN et surveiller toute demande TGS vers ces comptes permet de détecter un attaquant qui utilise un Golden Ticket pour explorer le domaine. Tout accès à un honeytoken est une alerte immédiate.
Protection
Comment protéger son domaine contre le Golden Ticket
Mesures structurelles et opérationnelles
La protection contre le Golden Ticket est plus complexe que contre la plupart des attaques Active Directory, parce qu’elle n’implique pas de corriger une mauvaise configuration mais de protéger un secret fondamental du protocole.
1. Rotation double du mot de passe KRBTGT
Si un Golden Ticket est suspecté, ou après toute compromission de Domain Admin, le mot de passe du compte KRBTGT doit être réinitialisé deux fois. La raison est que le KDC conserve les deux derniers hashs KRBTGT pour assurer la compatibilité lors de la réplication entre contrôleurs de domaine. Un seul changement laisse l’ancien hash toujours valide. Deux changements successifs (espacer d’au moins 10 heures, la durée de vie par défaut des TGT) invalident tous les tickets forgés avec l’ancien secret.
⚠️ La double rotation KRBTGT invalide tous les Golden Tickets existants, mais elle invalide également tous les TGT légitimes en cours. Les utilisateurs devront se reauthentifier. Planifier cette opération en dehors des heures de production est indispensable dans un environnement critique.
2. Restreindre les droits DCSync
Seuls les comptes de réplication Active Directory légitimes (les contrôleurs de domaine eux-mêmes, plus quelques rares exceptions opérationnelles) ont besoin du droit Replicating Directory Changes All. Auditer régulièrement les ACL de la partition de domaine pour identifier les comptes disposant de ces droits sans raison légitime est l’un des contrôles les plus importants contre les attaques DCSync. L’outil BloodHound permet de cartographier ces chemins en quelques secondes.
3. Limiter la surface d’exposition des comptes Domain Admin
Un attaquant ne peut extraire le hash KRBTGT que s’il possède d’abord des droits élevés sur le domaine. Toutes les mesures qui rendent difficile l’accès à ces droits (tiering model, just-in-time privileged access, MFA sur tous les comptes à privilèges, stations d’administration dédiées, groupe Protected Users) réduisent la probabilité que l’attaquant arrive à l’étape préalable au Golden Ticket.
4. Activer la validation PAC
La validation PAC (Privilege Attribute Certificate Validation) force les serveurs de service à vérifier auprès du contrôleur de domaine que le PAC contenu dans le ticket de service est cohérent avec les attributs réels du compte dans Active Directory. Cette validation ajoute un contrôle croisé qui détecte les anomalies dans les PAC des tickets forgés. Elle génère un overhead léger et doit être testée en environnement non-productif avant déploiement généralisé.
Missions
Comment le Golden Ticket s’intègre dans nos audits Active Directory
La preuve par la démonstration : du DCSync au Domain Admin
Dans le cadre d’un audit Active Directory PIIRATES, le Golden Ticket intervient comme étape de démonstration de compromission totale du domaine. L’objectif n’est pas de créer un ticket persistant dans l’environnement client, mais de démontrer que le chemin vers cette capacité existe, est exploitable, et que son impact métier est réel.
La séquence typique en mission : identification des chemins vers Domain Admin via BloodHound, exploitation d’un chemin d’élévation de privilèges, tentative de DCSync pour extraire le hash KRBTGT (avec accord explicite du client sur le périmètre testé), puis génération d’un Golden Ticket de démonstration avec une durée de vie courte sur un compte fictif créé pour la mission. Le tout est documenté, les preuves sont conservées, et le rapport inclut le chemin complet depuis le premier accès jusqu’à la forge du ticket.
Ce type de démonstration est souvent le moment le plus percutant d’une mission pour les équipes techniques des organisations auditées. Voir qu’un compte fictif "utilisateur_test_2049" peut accéder à n’importe quelle ressource du domaine grâce à un ticket valide 10 ans, réalisé en quelques minutes après un premier accès sur le réseau, est généralement un argument plus efficace qu’une liste de vulns classées CVSS dans un tableur.
Éthique
Cadre légal et éthique
Golden Ticket et responsabilité du pentester
L’extraction du hash KRBTGT et la forge de Golden Tickets en dehors d’une mission de pentest autorisée constituent une compromission de domaine caractérisée, sanctionnée par l’article 323-3 du Code pénal. Même dans le cadre d’une mission autorisée, l’extraction du hash KRBTGT doit faire l’objet d’un accord explicite spécifique dans le contrat ou les règles d’engagement, car c’est l’opération la plus sensible qu’un pentester peut réaliser sur un domaine Active Directory.
Testez votre exposition
Les chemins vers le hash KRBTGT existent-ils dans votre domaine Active Directory ?
Un audit Active Directory PIIRATES cartographie ces chemins et en démontre l’exploitabilité réelle.
Demander un audit Active DirectoryUn Golden Ticket est un Ticket Granting Ticket (TGT) Kerberos forgé par un attaquant à l’aide du hash du compte KRBTGT d’un domaine Active Directory. Ce ticket permet d’usurper n’importe quelle identité sur le domaine, d’accéder à toutes ses ressources, avec n’importe quels privilèges, et pour une durée pouvant atteindre 10 ans. Le KDC le valide sans vérification croisée car il est signé avec le bon secret.
Le Golden Ticket forge un TGT signé avec le hash KRBTGT, donnant accès à toutes les ressources du domaine. Le Silver Ticket forge un ticket de service signé avec le hash d’un compte de service, donnant accès à un seul service spécifique. Le Silver Ticket est plus discret car il ne passe pas par le KDC lors de son utilisation, mais son impact est limité à un service. Le Golden Ticket a un impact total mais génère des événements KDC lors des demandes TGS.
Active Directory conserve l’historique des deux derniers hashs KRBTGT pour assurer la compatibilité lors de la réplication entre contrôleurs de domaine. Une seule réinitialisation laisse l’ancien hash toujours valide dans cet historique, ce qui signifie que les Golden Tickets forgés avec ce hash restent utilisables. Deux réinitialisations successives (espacées d’au moins la durée de vie des TGT en cours) invalident complètement l’ancien secret.
Oui. C’est l’une des propriétés les plus dangereuses du Golden Ticket. Un ticket forgé avec le hash KRBTGT reste valide tant que ce hash n’est pas modifié, indépendamment des changements de mot de passe des administrateurs ou des autres comptes du domaine. Expulser un attaquant qui possède un Golden Ticket nécessite impérativement la double rotation du KRBTGT, pas seulement la réinitialisation des comptes compromis.
DCSync est une technique qui exploite le protocole de réplication Active Directory pour demander à un contrôleur de domaine de transmettre les données d’authentification d’un compte, comme si l’opérateur était lui-même un autre DC. Elle permet d’extraire le hash KRBTGT sans accès physique au contrôleur de domaine. C’est le prérequis technique au Golden Ticket : sans DCSync (ou accès direct au DC), l’extraction du hash KRBTGT est impossible.
BloodHound cartographie tous les chemins d’attaque dans Active Directory, y compris les chemins vers les droits DCSync (qui permettent l’extraction du hash KRBTGT). Il identifie quels comptes possèdent les privilèges Replicating Directory Changes All, et par quelles voies un attaquant pourrait les obtenir. Corriger ces chemins réduit directement le risque de Golden Ticket.
Les indicateurs les plus fiables sont : l’événement 4762 (modification du compte KRBTGT), des événements 4769 avec un type de chiffrement inattendu (RC4 dans un environnement AES), des tickets avec des durées de vie ou des timestamps anormaux, et des incohérences entre les groupes du PAC d’un ticket et les groupes réels du compte dans Active Directory. Une surveillance Active Directory continue avec corrélation SIEM est nécessaire pour détecter ces anomalies en temps réel.
Le Golden Ticket crée un TGT entièrement forgé depuis zéro. Le Diamond Ticket modifie un TGT légitime existant en changeant uniquement les champs du PAC (groupes, privilèges) tout en conservant les métadonnées originales (timestamps, identifiant de session). Le Diamond Ticket échappe aux détections basées sur les anomalies temporelles et les incohérences de métadonnées, le rendant significativement plus difficile à identifier.
Golden Ticket : la clé maître de l’Active Directory, fonctionnement et protection | PIIRATES
