Detection prevention kerberoasting commence par un constat simple : tout principal Active Directory authentifié qui détient un TGT valide peut demander des tickets de service pour des SPN, et certains de ces tickets peuvent encore être cassés hors ligne si le compte de service ciblé est suffisamment faible. Le plus difficile n’est pas de connaître le nom de l’attaque. Le plus difficile est de prouver quels comptes adossés à des SPN restent réellement exploitables dans votre domaine, quelle télémétrie est vraiment utile, et quelles actions de remédiation réduisent le risque de façon mesurable sans casser la production.
Qu’est-ce que le Kerberoasting ?
Le Kerberoasting est l’abus du mécanisme d’émission des tickets de service Kerberos pour obtenir du matériel de ticket qui peut ensuite être cassé hors ligne contre le secret d’un compte de service. MITRE classe ce comportement sous T1558.003 Kerberoasting.
Dans Active Directory, Kerberos utilise les Service Principal Names (SPN) pour associer une instance de service au compte qui exécute ce service. Microsoft documente les SPN comme l’identifiant que Kerberos utilise pour localiser le principal cible d’un service. Lorsqu’un client demande un ticket de service Kerberos pour ce SPN, le ticket est généré pour le compte de service qui le possède.
Cela ne signifie pas que tous les comptes ayant un SPN présentent le même niveau de danger. L’exposition réelle dépend de quatre éléments :
- Le compte repose-t-il sur un mot de passe géré manuellement par un utilisateur, ou sur une identité de service mieux gérée ?
- Le secret du compte est-il ancien, prévisible ou jamais renouvelé ?
- Quels types de chiffrement Kerberos sont réellement utilisés pour l’émission des tickets ?
- Quels accès le compte ouvre-t-il si ses identifiants sont finalement récupérés ?
C’est pour cela que le Kerberoasting n’est pas seulement un problème Kerberos. C’est aussi un problème d’hygiène des comptes de service, de politique de chiffrement et, très souvent, de gouvernance des privilèges.
Pourquoi le Kerberoasting reste un risque réel dans Active Directory
Le Kerberoasting reste pertinent parce que beaucoup de domaines traînent encore une longue queue de comptes de service legacy :
- comptes de service adossés à des utilisateurs créés il y a des années ;
- comptes avec
PasswordNeverExpires; - comptes dont le mot de passe a été défini une fois puis oublié ;
- comptes qui dépendent encore de
RC4pour des raisons de compatibilité ; - comptes qui ont accumulé au fil du temps des droits d’admin local, de sauvegarde, SQL, d’orchestration ou des droits délégués.
C’est cette combinaison qui rend la technique exploitable. Le chemin de requête Kerberos est légitime. Le cassage hors ligne se fait hors du domaine. Le rayon d’impact dépend ensuite de ce que le compte de service permet de faire.
Cela explique aussi pourquoi la sécurité des mots de passe Active Directory et les comptes obsolètes et sur-privilégiés dans AD comptent autant ici. Un ticket de service n’est pas l’objectif final. L’objectif est de récupérer un secret qui ouvre ensuite un chemin de privilèges plus large.
Préconditions d’une exposition Kerberoasting réelle
Une finding Kerberoasting mérite une priorisation forte lorsque la plupart des points suivants sont vrais :
- le compte possède un ou plusieurs SPN ;
- le compte repose sur un mot de passe géré manuellement au lieu d’une identité de service gérée ;
- le mot de passe est ancien, rarement renouvelé ou exempt d’expiration ;
RC4est encore utilisé ou encore accepté alors que des types de chiffrement plus solides devraient déjà être en place ;- le compte ouvre des possibilités significatives de mouvement latéral ou d’élévation de privilèges ;
- l’environnement ne révise pas régulièrement l’inventaire des SPN et l’ownership des comptes de service.
La documentation Microsoft sur msDS-SupportedEncryptionTypes est directement pertinente ici. Le KDC s’appuie sur cette information lorsqu’il génère un ticket de service pour le compte. La documentation actuelle de Microsoft sur Kerberos rappelle aussi que RC4 est insuffisant, en voie de retrait, et qu’il doit être audité puis remédié dès que des types de chiffrement plus robustes sont disponibles.
C’est la différence opérationnelle entre un simple item d’inventaire et une vraie exposition Kerberoasting. Un compte à SPN à faible valeur, doté d’un secret long, aléatoire et récemment renouvelé, n’est pas le même problème qu’un compte SQL adossé à un utilisateur, encore en RC4 et doté de droits étendus sur des serveurs.
Comment fonctionne le Kerberoasting
Microsoft documente les SPN comme le mécanisme par lequel Kerberos associe une instance de service au compte qui s’authentifie pour ce service. En pratique, cela signifie qu’un principal de domaine disposant d’un TGT valide peut demander un TGS pour un compte de service qui possède un SPN.
MITRE décrit le Kerberoasting comme l’obtention d’un ticket TGS susceptible d’être attaqué en force brute. Le point important pour les défenseurs est que le cassage se fait hors ligne. Une fois le matériel de ticket collecté, l’attaquant n’a plus besoin d’interagir en continu avec le domaine pour tester des hypothèses de mot de passe.
Les points défensifs à retenir sont :
- la requête elle-même est du trafic Kerberos légitime ;
- le ticket est lié au secret du compte de service, pas à une session interactive sur l’hôte cible ;
- l’exploitabilité réelle dépend du type de chiffrement et de la robustesse du mot de passe ;
- l’impact métier dépend des privilèges détenus par le compte de service après compromission.
La bonne question n’est donc pas « le Kerberoasting est-il possible dans ce domaine ? ». La bonne question est : « quels comptes à SPN restent assez crackables pour compter, et qu’ouvriraient-ils s’ils étaient récupérés ? »
Detection prevention kerberoasting : ce que les défenseurs doivent réellement examiner
La détection du Kerberoasting doit être construite comme une corrélation, pas comme une théorie reposant sur un événement unique.
Commencer par l’Event ID 4769
Microsoft documente 4769 comme l’événement généré lorsque le KDC émet un ticket de service Kerberos. Il est journalisé sur les contrôleurs de domaine. Pour l’analyse Kerberoasting, c’est généralement l’événement natif le plus utile car il capture directement le chemin de requête TGS.
Ce qu’il faut regarder :
- une rafale de requêtes TGS émises par un même compte ou une même source sur une courte période ;
- des demandes portant sur de nombreux SPN distincts qui ne correspondent pas au comportement normal du demandeur ;
TicketEncryptionType = 0x17uniquement si RC4 n’est plus censé être nécessaire dans cet environnement ;- des requêtes SPN provenant de postes ou d’utilisateurs qui n’interagissent normalement pas avec ces services.
La documentation Microsoft actuelle sur la remédiation de RC4 recommande explicitement d’auditer l’usage de RC4 dans les événements 4768 et 4769, et explique que RC4 est en voie de retrait. Cela rend cette télémétrie utile, mais seulement dans son contexte. RC4 à lui seul ne prouve pas un Kerberoasting. Dans certains domaines, cela indique encore un problème de compatibilité plutôt qu’une activité hostile.
Utiliser l’Event ID 4768 comme contexte de corrélation
4768 documente l’émission d’un TGT, pas la demande de ticket de service sur laquelle repose le Kerberoasting. Il faut donc le traiter comme un contexte d’investigation, pas comme le détecteur principal.
Il aide notamment à répondre à des questions comme :
- quel compte a obtenu le TGT qui précède l’activité TGS inhabituelle ?
- quels systèmes sources sont impliqués ?
- lorsque le schéma enrichi de l’événement est disponible, que suggèrent les champs liés aux types de chiffrement supportés et au fallback ?
Ce contexte est utile lorsqu’on enquête sur un cluster inhabituel de 4769. Il ne remplace pas 4769.
Maintenir un inventaire continu des comptes à SPN
La qualité de détection s’améliore fortement si vous maintenez un inventaire continu de :
- tous les comptes avec SPN ;
- l’âge des mots de passe ;
PasswordNeverExpires;- le fait qu’il s’agisse d’un compte utilisateur classique ou d’une identité de service gérée ;
- les privilèges effectifs et la portée d’admin local ;
- la posture de chiffrement lorsqu’elle est pertinente dans votre environnement.
Un simple travail défensif d’inventaire suffit souvent à faire remonter les candidats à haut risque avant même qu’une activité suspecte ne soit investiguée.
Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName,pwdLastSet,PasswordNeverExpires,msDS-SupportedEncryptionTypes |
Select-Object SamAccountName,ServicePrincipalName,PasswordNeverExpires,pwdLastSet,msDS-SupportedEncryptionTypes
Le but n’est pas de collecter tous les SPN puis de paniquer. Le but est d’identifier les comptes qui combinent exposition SPN, hygiène faible du secret et privilèges significatifs.
Baseline obligatoire
Une posture sérieuse de détection du Kerberoasting exige une baseline des modèles normaux de tickets de service. Cela implique de savoir :
- quels hôtes demandent habituellement des tickets pour quels services ;
- quels comptes de service sont accédés en masse à cause de comportements applicatifs légitimes ;
- quels outils d’administration, de scan ou de gestion peuvent générer légitimement une activité TGS large.
Sans cette baseline, « beaucoup de 4769 » n’est pas une stratégie de détection. C’est seulement un point de départ.
Prévention, hardening et remediation
La prévention du Kerberoasting revient surtout à faire des comptes de service adossés à des SPN de mauvaises cibles pour le cassage, et de mauvaises cibles pour l’élévation de privilèges.
1. Réduire les comptes de service adossés à des utilisateurs quand c’est possible
Microsoft documente les group Managed Service Accounts (gMSA) comme des comptes de domaine gérés offrant une gestion automatique des mots de passe et une gestion simplifiée des SPN, y compris sur plusieurs serveurs.
Cela ne rend pas un gMSA magiquement hors de portée de Kerberos. En revanche, cela en fait un bien meilleur choix défensif qu’un compte utilisateur géré à la main dont le mot de passe n’a pas bougé depuis des années.
Là où la plateforme le permet, faire migrer les services éligibles depuis des comptes de service adossés à des utilisateurs vers des gMSA est l’un des contrôles préventifs les plus utiles.
2. Faire tourner les mots de passe des comptes de service legacy
La guidance Microsoft sur RC4 précise que des comptes anciens peuvent ne pas avoir de clés AES si leur mot de passe n’a jamais été réinitialisé après l’introduction du support Kerberos moderne. Cela compte, car réinitialiser un mot de passe ne change pas seulement le secret : cela peut aussi rafraîchir le jeu de clés utilisables par le compte.
Pour les comptes de service legacy qui ne peuvent pas encore migrer vers un gMSA :
- faites tourner le mot de passe ;
- rendez-le long et aléatoire ;
- vérifiez que le service continue de fonctionner proprement ensuite ;
- documentez l’ownership pour éviter que le compte ne redevienne de la dette technique partagée.
3. Réduire RC4 avec méthode, pas à l’aveugle
Microsoft documente désormais explicitement RC4 comme un mécanisme insuffisant, en voie de retrait, qu’il faut auditer via la télémétrie Kerberos. Microsoft documente aussi des moyens concrets de restreindre ou désactiver RC4, notamment via la politique de types de chiffrement Kerberos autorisés.
La bonne conclusion n’est pas « désactivez RC4 partout immédiatement ». La bonne conclusion est :
- identifiez les endroits où RC4 est encore utilisé ;
- déterminez si la dépendance est réelle ou seulement héritée d’une configuration non entretenue ;
- faites migrer les comptes et hôtes éligibles vers des réglages compatibles AES ;
- surveillez les échecs d’authentification pendant le rollout.
La documentation Microsoft elle-même avertit qu’une désactivation de RC4 peut casser des dépendances legacy si elles n’ont pas été validées en amont. Cette réserve doit faire partie de tout plan sérieux de durcissement Kerberoasting.
4. Réviser les privilèges derrière le compte de service
La prévention reste incomplète si vous améliorez seulement le mot de passe sans revoir les privilèges.
Il faut examiner si le compte de service possède :
- des droits d’admin local sur de nombreux serveurs ;
- des droits délégués dans AD ;
- des privilèges de sauvegarde, d’orchestration ou de déploiement ;
- des accès à forte valeur sur des bases de données ou des partages ;
- des chemins implicites vers l’imbrication dangereuse de groupes AD ou la dérive des accès privilégiés dans Active Directory.
Un compte de service durci mais sur-privilégié transforme encore une récupération de secret en incident majeur.
5. Nettoyer les SPN qui ne correspondent plus à de vrais services
Microsoft documente setspn comme l’outil permettant de lire, ajouter, supprimer et interroger les SPN. C’est important opérationnellement, car des SPN obsolètes ou dupliqués ne sont pas seulement un problème d’hygiène. Ils brouillent l’ownership et élargissent inutilement la surface de revue.
Si un SPN ne correspond plus à un vrai service, supprimez-le. Si une application n’a plus besoin d’une identité utilisateur dédiée, retirez le compte au lieu de le conserver indéfiniment.
Validation après remediation
Une remédiation Kerberoasting n’est pas terminée parce qu’un mot de passe a été changé une fois ou parce qu’un type de ticket a été modifié en labo. La validation doit prouver que l’exposition de production a réellement bougé.
Conservez au minimum un jeu de preuves comme celui-ci :
| Preuve | Pourquoi elle compte |
|---|---|
| Inventaire à jour des comptes à SPN | Confirme le périmètre revu et l’ownership |
| Posture d’âge / expiration des mots de passe de comptes de service | Montre si les comptes legacy crackables ont réellement été remédiés |
| Classification comptes gérés vs comptes adossés à des utilisateurs | Prouve où la migration vers gMSA a réduit le risque lié aux secrets manuels |
Baseline Kerberos pour 4769 | Confirme la logique de détection après les changements |
| Revue de l’usage de RC4 avec exceptions documentées | Distingue les dépendances legacy acceptées de la dérive non pilotée |
| Revue de privilèges pour les comptes de service à forte valeur | Montre si le rayon d’impact a baissé, pas seulement le problème de mot de passe |
Les questions de validation doivent être concrètes :
- quels comptes SPN critiques reposent encore sur des mots de passe gérés manuellement ?
- lesquels montrent encore un âge de mot de passe trop élevé ou une exemption d’expiration ?
- quels services nécessitent encore RC4, et qui a validé cette dépendance ?
- quels comptes ouvriraient encore un mouvement latéral significatif s’ils étaient récupérés ?
- la baseline
4769du domaine s’est-elle réellement améliorée après les remédiations ?
C’est la différence entre « nous avons changé quelques mots de passe de comptes de service » et « nous avons réduit de manière mesurable le risque Kerberoasting ».
Comment EtcSec mesure le risque de Kerberoasting
EtcSec doit décrire les conditions qui rendent le Kerberoasting praticable, pas prétendre prouver une attaque en cours à partir d’un seul événement.
La finding centrale est KERBEROASTING_RISK, utile lorsqu’un compte possède un SPN et présente encore un ou plusieurs traits qui rendent le cassage hors ligne matériellement plus réaliste.
Les findings de contexte qui augmentent la priorité incluent :
PASSWORD_NEVER_EXPIRESPASSWORD_POLICY_WEAKKERBEROS_RC4_FALLBACK
Ensemble, ces checks aident à structurer une revue répétable de :
- quels comptes de service sont exposés ;
- lesquels restent assez faibles pour réellement compter ;
- lesquels se trouvent sur des chemins de privilèges importants ;
- lesquels nécessitent encore des preuves de remediation après les changements.
Contrôles liés
Le Kerberoasting doit être revu avec des contrôles identité adjacents qui amplifient souvent le même chemin de compromission :
- AS-REP Roasting, parce que les deux techniques transforment du matériel Kerberos en risque de cassage hors ligne ;
- Sécurité des mots de passe Active Directory, parce que la qualité et la rotation des mots de passe déterminent l’exploitabilité ;
- Comptes obsolètes et sur-privilégiés dans AD, parce que les comptes oubliés portent souvent les SPN les plus dangereux ;
- Délégation Kerberos, parce que les identités de service se recoupent souvent avec l’exposition à la délégation ;
- Audit de sécurité Active Directory, parce que le Kerberoasting n’est qu’un item d’une revue AD plus large, orientée preuve ;
- Supervision sécurité AD, parce que
4769ne devient utile que si la collecte d’événements et la baseline sont déjà en place.
Références primaires
- MITRE ATT&CK T1558.003: Kerberoasting
- 4769(S, F): A Kerberos service ticket was requested
- 4768(S, F): A Kerberos authentication ticket (TGT) was requested
- Detect and remediate RC4 usage in Kerberos
- Kerberos authentication overview in Windows Server
- Group Managed Service Accounts overview
- Service principal names
- Setspn
- ms-DS-Supported-Encryption-Types attribute
- Audit Directory Service Access
