Golden Ticket : Les Clés de Votre Domaine

Qu'est-ce qu'une attaque Golden Ticket ?

Une attaque 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 quelconque utilisateur.

L'attaque exploite le compte KRBTGT, dont le hash sert à 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 de son choix.

Cela fait du Golden Ticket l'une des techniques post-exploitation les plus graves d'Active Directory : un seul hash volé se traduit par un contrôle indéfini de tout le domaine.

Comment fonctionne une attaque Golden Ticket

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 demander 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 de 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 véritable hash KRBTGT, est donc indiscernable d'un ticket légitime.

La Chaîne d'Attaque

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

L'attaquant a besoin de privilèges suffisants pour extraire le hash KRBTGT. Cela implique généralement de compromettre un contrôleur de domaine ou tout compte disposant des droits DS-Replication-Get-Changes-All (DCSync).

Les chemins d'escalade courants qui y mènent : Kerberoasting d'un compte de service privilégié, abus d'ADCS ESC1/ESC8, ou exploitation d'une délégation non contrainte.

Étape 2 - Extraire le Hash KRBTGT via DCSync

L'attaquant exécute une attaque DCSync avec Mimikatz ou Impacket pour extraire le hash NTLM du compte KRBTGT sans toucher au disque du DC ni déclencher d'événement de connexion :

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

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

La sortie inclut le hash NTLM et le SID du domaine — tous deux nécessaires pour forger le ticket.

Étape 3 - Forger le Golden Ticket

Avec le hash KRBTGT et le SID du domaine, l'attaquant fabrique un TGT pour l'utilisateur de son choix :

# 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 :

Étape 4 - Accès Total au Domaine 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
• Déployer des GPO malveillantes sur toutes les machines
• Persister indéfiniment — la réinitialisation du mot de passe de n'importe quel compte utilisateur n'a aucun effet

Détection

Les Golden Tickets sont difficiles à détecter car les TGT forgés ressemblent à du trafic Kerberos légitime. Le KDC n'est pas consulté au moment de l'utilisation du ticket, donc aucun événement d'authentification ne se déclenche sur le DC lorsque le ticket est présenté à un service.

La détection repose sur l'analyse d'anomalies plutôt que sur une 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 10 heures ; 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 - les outils plus anciens utilisent RC4 (0x17) par défaut
• Demande TGS sans AS-REQ préalable - une demande de service ticket sur un DC sans demande de TGT correspondante est un indicateur fort
• Incohérence de SID - le SID intégré dans le ticket ne correspond à aucun compte AD réel

Requête SIEM (Elastic KQL)

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

event.code: "4768" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
winlog.event_data.PreAuthType: "0"

Remediation

Réponse Immédiate

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

• La première rotation invalide tous les tickets forgés actuellement actifs.
• La seconde rotation retire l'ancien hash de la mémoire des DC, empêchant l'utilisation de tickets forgés avec l'ancien hash.

Utilisez le script de réinitialisation KRBTGT activement maintenu, qui gère automatiquement les vérifications de réplication multi-DC :

# Télécharger et exécuter Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
# https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.md

.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs
# Attendre au moins 10 heures (durée de vie maximale des tickets)
.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs

Durcissement pour Prévenir la Compromission Initiale

Vérifier l'Exposition DCSync

# Trouver les comptes disposant des droits DCSync (comptes non-DC avec permissions de réplication)
Get-ADObject -Filter * -Properties nTSecurityDescriptor | Where-Object {
    $_.nTSecurityDescriptor.Access | Where-Object {
        $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -and
        $_.IdentityReference -notmatch "Domain Controllers"
    }
}

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é précédemment pourrait encore être valide.

Contrôles associés supplémentaires :

• WEAK_KERBEROS_POLICY - paramètres de durée de vie et de renouvellement des tickets Kerberos qui étendent la fenêtre d'exposition aux tickets forgés
• KERBEROS_RC4_FALLBACK - chiffrement RC4 encore autorisé sur le domaine, nécessaire pour forger des tickets avec les outils plus anciens et qui complique la détection
• UNCONSTRAINED_DELEGATION - comptes avec délégation non contrainte pouvant être utilisés pour capturer des TGT, un précurseur courant des attaques Golden Ticket

Priorités de Revue

Golden Ticket : Les Clés de Votre Domaine doit être traité comme une exposition réelle dans votre environnement Active Directory, et non comme un simple paramètre isolé. Commencez par définir le périmètre de revue : quels groupes privilégiés, comptes de service, ACL, liens GPO, trusts, délégations, modèles de certificats et postes d'administration sont concernés, quels flux métier en dépendent, quels privilèges ils exposent, et quelles exceptions d'urgence ont été ajoutées au fil du temps. Cette étape de cadrage évite une remédiation superficielle, car le symptôme technique est souvent plus restreint que le rayon d'impact opérationnel. En documentant le chemin complet entre configuration et privilège, l'équipe peut prioriser les changements qui réduisent le risque rapidement sans casser l'accès en production. Cela crée aussi une base défendable pour la validation ultérieure et donne à la direction une explication claire de l'urgence du sujet.

Contrôles Adjacents à Revoir

Quand des attaquants atteignent votre environnement Active Directory, ils s'arrêtent rarement au premier point faible. Autour de Golden Ticket : Les Clés de Votre Domaine, ils testent généralement si le chemin exposé peut être enchaîné avec des comptes privilégiés obsolètes, une imbrication de groupes dangereuse, une délégation excessive, des politiques de mot de passe faibles, des chemins GPO accessibles en écriture et un abus d'ACL héritées. Les défenseurs doivent donc revoir non seulement la faiblesse principale, mais aussi chaque dépendance voisine qui transforme un accès en persistance ou en escalade de privilèges. Vérifiez quelles identités, rôles, permissions et hypothèses de confiance peuvent être réutilisés par un opérateur motivé. Si un correctif ferme un seul objet en laissant intactes les voies de privilège adjacentes, le risque réel change à peine. Une revue disciplinée des possibilités d'enchaînement est ce qui transforme ce sujet en un véritable exercice de durcissement plutôt qu'en simple case cochée.

Lectures Connexes

Traitez ce sujet en lien avec Délégation Kerberos : de la Non Contrainte au RBCD, Kerberoasting : Comment les Attaquants Cassent les Mots de Passe des Comptes de Service, Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, Attaques de Confiance Active Directory : du Domaine Enfant à la Racine de la Forêt et AS-REP Roasting : Récolter des Hashes Sans Identifiants. Ces articles connexes montrent comment les mêmes faiblesses d'identité s'enchaînent généralement lors d'un audit réel, au lieu d'apparaître comme des constats isolés.

• Délégation Kerberos : de la Non Contrainte au RBCD
• Kerberoasting : Comment les Attaquants Cassent les Mots de Passe des Comptes de Service
• Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin
• Attaques de Confiance Active Directory : du Domaine Enfant à la Racine de la Forêt
• AS-REP Roasting : Récolter des Hashes Sans Identifiants

Utiliser ces références permet de garder la discussion de remédiation centrée sur le chemin d'attaque complet plutôt que sur une seule faille de contrôle.

Liste de Validation

Avant de clore la revue, rejouez les mêmes contrôles qui ont révélé le problème et confirmez que le chemin à risque n'existe plus du point de vue de l'attaquant. Vérifiez les identités, privilèges, chemins d'héritage et contrôles compensatoires concernés en production, et pas seulement en environnement de test ou dans la documentation. Consignez le responsable technique, la dépendance métier attendue, et la preuve que la nouvelle configuration est à la fois plus sûre et opérationnellement soutenable. Cette étape finale de validation est ce qui garde l'article ancré dans la manière dont les équipes réduisent réellement le risque d'identité.