Réseaux et infrastructures

Entreprises et organisations

Collecte de tickets Kerberos pour casser un secret

Kerberoasting

L’attaquant emporte un ticket de service et l’utilise pour essayer des mots de passe hors ligne.

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

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

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 les comptes de service d’un réseau utilisant Kerberos. Un utilisateur demande un ticket de service, ce qui peut être une opération normale. L’attaquant s’en sert ensuite pour tenter de retrouver le secret qui protège une partie du ticket. Les essais se déroulent hors ligne : ils ne produisent donc pas forcément une série d’échecs de connexion sur le compte visé.

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.

Un point à vérifierUne idée reçue à corriger

Un compte qui ne se verrouille pas peut malgré tout être visé par des essais de mots de passe effectués 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 ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Oui. Les essais portent sur les données du ticket, sur la machine de l’attaquant. Chaque calcul ne provoque donc pas une nouvelle tentative de connexion au service.

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

Des tickets de service permettent de tester un secret hors ligne

Un utilisateur connecté au réseau demande des tickets Kerberos pour des services. Il peut utiliser la partie protégée par la clé du compte de service pour tester des mots de passe hors ligne. L’annuaire peut autoriser cette demande de ticket sans droits d’administration : cette étape ne prouve donc pas, à elle seule, un abus.

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.

Quelles informations comparer

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.

Ce que ces indices ne permettent pas de conclure

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

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.

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 ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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

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.

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

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.

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