Réseaux et infrastructures
Entreprises et organisationsFalsification de tickets Kerberos
Golden ticket / Silver ticket
Des secrets de domaine volés permettent de fabriquer des preuves d’accès.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Un réseau utilise des tickets pour prouver les droits des utilisateurs. Si un attaquant vole un ticket valide, ou obtient une clé qui permet d’en fabriquer, il peut tenter de se faire reconnaître sous une identité usurpée.
Comment cela fonctionne
Kerberos utilise des tickets pour prouver une connexion sans renvoyer le mot de passe à chaque service. Ces tickets sont donc sensibles. Un attaquant peut voler un ticket existant ou fabriquer un faux ticket : ce sont deux attaques différentes. Les appellations Golden Ticket et Silver Ticket désignent des falsifications utilisant des clés différentes, qui ne donnent pas accès aux mêmes ressources.
- Une preuve d’identité est compromise
Ticket volé ou clé exposée.
- Un ticket est réutilisé ou falsifié
Selon le secret disponible.
- Des services reconnaissent la fausse identité
La portée dépend du ticket et des clés.
Ce que vous pouvez faire
Vos premiers réflexes
Cette attaque concerne la gestion des identités du réseau. Signalez les accès non reconnus au support ; ne tentez pas de renouveler vous-même les secrets du domaine.
Si vous êtes responsable du service ou de l’organisation
Protégez les contrôleurs de domaine et les comptes de service. Si une clé est exposée, planifiez son renouvellement avec les spécialistes de l’annuaire et vérifiez les accès persistants.
Changer le mot de passe d’un utilisateur n’invalide pas nécessairement immédiatement tous les tickets déjà émis.
À vous de décider
Changer le mot de passe d’un utilisateur retire-t-il un faux ticket créé avec une clé de domaine volée ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Il faut traiter la clé volée qui a permis de fabriquer le ticket, ainsi que les tickets concernés. Changer seulement le mot de passe de l’utilisateur imité ne règle pas ce problème.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un accès Kerberos apparaît sans demande de ticket retrouvée
Le serveur accepte un accès Kerberos, mais aucune demande correspondante n’apparaît dans les événements de domaine collectés. Un faux ticket est une explication possible. Un ticket plus ancien, un contrôleur absent de la collecte ou un retard de transmission peuvent aussi l’expliquer. Ici, il faut d’abord combler le manque de journaux récents de DC03.
Un Golden Ticket repose sur la compromission de la clé du compte KRBTGT, qui protège les tickets d’authentification du domaine. Un Silver Ticket vise un service à partir de sa clé. Les événements disponibles et les vérifications effectuées par le service diffèrent selon le cas ; une seule règle fondée sur l’absence d’un événement ne couvre pas ces situations.
Examiner les identités, groupes, durées de validité et accès effectivement accordés, puis rechercher la compromission des clés concernées. La remise en état doit être coordonnée avec l’équipe annuaire. Les rotations de clés, notamment celles de KRBTGT, exigent de tenir compte de la réplication et des tickets encore valides pour éviter de perturber tout le domaine.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Émission normale possible
KDC / DC vers Client WS24
Trace hors fenêtre ou autre DC
- Action
Présentation du ticket
Client WS24 vers Serveur FS01
Trace Kerberos accepté
- Action sur place
Accès sensible
Serveur FS01
Trace audit du partage
- Action
Événement cible
Serveur FS01 vers SIEM
Trace 4624 et identité
- Action
Émissions collectées
KDC / DC vers SIEM
Trace DC03 manquant
- Action sur place
Jointure sans correspondance
SIEM
Trace conclusion conditionnelle
- Action
Rotation coordonnée des clés
KDC / DC vers Serveur FS01
Trace validation et réplication
Comment repérer cette attaque
Indices à rechercher
- Des accès de service ne correspondent pas aux habitudes du compte.
- Des clés ou secrets privilégiés du domaine ont été exposés.
- Des incohérences apparaissent entre tickets, identités et événements du domaine.
Rechercher les tickets ou privilèges incohérents, les accès associés sur les serveurs et les indices de vol de clés, en tenant compte de la couverture de collecte des contrôleurs.
Quelles informations comparer
Aligner identité, service, adresse et temps entre contrôleurs et serveur cible. Documenter explicitement les contrôleurs manquants, les horloges décalées et les trous de collecte avant d’interpréter les événements absents.
Ce que ces indices ne permettent pas de conclure
Une session Kerberos sans 4768 ou 4769 retrouvé ne prouve pas un ticket forgé. La collecte peut être incomplète et un ticket valide peut être réutilisé ; l’enquête doit rechercher d’autres incohérences.
Comment réagir
Préserver les preuves sur les DC et les hôtes concernés, isoler les chemins d’administration compromis et définir quelles clés doivent être renouvelées. Suivre une procédure de récupération AD éprouvée pour KRBTGT, avec validation de réplication et de l’intégrité des contrôleurs. Pour une clé de service, traiter ses dépendances et tous les serveurs qui la partagent.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- Injecter une panne de collecte de laboratoire et vérifier qu’elle dégrade la confiance de l’alerte.
- Tester un ticket légitime mis en cache pour éviter de le qualifier de faux.
- Vérifier réplication, authentifications métier et refus des anciennes clés selon la procédure choisie.
À vous de raisonner
Un service accepte un ticket sans demande correspondante retrouvée, mais un contrôleur de domaine n’est plus collecté. Quelle conclusion reste prématurée ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Conclure à un ticket forgé serait prématuré. Résolvez la lacune de collecte et vérifiez les tickets obtenus auparavant, les durées et les identités. L’absence d’une demande dans un ensemble incomplet de journaux ne démontre pas son absence réelle.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
last_event- Contrôle de fraîcheur de la collecte : un contrôleur silencieux ne peut pas servir à prouver qu’aucun ticket n’a été émis.
4769- Demande de ticket de service, à distinguer de l’émission du ticket initial 4768.
La jointure manquante et son angle mort
JournalChronologie synthétique ; l’absence de 4769 est explicitement une absence dans la collecte, pas dans tout le domaine.
10:10 FS01 4624 package=Kerberos user=svc_ops source=WS24
10:11 FS01 audit action=read_sensitive_share user=svc_ops
search DC01,DC02 4769 service=cifs/FS01 user=svc_ops: 0 result
coverage DC03 last_event=07:00 collector_state=stale
inventory FS01 service_key_rotation=unknownPréparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Windows — journal Sécurité de la machine cible
- Où les trouver
- Observateur d’événements → Journaux Windows → Sécurité. Chercher les connexions réussies 4624 sur la machine qui reçoit l’accès, pas seulement sur le poste de départ.
- Quoi relever
- Sur le serveur atteint, retrouver la session Kerberos 4624, le compte, l’adresse source et les actions effectuées avec cette session.
- Accès et prérequis
- Accès délégué aux événements et stratégie d’audit des ouvertures de session active. Une adresse IP ou un champ peuvent être absents selon le protocole utilisé.
Active Directory — demandes de tickets de service 4769
- Où les trouver
- Dans le journal Sécurité des contrôleurs de domaine, ou dans leur collecte centralisée. Ne pas se limiter au contrôleur de domaine le plus proche du poste.
- Quoi relever
- Sur les contrôleurs de domaine, rechercher les demandes de tickets pour le service cible. Vérifier d’abord les dates du dernier événement reçu de chaque contrôleur.
- Accès et prérequis
- Audit Kerberos Service Ticket Operations actif. Les champs disponibles dépendent des mises à jour Windows ; conserver l’événement original avec le nom du contrôleur.
Active Directory — émission de tickets initiaux 4768
- Où les trouver
- Dans le journal Sécurité des contrôleurs de domaine ; cet événement concerne la demande de ticket initial, distincte d’une demande de ticket de service.
- Quoi relever
- Chercher l’émission du ticket initial dans une fenêtre suffisamment large, en tenant compte de sa durée de vie et de son obtention possible avant l’accès suspect.
- Accès et prérequis
- Audit Kerberos Authentication Service actif et couverture des contrôleurs vérifiée. Un ticket peut avoir été obtenu avant la fenêtre de recherche.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- àGroupeAPT29
Des preuves d’identité forgées pour conserver l’accès
Mandiant décrit l’emploi de Golden Tickets pour entrer dans des systèmes internes, puis l’adaptation de ce principe aux jetons SAML dans le cloud. Les tickets Kerberos et les jetons SAML utilisent des protocoles différents. Dans les deux cas, les faux éléments d’authentification abusent de la confiance du service.
Ce qu’établit la source. Synthèse d’investigations publiée par Mandiant en 2022, couvrant plusieurs opérations d’APT29. Ces observations ne sont pas présentées comme une seule attaque.
Consulter le rapport Assembling the Russian Nesting Doll: UNC2452 Merged into APT29Mandiant / Google Cloud · Publié le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
Si vous utilisez le service
Cette attaque concerne la gestion des identités du réseau. Signalez les accès non reconnus au support ; ne tentez pas de renouveler vous-même les secrets du domaine.
Pour l’équipe qui exploite le service
- Faites intervenir les responsables de l’identité et de la réponse à incident.
- Délimitez les clés et tickets potentiellement exposés.
- Planifiez les renouvellements de secrets avec les dépendances et délais Kerberos.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Steal or Forge Kerberos Tickets — attack.mitre.org
- MITRE ATT&CK — Pass the Ticket — attack.mitre.org
- Microsoft — réinitialisation KRBTGT — learn.microsoft.com
