Une minute de tickets faibles : repérer le Kerberoasting dans les logs du DC

Dans Active Directory, un service comme SQL Server tourne sous un compte qui possède un service principal name (SPN). Pour l'atteindre, un utilisateur demande au contrôleur de domaine un ticket de service Kerberos, et une partie de ce ticket est chiffrée avec une clé dérivée du mot de passe du compte de service. Tout utilisateur authentifié peut demander un ticket pour n'importe quel SPN : la requête est donc normale et aboutit.

Le Kerberoasting (MITRE ATT&CK T1558.003, présenté par Tim Medin en 2014) demande ces tickets en masse et les casse hors ligne, là où aucun log ne peut le voir. Les tickets RC4 (0x17) sont la cible : leur clé est le hash NT du compte, que les GPU testent des ordres de grandeur plus vite que les clés AES (0x12), salées et itérées, si bien que le mot de passe d'un compte de service choisi par un humain tombe rapidement. MITRE cite son usage par des groupes de ransomware comme Wizard Spider et par APT29 dans la compromission de SolarWinds.

Le contrôleur de domaine enregistre chaque ticket dans l'événement 4769, et le chiffrement du ticket est décidé par le compte de service. Microsoft a annoncé que, à partir de mi-2026, les contrôleurs de domaine n'autorisent par défaut que l'AES, le RC4 seulement là où un administrateur l'active ; Ashgrove l'a gardé pour un ancien client ERP, donc ses huit anciens comptes de service, jamais configurés pour l'AES, distribuent encore des tickets RC4 à n'importe qui, alors que les comptes d'ordinateur et le gMSA reçoivent de l'AES. La consigne de Microsoft pour cet événement est de surveiller les chiffrements de ticket autres que 0x11 et 0x12 ; MITRE ajoute la forme : un seul compte qui demande un nombre inhabituel de tickets de service sur une courte période.

• Répondre svc_erpbatch. Il a exactement autant de tickets RC4 que l'attaquant, mais toujours pour un seul service, svc_sqlerp, toutes les deux minutes depuis le serveur ERP : une tâche planifiée sur un compte ancien, une exception à retirer, pas une attaque. Compte les services distincts par compte, pas les lignes.
• Répondre svc_tenable. Cinq services en quatorze secondes, c'est le scan authentifié du scanner de vulnérabilités : des tickets AES, pour des comptes d'ordinateur (noms qui finissent par $) dont les mots de passe sont longs, aléatoires et renouvelés, donc inutiles à roaster.
• Répondre a.quintero. Un seul ticket RC4 pour svc_crm, c'est un utilisateur qui ouvre le CRM, qui tourne encore sous un compte ancien. Le RC4 seul n'est pas le signal.
• Répondre un compte de service roasté. svc_sql, svc_backup et les autres sont les victimes : leurs tickets ont été demandés. La question demande qui les a demandés.
• Répondre le poste de travail. WKS-0417 (10.20.14.37) est l'origine des requêtes et la machine à isoler, mais les tickets ont été émis pour le compte c.ferrante.
• Chercher des échecs. Chaque ligne a le code d'échec 0x0 : un Kerberoasting est fait de requêtes réussies et parfaitement valides.

Rends les tickets inutiles à casser, puis rends le schéma de requêtes bruyant.

• Donne l'AES à chaque compte de service : positionne msDS-SupportedEncryptionTypes sur 0x18 (AES128 + AES256) et réinitialise son mot de passe une fois pour que les clés AES existent. Retire ensuite l'exception RC4 : mets à jour le client ERP et laisse partir le RC4, comme le prévoient les nouveaux défauts de Microsoft.
• Migre les services vers des comptes de service gérés de groupe (gMSA) : le domaine leur attribue des mots de passe longs et aléatoires et les renouvelle, donc un ticket volé ne peut pas être cassé. Quand c'est impossible, utilise un mot de passe aléatoire de 25 caractères ou plus, comme le conseille MITRE, et renouvelle-le.
• Supprime les SPN que personne n'utilise et garde les comptes de service hors des groupes privilégiés comme Domain Admins.
• Active Audit Kerberos Service Ticket Operations sur chaque contrôleur de domaine et alerte quand un compte obtient des tickets RC4 (0x17) pour plusieurs services distincts en une minute ; ignore les services qui finissent par $ et mets en liste d'autorisation les paires héritées connues comme svc_erpbatch vers svc_sqlerp. Un compte piège avec un SPN que rien n'utilise transforme toute demande de ticket pour lui en alerte à forte confiance.
• Réagis : réinitialise dès maintenant les mots de passe des huit comptes de service roastés (les tickets sont déjà hors ligne), isole WKS-0417 et enquête sur la session de c.ferrante.