Active Directory reste une cible prioritaire lors d’un test d’intrusion interne. Dès qu’un attaquant obtient un simple compte domaine, même peu privilégié, il peut commencer à interroger l’annuaire, cartographier les utilisateurs, chercher les mauvaises configurations et tenter d’identifier des chemins vers des privilèges plus élevés.
Parmi les attaques les plus connues contre Active Directory, Kerberoasting occupe une place importante. Elle est redoutable parce qu’elle ne nécessite pas forcément de privilèges administrateur au départ. Un utilisateur authentifié du domaine peut parfois récupérer des tickets Kerberos associés à des comptes de service, puis tenter de casser leur mot de passe hors ligne.
Cet article explique le principe du Kerberoasting, son fonctionnement, les risques associés, les méthodes de détection et les bonnes pratiques pour s’en protéger.
Qu’est-ce que le Kerberoasting ?
Le Kerberoasting est une attaque visant les comptes de service Active Directory qui possèdent un SPN, pour Service Principal Name.
Un SPN permet d’associer un service à un compte Active Directory. Par exemple, une application web, une base SQL ou un service métier peut tourner avec un compte de domaine dédié. Ce compte peut être lié à un SPN pour permettre l’authentification Kerberos.
Le problème, c’est que tout utilisateur authentifié du domaine peut demander un ticket de service, appelé TGS, pour un SPN donné. Ce ticket est chiffré avec le secret du compte de service. L’attaquant ne casse donc pas directement Active Directory. Il récupère un ticket légitime, puis tente de retrouver le mot de passe du compte de service en mode hors ligne.
C’est précisément ce qui rend l’attaque dangereuse : une fois le ticket récupéré, la phase de cracking peut se faire sans générer davantage de bruit sur le réseau.
Pour une référence technique reconnue, MITRE ATT&CK documente cette technique sous l’identifiant T1558.003 – Kerberoasting .
Pourquoi cette attaque est dangereuse
Le Kerberoasting devient critique lorsque les comptes de service utilisent des mots de passe faibles, anciens ou jamais renouvelés. Dans beaucoup d’environnements, ces comptes ont été créés il y a plusieurs années, parfois avec des mots de passe choisis manuellement.
On retrouve encore trop souvent des mots de passe de comptes de service du type :
Service2023!P@ssw0rdSQLEntreprise123!NomDuClient2024!
Ces mots de passe peuvent paraître complexes, mais ils restent souvent prévisibles. Avec un bon dictionnaire, des règles Hashcat ou John the Ripper, ils peuvent tomber rapidement.
Le vrai risque dépend ensuite des privilèges du compte compromis. Si le compte de service est simple utilisateur, l’impact reste limité. Mais dans la vraie vie, on voit encore des comptes de service membres de groupes sensibles, avec des droits élevés sur des serveurs, des bases de données ou parfois même sur le domaine.
Un compte de service compromis peut alors devenir une étape vers une compromission plus large : rebond sur serveur, extraction de secrets, mouvement latéral, élévation de privilèges, voire prise de contrôle complète du domaine.
Comment fonctionne l’attaque
Le scénario classique est assez simple.
L’attaquant dispose d’un compte domaine valide. Ce compte peut provenir d’un phishing, d’un mot de passe réutilisé, d’un poste compromis ou d’un accès VPN mal protégé.
Depuis le réseau interne, il interroge Active Directory pour lister les comptes ayant un SPN. Ensuite, il demande un ticket Kerberos pour ces services. Ces tickets sont exportés dans un format compatible avec un outil de cracking.
Dans un lab ou un cadre autorisé, l’attaque peut être réalisée avec des outils connus comme Impacket, Rubeus, CrackMapExec ou PowerView.
Exemple avec Impacket :
GetUserSPNs.py domaine.local/user:MotDePasse -dc-ip 192.168.1.10 -requestCette commande permet d’identifier les comptes avec SPN et de demander les tickets associés. Les tickets récupérés peuvent ensuite être testés avec un outil de cracking.
Avec Hashcat, on peut utiliser un mode adapté aux tickets Kerberos TGS. Avec John the Ripper, le principe est similaire : on fournit le hash, puis on utilise une wordlist et des règles de mutation.
Si vous voulez approfondir la partie cracking, vous pouvez aussi lire l’article sur John the Ripper , qui complète bien ce sujet.
Kerberoasting avec CrackMapExec
CrackMapExec est souvent utilisé en pentest Active Directory parce qu’il permet d’automatiser de nombreuses actions : énumération SMB, test d’identifiants, récupération d’informations domaine, recherche de partages accessibles, etc.
Dans un contexte autorisé, il peut aussi aider à identifier les comptes exploitables dans une logique de Kerberoasting. L’intérêt est surtout de l’intégrer dans une méthodologie plus globale : découverte du domaine, identification des comptes de service, récupération des tickets, puis analyse du niveau de risque.
Vous pouvez faire le lien avec l’article CrackMapExec : Guide Complet + Cheatsheet Pentest Active Directory pour replacer Kerberoasting dans une approche plus large du pentest AD.
Comment détecter le Kerberoasting
La détection du Kerberoasting repose principalement sur la surveillance des demandes de tickets Kerberos.
L’événement Windows le plus intéressant est souvent le 4769, qui correspond à une demande de ticket de service Kerberos. Pris seul, cet événement n’est pas forcément suspect, car Kerberos génère naturellement beaucoup de tickets dans un environnement Windows.
Il faut donc chercher des comportements anormaux :
- nombreuses demandes TGS en peu de temps ;
- demandes visant plusieurs SPN différents ;
- utilisation d’un chiffrement faible comme RC4 ;
- requêtes provenant d’un poste utilisateur inhabituel ;
- compte utilisateur demandant des tickets pour des services qu’il n’utilise normalement pas ;
- activité Kerberos inhabituelle en dehors des heures de bureau.
La détection devient plus efficace lorsqu’elle est corrélée avec d’autres signaux : authentifications suspectes, exécution d’outils offensifs, connexions SMB anormales, ou apparition d’un compte compromis sur plusieurs machines.
Un SIEM bien configuré peut générer des alertes lorsqu’un utilisateur demande un volume anormal de tickets de service. Microsoft Defender for Identity, Splunk, Sentinel, Elastic ou Wazuh peuvent aider à mettre en place ce type de détection.
Comment se protéger contre le Kerberoasting
La meilleure défense consiste à rendre le cracking inutile ou beaucoup trop coûteux.
Première mesure : utiliser des mots de passe très longs et réellement aléatoires pour les comptes de service. Un mot de passe de 25 ou 30 caractères généré aléatoirement résiste beaucoup mieux qu’un mot de passe court avec quelques caractères spéciaux.
Deuxième mesure : privilégier les gMSA, pour Group Managed Service Accounts. Ces comptes de service managés permettent à Active Directory de gérer automatiquement des mots de passe longs, complexes et régulièrement renouvelés. C’est une excellente pratique pour réduire le risque Kerberoasting.
Troisième mesure : limiter les privilèges des comptes de service. Un compte utilisé par une application n’a généralement aucune raison d’être administrateur du domaine. Il faut appliquer strictement le principe du moindre privilège.
Quatrième mesure : faire régulièrement l’inventaire des SPN. Les comptes inutilisés, anciens ou mal configurés doivent être supprimés ou corrigés. Beaucoup d’environnements gardent des SPN historiques liés à des applications qui n’existent plus.
Cinquième mesure : désactiver autant que possible les chiffrements faibles. L’usage de RC4 augmente fortement le risque, car il rend certains tickets plus faciles à attaquer. Il faut favoriser AES lorsque c’est possible.
Enfin, il faut intégrer Kerberoasting dans les audits réguliers Active Directory. Un audit défensif peut identifier les comptes vulnérables avant qu’un attaquant ne le fasse.
Bonnes pratiques à retenir
Pour réduire le risque Kerberoasting, il faut surtout agir sur trois axes : comptes de service, mots de passe et supervision.
Les comptes de service doivent être connus, documentés et limités à leurs besoins réels. Leurs mots de passe doivent être longs, aléatoires et renouvelés. Quand c’est possible, les gMSA doivent remplacer les comptes de service classiques.
Côté détection, il faut surveiller les demandes anormales de tickets Kerberos, notamment via l’événement 4769. Une alerte ne doit pas se déclencher sur une seule demande, mais sur un comportement inhabituel : volume élevé, cible rare, chiffrement faible ou poste source suspect.
Conclusion
Le Kerberoasting est une attaque simple dans son principe, mais redoutable dans ses conséquences. Elle illustre parfaitement un problème fréquent en cybersécurité : ce n’est pas toujours la faille technique qui expose l’entreprise, mais une mauvaise hygiène Active Directory accumulée pendant des années.
Des comptes de service trop privilégiés, des mots de passe faibles, des SPN oubliés et une supervision insuffisante peuvent transformer un simple compte utilisateur compromis en point d’entrée vers des actifs critiques.
Pour se protéger, il faut traiter les comptes de service comme des comptes sensibles, auditer régulièrement Active Directory et surveiller les comportements Kerberos inhabituels. Dans un pentest interne, Kerberoasting fait partie des techniques incontournables à tester. Dans une démarche défensive, c’est surtout un excellent indicateur de maturité Active Directory.
