Kerberoasting : le ticket Kerberos qui peut exposer un compte service
Le Kerberoasting n’est pas une faille nouvelle ni le nom d’une victime : c’est une technique d’attaque documentée contre Active Directory. Après avoir obtenu un compte de domaine valide, même peu privilégié, un attaquant peut demander des tickets de service et tenter hors ligne de retrouver le mot de passe d’un compte de service. Le risque dépend alors de la robustesse de ce mot de passe, du chiffrement utilisé et surtout des droits confiés à ce compte.
Un compte ordinaire peut suffire à commencer
Dans un domaine Windows, Kerberos permet à un utilisateur déjà authentifié d’obtenir des tickets pour accéder à des services. Les noms principaux de service, ou SPN, identifient ces services et sont associés à des comptes qui les exécutent. MITRE ATT&CK classe le Kerberoasting comme une technique d’accès aux identifiants : un attaquant qui possède déjà un ticket d’authentification valide peut demander des tickets de service pour les SPN du domaine.
Cette étape n’implique pas nécessairement un compte administrateur. C’est précisément ce qui rend le sujet important : le premier accès obtenu par hameçonnage, mot de passe réutilisé ou poste compromis peut ouvrir une phase suivante beaucoup moins visible. Le Kerberoasting ne décrit donc pas l’intrusion initiale. Il décrit ce qu’un intrus peut tenter une fois à l’intérieur du réseau.
Le mot de passe du service n’est pas envoyé, mais un ticket peut être attaqué hors ligne
Le ticket de service contient une partie protégée avec une clé liée au compte de service. MITRE explique que, lorsque RC4 est utilisé, cette partie peut être soumise à une attaque par force brute hors ligne afin de retrouver des identifiants en clair. L’attaquant n’a alors pas besoin de multiplier les essais de mots de passe contre le contrôleur de domaine pendant l’opération de cassage.
Cela ne signifie pas qu’un ticket suffit à révéler automatiquement un mot de passe. Un mot de passe long, unique et géré correctement augmente fortement le coût de l’attaque. Mais les comptes de service ont souvent une longue durée de vie et peuvent conserver des secrets anciens. Si l’un d’eux dispose de privilèges élevés ou d’accès étendus, sa compromission peut faciliter le déplacement latéral et l’élévation de privilèges, deux conséquences également signalées par MITRE.
RC4 est un héritage à repérer avant de le désactiver
Microsoft indique que RC4 est un chiffrement historique, encore présent pour des raisons de compatibilité, mais considéré comme non sûr et progressivement abandonné. Sa documentation relie explicitement l’usage de RC4 dans les tickets de service au Kerberoasting. Passer à AES réduit cette exposition, sans dispenser de gérer les mots de passe des comptes de service.
Il ne faut toutefois pas désactiver RC4 à l’aveugle. Microsoft conseille d’abord d’observer les dépendances restantes dans les journaux Kerberos, notamment sur les contrôleurs de domaine. Des équipements anciens ou des comptes créés avant la prise en charge d’AES peuvent provoquer des erreurs d’authentification après un changement. Une migration se prépare, se teste et se surveille.
Les comptes de service doivent avoir le moins de droits possible
La gravité d’un Kerberoasting ne dépend pas seulement du ticket demandé, mais du rôle du compte visé. MITRE recommande de limiter les comptes de service aux privilèges strictement nécessaires, y compris en évitant leur appartenance à des groupes fortement privilégiés. Un compte qui exécute un seul service n’a pas à devenir un raccourci vers l’administration du domaine.
Lorsque l’architecture le permet, les comptes de service gérés de groupe, appelés gMSA, constituent une piste utile. Microsoft explique que le contrôleur de domaine gère leur mot de passe et que les hôtes autorisés le récupèrent sans gestion manuelle de synchronisation. Ils ne conviennent pas à tous les logiciels ni à toutes les architectures, mais ils réduisent le risque de secrets fixes et mal renouvelés.
La détection passe par les demandes de tickets inhabituelles
Un Kerberoasting n’est pas forcément invisible. La stratégie DET0157 de MITRE propose de surveiller les demandes de tickets de service TGS anormales, l’événement Windows 4769, l’usage de RC4 et les comptes demandant soudainement beaucoup de tickets sur une courte période. Elle recommande aussi de comparer les services ciblés avec les usages habituels des comptes.
Un pic isolé ne prouve pas une attaque. Des tâches d’administration ou une application peuvent légitimement demander plusieurs tickets. L’objectif est d’établir une référence normale puis d’enquêter sur les écarts : poste demandeur inattendu, liste de services inhabituelle, chiffrement RC4 ou activité de processus suspecte autour de la même session.
Ce que nous ne pouvons pas vérifier
Aucune organisation, aucun incident précis, aucun volume de comptes ni aucune campagne en cours ne sont identifiés par le signal ZATAZ à l’origine de cet article. Il ne s’agit pas de l’annonce d’une fuite ou d’une cyberattaque confirmée contre une victime nommée.
Nous ne pouvons pas déterminer, sans audit d’un domaine donné, quels comptes utilisent encore RC4, quels logiciels accepteraient une migration vers gMSA ou quelles demandes de tickets seraient réellement anormales. Les mesures décrites sont des pistes de durcissement et de détection à adapter à chaque environnement, en s’appuyant sur les documentations Microsoft et MITRE citées.
Le déroulé
- 11 février 2020 · MITRE ATT&CK crée la sous-technique T1558.003 consacrée au Kerberoasting.
- 21 octobre 2025 · MITRE publie sa stratégie DET0157 de détection des tentatives de Kerberoasting.
- 2026 · Microsoft publie ses recommandations de surveillance et de réduction de RC4 dans Kerberos.
Ce qu'il faut faire
- Inventoriez les comptes de service et leurs privilèges. Retirez les droits qui ne sont pas nécessaires et évitez que ces comptes appartiennent à des groupes fortement privilégiés.
- Repérez RC4 avant toute désactivation. Utilisez les journaux Kerberos pour identifier les dépendances, puis migrez vers AES de manière testée afin d’éviter des ruptures d’authentification.
- Surveillez les demandes TGS inhabituelles. L’événement 4769, l’usage de RC4 et les pics de tickets demandés doivent être rapprochés des usages habituels de votre domaine.
Sources : MITRE ATT&CK ↗ · MITRE ATT&CK ↗ · Microsoft Learn ↗ · Microsoft Learn ↗ · ZATAZ ↗
Article rédigé et vérifié par Cyberfaille, avec assistance IA. Un doute, une correction ? écrivez-nous.