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
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
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
Les tickets Kerberos évitent de transmettre le mot de passe à chaque service. Ils deviennent donc des éléments sensibles. Le vol d’un ticket existant et la fabrication d’un faux ticket sont deux mécanismes différents. Les noms Golden Ticket et Silver Ticket désignent des cas de falsification liés à des clés différentes, avec des portées différentes.
- 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 ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Le problème porte sur la clé utilisée pour fabriquer le ticket, pas seulement sur le mot de passe de l’utilisateur imité. La réponse doit traiter cette clé et les tickets concernés.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Un accès Kerberos apparaît sans demande de ticket retrouvée
Le serveur accepte un accès Kerberos, mais l’enquête ne retrouve pas de demande correspondante dans les événements collectés du domaine. Cela peut évoquer un ticket forgé. Cela peut aussi venir d’un ticket obtenu plus tôt, d’un contrôleur non collecté ou d’un retard de transmission. Ici, les journaux de DC03 sont anciens : cette lacune doit être résolue avant de tirer une conclusion.
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.
Éléments à croiser
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.
Limites de l’interprétation
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
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des 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
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- àGroupeAPT29
Des preuves d’identité forgées pour conserver l’accès
Mandiant décrit l’usage de Golden Tickets pour accéder à des systèmes internes, puis l’adaptation du principe à des jetons SAML dans le cloud. Un ticket Kerberos forgé et un jeton SAML falsifié concernent des protocoles différents, même s’ils abusent tous deux de la confiance dans l’authentification.
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
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à 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 qualifier votre situation et être orienté : 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
