Réseaux et infrastructures

Entreprises et organisations

Collecte de tickets Kerberos pour casser un secret

Kerberoasting

Un ticket de service sert à tester hors ligne la robustesse d’un secret.

Révision éditoriale : 23 septembre 2026Comprendre : 2 min · Cas technique et détails : 5 min

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

Dans un réseau d’entreprise, un compte compromis demande un ticket pour un service. L’attaquant emporte certaines données du ticket et tente de retrouver hors ligne le mot de passe du compte de service. Un secret faible peut alors ouvrir un accès plus puissant.

Comment cela fonctionne

Le Kerberoasting vise des comptes de service dans des environnements Kerberos. La demande de ticket peut être une fonction normale du réseau. L’attaque consiste ensuite à essayer de retrouver le secret qui protège une partie du ticket. Comme ce travail se fait hors ligne, le compte ne reçoit pas nécessairement une série d’échecs de connexion.

Comment le piège fonctionne

Un ticket de service est obtenu
Une fonction normale de Kerberos.
Son secret est recherché hors ligne
Des candidats sont testés sans connexion répétée.
Le compte de service peut être détourné
Si son mot de passe est retrouvé.

Ce que vous pouvez faire

Vos premiers réflexes

Si vous utilisez simplement un poste de l’organisation, transmettez les alertes au support. Les tickets et mots de passe des comptes de service doivent être traités par les administrateurs.

Si vous êtes responsable du service ou de l’organisation

Employez des secrets de service longs et gérés automatiquement lorsque possible. Limitez leurs droits et examinez les demandes inhabituelles de tickets avec le contexte du service.

Le détail qui change toutUne idée reçue à corriger

L’absence de verrouillage de compte ne prouve pas qu’aucun essai de mot de passe n’a lieu hors ligne.

À vous de décider

Le compte de service ne montre aucun échec de connexion. Peut-on tout de même essayer de retrouver son mot de passe ?

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Oui. L’attaquant peut tester des candidats sur les données du ticket, hors ligne. Ces calculs n’envoient pas une tentative au service à chaque essai.

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

Des tickets de service permettent de tester un secret hors ligne

Un utilisateur authentifié demande des tickets Kerberos pour des services. Une partie de ces tickets est protégée avec la clé du compte de service ; elle peut servir à tester des mots de passe hors ligne. La demande de ticket peut être autorisée par l’annuaire : l’attaque n’exige pas nécessairement un privilège d’administration.

Les événements 4769 renseignent les services ciblés et les types de chiffrement. Dans l’exemple, svc_sql utilise un secret ancien et un ticket RC4, tandis qu’un autre service utilise AES et un compte géré. Le cas du premier mérite une attention particulière. Un ticket AES n’exclut toutefois pas les essais hors ligne ; la solidité du secret reste déterminante.

La phase de calcul ne produit pas de nouvelles requêtes au contrôleur de domaine. L’absence de connexions en échec ne rassure donc pas sur ce point. Examiner les demandes inhabituelles par utilisateur, la diversité des services et les usages ultérieurs de leurs comptes. La correction passe notamment par des secrets longs et renouvelés, des comptes gérés lorsque le service le permet, et des privilèges limités.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

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.

Étape

Client du domaineCompte authentifié

KDCTickets de service

Analyse hors ligneHors télémétrie du DC

Service cibleDroits du compte

Action
Demande de ticket de service
Client du domaine vers KDC
Trace 4769 et SPN
Réponse
Ticket délivré
KDC vers Client du domaine
Trace type de chiffrement
Action
Ticket disponible pour analyse
Client du domaine vers Analyse hors ligne
Trace collecte non égale au cassage
Action sur place
Hypothèses sur le secret
Analyse hors ligne
Trace aucun échec visible au DC
Action
Autres services demandés
Client du domaine vers KDC
Trace diversité et rareté
Action
Usage ultérieur à rechercher
Client du domaine vers Service cible
Trace nouvelle source
Action sur place
Validation après rotation
Service cible
Trace fonctionnement métier

Comment repérer cette attaque

Indices à rechercher

Un compte demande soudain de nombreux tickets de services inhabituels.
Des comptes de service anciens disposent de mots de passe faibles ou de droits excessifs.
Un service est demandé depuis une machine qui ne l’utilise normalement pas.

Repérer les demandes de tickets vers des services rarement utilisés par le demandeur, les collectes couvrant de nombreux SPN et les choix de chiffrement inattendus.

Éléments à croiser

Chercher un compte demandant soudain des tickets pour de nombreux services inhabituels, puis comparer les services ciblés à leurs usages normaux et à leur configuration de chiffrement.

Limites de l’interprétation

Une demande de ticket est une opération Kerberos normale. RC4 peut venir d’une compatibilité ancienne ; AES n’exclut pas toute attaque. Le travail de cassage hors ligne n’apparaît pas dans les journaux du contrôleur.

Comment réagir

Examiner les comptes ciblés et leur exposition, remplacer les secrets faibles ou partagés et adopter des comptes gérés quand le service le permet. Tester les clés AES disponibles et les dépendances avant retrait de RC4. Si un secret est compromis, traiter les sessions et tickets encore valides, au-delà du seul changement de configuration cryptographique.

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.

Comparer un compte de service de test géré et un compte ancien sans réaliser de cassage de mot de passe.
Vérifier les types de chiffrement réellement utilisés et la solidité des secrets de service ; un ticket AES ne suffit pas à exclure les essais hors ligne.
Après rotation, valider le service et surveiller toute utilisation de l’ancienne identité depuis un nouveau poste.

À vous de raisonner

Des tickets de service inhabituels ont été demandés, mais aucun échec de connexion ne suit. Pourquoi ce silence ne suffit-il pas à écarter le risque ?

Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Les essais peuvent se faire sur une copie du ticket sans contacter le domaine. Examinez les demandes, la solidité et l’ancienneté des secrets, les privilèges et les usages ultérieurs des comptes. Le chiffrement AES améliore certains aspects, mais n’exclut pas à lui seul les essais hors ligne.

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.

TicketEncryptionType: Type de chiffrement du ticket dans l’événement, pas preuve que son secret a été retrouvé.
secret_age_days: Contexte d’inventaire ajouté au scénario, non champ natif du 4769.

Tickets de service et inventaire

Journal

Champs 4769 synthétiques suivis d’un enrichissement d’inventaire indépendant.

EventID=4769 TargetUserName=alice ServiceName=svc_sql
IpAddress=::ffff:10.20.1.24 TicketEncryptionType=0x17 Status=0x0
EventID=4769 TargetUserName=alice ServiceName=svc_backup
IpAddress=::ffff:10.20.1.24 TicketEncryptionType=0x12 Status=0x0
inventory account=svc_sql managed=false secret_age_days=730
inventory account=svc_backup managed=true privileged=false

Pré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.

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
Comparer compte demandeur, adresse cliente, ServiceName, résultat et TicketEncryptionType. Dans les événements concernés, 0x17 désigne RC4 et 0x12 AES256 ; préserver le code original.
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.
Documentation : Active Directory — demandes de tickets de service 4769
Service concerné — audit et historique à vérifier
Où les trouver
Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
Quoi relever
Dans l’inventaire Active Directory, vérifier les comptes de service ciblés, leurs SPN, les types de chiffrement autorisés et la gestion de leurs secrets. Ce contexte vient de l’annuaire, pas du seul événement 4769.
Accès et prérequis
Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Documentation : Service concerné — audit et historique à vérifier

Si vous pensez être concerné

Si vous utilisez le service

Si vous utilisez simplement un poste de l’organisation, transmettez les alertes au support. Les tickets et mots de passe des comptes de service doivent être traités par les administrateurs.

Pour l’équipe qui exploite le service

Analysez les comptes de service visés et leurs permissions.
Renouvelez leurs secrets de manière coordonnée avec les applications.
Recherchez l’usage des identités concernées et le compte initial compromis.

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 — Kerberoasting — attack.mitre.org
Microsoft — événement 4769 — learn.microsoft.com
Microsoft — détecter et corriger RC4 — learn.microsoft.com