Kerberoasting : casser les mots de passe de service sans jamais toucher au contrôleur de domaine

Lors des audits d’Active Directory, le Kerberoasting fait partie des attaques vérifiées systématiquement, tant cette technique est efficace, rapide et discrète. En quelques secondes, un simple compte utilisateur dépourvu du moindre privilège peut récupérer de quoi casser, hors ligne et sans bruit, les mots de passe de comptes parfois très puissants. Cet article détaille son fonctionnement, pourquoi elle réussit si souvent, et surtout comment s’en prémunir.

Un peu de Kerberos et de SPN

Dans un domaine Windows, l’authentification repose sur Kerberos, un protocole fondé sur des tickets délivrés par le contrôleur de domaine. Le principe remonte aux années 1980 (le projet Athena du MIT), et Microsoft l’a adopté comme mécanisme d’authentification par défaut depuis Windows 2000. Chaque service accessible via Kerberos est identifié par un SPN, pour Service Principal Name, une étiquette du type MSSQLSvc/serveur.entreprise.local:1433 qui relie un service (une base SQL, un serveur web, un partage) à un compte de service dans l’annuaire.

Pour rappel, un compte de service est un compte utilisateur dédié à faire tourner une application. Il porte souvent des droits élevés et son mot de passe est rarement changé, car le modifier risque d’interrompre l’application qui en dépend. C’est un secret qui vieillit mal.

Pourquoi les comptes de service sont un tel aimant

Ces comptes concentrent tous les défauts que recherche un attaquant. Ils ont été créés il y a longtemps, souvent lors de l’installation d’un logiciel, avec un mot de passe choisi à la main par un administrateur pressé. Ce mot de passe n’expire généralement jamais, car une expiration signifierait une panne applicative. Et pour couronner le tout, ces comptes se retrouvent fréquemment membres de groupes très privilégiés, parfois Administrateurs du domaine, « le temps de faire fonctionner l’application », puis on oublie de revenir en arrière. Un attaquant le sait, et cible en priorité ces SPN.

Le mécanisme de l’attaque

Le point clé tient en une phrase : n’importe quel utilisateur authentifié du domaine peut demander un ticket de service (un TGS, pour Ticket-Granting Service) pour n’importe quel SPN. C’est un fonctionnement parfaitement normal de Kerberos, pas une faille. Or une partie de ce ticket est chiffrée avec une clé dérivée directement du mot de passe du compte de service. En obtenant le ticket, on obtient donc un échantillon chiffré que l’on pourra attaquer tranquillement.

L’attaquant énumère les SPN de l’annuaire, demande les tickets correspondants, puis les extrait. Avec GetUserSPNs.py, de la suite Impacket, une seule commande suffit depuis Linux :

GetUserSPNs.py entreprise.local/utilisateur:MotDePasse -request -outputfile tickets.txt

Côté Windows, l’outil Rubeus fait la même chose depuis un poste déjà compromis, et sait cibler les comptes les plus intéressants :

Rubeus.exe kerberoast /outfile:tickets.txt

Point crucial : à aucun moment l’attaquant n’a besoin d’écrire sur le contrôleur de domaine ni de tester des mots de passe contre lui. Tout le cassage se fait ensuite sur sa propre machine, hors ligne. Il n’y a donc ni compte verrouillé, ni pic d’échecs d’authentification visible dans les journaux.

Le cassage hors ligne

Une fois les tickets récupérés, l’attaquant les soumet à un outil de cassage comme hashcat. Le format Kerberos TGS correspond au mode 13100 :

hashcat -m 13100 tickets.txt dictionnaire.txt -r regles.rule

Le paramètre -r applique un jeu de règles qui reproduit les habitudes humaines : majuscule initiale, chiffre final, substitutions classiques. Contre un mot de passe faible du type Serveur2021, le résultat tombe en quelques secondes sur un simple ordinateur portable équipé d’une carte graphique. Et c’est là tout le problème :

• les comptes de service ont souvent des mots de passe courts, choisis par un humain il y a des années ;
• ils ne sont presque jamais renouvelés ;
• ils cumulent des privilèges élevés, parfois jusqu’à l’administration complète du domaine.

Un seul mot de passe faible cassé, et l’attaquant hérite directement des droits du compte, sans exploit ni élévation de privilège supplémentaire. C’est un raccourci spectaculaire entre « je suis un utilisateur quelconque » et « je contrôle l’annuaire ».

RC4, le carburant discret de l’attaque

Un détail technique aggrave souvent la situation : par compatibilité, beaucoup de tickets sont encore chiffrés avec l’algorithme RC4, dérivé du condensat NTLM du mot de passe. Or RC4 se prête particulièrement bien au cassage massif. En forçant l’usage d’AES pour les comptes de service, on rend le cassage nettement plus coûteux. Les outils d’attaque le savent : Rubeus, par exemple, demande volontiers des tickets en RC4 lorsqu’ils sont disponibles, précisément parce qu’ils sont plus faciles à traiter.

Ce que révèle le terrain

Sur une mission type, l’énumération remonte régulièrement plusieurs dizaines de SPN. Il suffit qu’un seul corresponde à un compte au mot de passe daté pour ouvrir une brèche. Les comptes de sauvegarde, de supervision ou de base de données reviennent fréquemment, souvent dotés de privilèges élevés, protégés par un mot de passe reprenant le nom de l’éditeur du logiciel suivi d’une année. L’impact métier est immédiat : qui contrôle un tel compte contrôle l’authentification de toute l’entreprise. La BOX Oxyscan repère justement ces comptes de service exposés au Kerberoasting sur l’ensemble d’un annuaire, ce qui permet de les corriger avant qu’un attaquant ne les trouve.

Corriger la faille : passer aux comptes de service gérés

Puisque le Kerberoasting n’exploite pas un défaut logiciel mais la faiblesse d’un mot de passe, la correction consiste à rendre ce mot de passe impossible à casser. Les comptes de service gérés de groupe (gMSA, pour group Managed Service Accounts) répondent exactement à ce besoin : leur mot de passe est généré aléatoirement par le domaine, s’étend sur 240 octets et est renouvelé automatiquement, sans aucune intervention humaine. Un attaquant qui récupère un ticket chiffré avec un tel secret peut y consacrer toutes les cartes graphiques qu’il veut, il ne le retrouvera pas.

Pour rappel, c’est déjà le comportement des comptes machine (ceux dont le nom se termine par un $) : leur mot de passe est aléatoire et très long, ce qui les rend insensibles au Kerberoasting. Le gMSA étend simplement ce principe aux comptes qui exécutent les services applicatifs.

La mise en place tient en trois commandes PowerShell, côté contrôleur de domaine. On génère d’abord, une seule fois pour tout le domaine, la clé racine du service de distribution de clés (KDS) :

Add-KdsRootKey -EffectiveImmediately

Malgré son nom, l’option -EffectiveImmediately ne rend la clé utilisable qu’après sa réplication sur l’ensemble des contrôleurs de domaine, avec un délai de sécurité pouvant atteindre dix heures. Ce délai doit être respecté en production. On crée ensuite le compte géré, en indiquant son nom DNS et le ou les hôtes autorisés à récupérer son mot de passe :

New-ADServiceAccount -Name sql-service -DNSHostName sql-service.exemple.local -PrincipalsAllowedToRetrieveManagedPassword "GRP-SRV-SQL$"

Puis on installe le compte sur la machine qui exécutera le service :

Install-ADServiceAccount sql-service

Il ne reste qu’à désigner ce compte comme identité du service. Dans le gestionnaire de serveur, on renseigne le compte géré, reconnaissable à son suffixe $, comme compte personnalisé, ici pour l’identité d’un pool d’applications IIS :

Tous les logiciels ne savent pas encore fonctionner avec un gMSA. Pour ces cas résiduels, la règle est double : un mot de passe d’au moins vingt-cinq caractères, tiré aléatoirement et conservé dans un coffre, et le strict respect du moindre privilège, car un compte de service n’a presque jamais besoin d’appartenir aux administrateurs du domaine. On force par ailleurs le chiffrement AES des tickets, bien plus coûteux à casser que le RC4 hérité, et on surveille les demandes anormalement nombreuses de tickets de service, souvent le premier signe d’une campagne de Kerberoasting en cours.

Conclusion

Le Kerberoasting n’exploite pas un bug : il exploite un mauvais mot de passe posé sur un compte trop puissant. C’est pourquoi il figure parmi les techniques les plus rentables pour un attaquant interne, et parmi les plus faciles à négliger côté défense. La bonne nouvelle est que les contre-mesures sont connues, documentées (notamment par le MITRE et par l’ANSSI) et efficaces.

Conseils : attribuer aux comptes de service des mots de passe très longs (25 caractères et plus) ou, mieux, migrer vers des comptes de service gérés de groupe (gMSA), dont le mot de passe est renouvelé automatiquement par le domaine ; appliquer le principe de moindre privilège (aucun compte de service ne devrait être administrateur du domaine sans justification solide), forcer le chiffrement AES plutôt que RC4, et surveiller les demandes massives de tickets TGS, souvent le premier signe d’une attaque en cours.

Pour aller plus loin

• MITRE ATT&CK, technique T1558.003 (Kerberoasting), description, détection et mesures d’atténuation.
• ANSSI, recommandations de sécurisation d’un annuaire Active Directory.
• Microsoft Learn, présentation des comptes de service gérés de groupe (gMSA).
• hashcat, l’outil de référence pour le cassage hors ligne (mode 13100 pour les tickets Kerberos).
• Suite Impacket (GetUserSPNs.py), la boîte à outils open source utilisée pour la collecte des tickets.