L’attaque Kerberoasting expliquée : d’un utilisateur AD ordinaire au Domain Admin

Confiez-nous un seul compte de domaine valide sur presque n’importe quel réseau Active Directory, et il y a de bonnes chances que nous repartions avec le mot de passe d’un compte de service avant midi. Aucun exploit. Aucun malware. Aucun droit d’administrateur. Juste Kerberos qui fait exactement ce pour quoi il a été conçu. C’est cela, une attaque Kerberoasting, et elle reste l’un des chemins les plus fiables d’un utilisateur ordinaire jusqu’au Domain Admin que nous empruntons lors de tests internes.

Ce qui la rend tenace, c’est qu’il n’existe aucun correctif contre elle. La faiblesse tient à une pile de comptes de service dotés de mots de passe faibles, choisis par des humains et jamais renouvelés, adossés à un protocole qui remettra à tout utilisateur authentifié le matériel nécessaire pour les casser. Une attaque Kerberoasting est discrète, patiente et presque entièrement hors ligne. C’est précisément cette combinaison qui fait que les défenseurs continuent de passer à côté.

Ci-dessous, nous détaillons le fonctionnement des tickets de service Kerberos, pourquoi un Service Principal Name (SPN) place les comptes de service dans le viseur, comment l’attaque s’enchaîne vers la domination du domaine, et les mesures d’atténuation qui survivent réellement au contact de la production. La technique correspond à MITRE ATT&CK T1558.003.

Points clés

• Une attaque Kerberoasting permet à tout utilisateur de domaine authentifié de demander des tickets de service Kerberos pour les comptes possédant un SPN, puis de casser ces tickets hors ligne afin de récupérer le mot de passe en clair. Aucun privilège élevé requis.
• Le ticket est chiffré avec une clé dérivée du mot de passe du compte de service, si bien que les mots de passe faibles ou périmés tombent rapidement face à hashcat, surtout lorsque RC4 (type de chiffrement 0x17) est encore autorisé.
• Les comptes de service sont systématiquement surdotés en privilèges : un seul mot de passe cassé signifie donc souvent des droits d’administrateur local sur de nombreux hôtes, l’accès à des données sensibles ou une voie directe vers le Domain Admin.
• La détection s’appuie sur les anomalies de l’événement Kerberos 4769 (requêtes RC4, volume élevé provenant d’un seul utilisateur) et sur des comptes SPN pièges qu’aucun service réel ne devrait jamais interroger.
• Le correctif durable, ce sont les group Managed Service Accounts (gMSA) ou des mots de passe aléatoires de 25 caractères ou plus, l’application d’AES, l’élagage des SPN inutilisés et le moindre privilège appuyé par un cloisonnement des administrateurs (admin tiering).

Qu’est-ce qu’une attaque Kerberoasting ?

Une attaque Kerberoasting est une technique de cassage de mots de passe hors ligne visant les comptes de service Active Directory. N’importe quel utilisateur de domaine peut demander à un Domain Controller un ticket de service pour n’importe quel compte possédant un SPN enregistré. Une partie de ce ticket est chiffrée avec une clé dérivée du mot de passe du compte de service. L’attaquant s’empare du ticket, s’éloigne, et casse le mot de passe par force brute sur son propre matériel, sans jamais retoucher au Domain Controller.

Le danger réside dans l’asymétrie. Demander un ticket est une action normale que chaque poste de travail effectue des centaines de fois par jour, si bien qu’elle se fond dans le bruit. Le cassage se déroule sur le matériel de l’attaquant, invisible pour vos journaux. Et les comptes les plus susceptibles de porter un SPN, comme SQL Server, les pools d’applications IIS et divers services HTTP ou MSSQL, sont généralement ceux qui disposent des accès les plus larges et des mots de passe les plus anciens. C’est la pire combinaison possible.

Comment fonctionnent réellement les tickets de service Kerberos ?

L’authentification Kerberos comporte trois rouages : le client, le Key Distribution Center (KDC, présent sur chaque Domain Controller) et le service cible. Lorsque vous vous connectez, le client envoie un AS-REQ et reçoit en retour un Ticket Granting Ticket (TGT) dans l’AS-REP. Le TGT est la preuve de votre identité.

Lorsque vous voulez atteindre un service, le client présente ce TGT et envoie un TGS-REQ nommant le SPN, par exemple MSSQLSvc/db01.acme-corp.local:1433. Le KDC répond par un TGS-REP contenant un ticket de service. Voici le détail qui compte : le ticket est chiffré avec la clé à long terme du compte auquel appartient le SPN. Pour RC4, cette clé est littéralement le hachage NT du compte. Pour AES, c’est une clé dérivée du mot de passe et d’un sel.

Vient maintenant la partie que les attaquants adorent. Le KDC ne vérifie jamais si vous êtes réellement autorisé à utiliser le service. Il confirme seulement que vous détenez un TGT valide, puis renvoie un ticket chiffré avec la clé du compte de service. L’autorisation intervient plus tard, au niveau du service lui-même. Le KDC remettra donc volontiers à tout utilisateur authentifié un blob chiffré dérivé du mot de passe de n’importe quel compte de service. Il suffit de demander poliment, et il dit oui.

Qu’est-ce qu’un SPN et pourquoi les comptes de service sont-ils la cible ?

Un Service Principal Name est une chaîne unique qui relie une instance de service au compte qui l’exécute, afin que Kerberos sache quelle clé utiliser pour chiffrer le ticket. Les comptes d’ordinateur ont aussi des SPN, mais leurs mots de passe sont de longues chaînes aléatoires qui se renouvellent d’elles-mêmes, ce qui les rend pratiquement incassables. Les cibles molles sont les comptes utilisateurs dotés de SPN : les comptes de service du domaine qu’un humain a créés et configurés à la main.

C’est là que le risque se concentre. Au cours de nos missions, nous trouvons régulièrement des comptes de service dont le mot de passe a été défini il y a cinq ans ou plus, choisi par un administrateur qui voulait quelque chose de mémorisable, et souvent réutilisé d’un environnement à l’autre. Les exceptions à la politique de mots de passe sont ici la norme, parce que “l’application casse si le mot de passe change.” Trouver ces comptes est trivial pour tout membre du domaine, puisque les SPN sont des attributs d’annuaire lisibles. Une seule ligne les fait ressortir :

# Native, no tooling required
setspn -Q */*

# Impacket, from a non-domain-joined attacker box
GetUserSPNs.py acme-corp.local/lowpriv:'Password123' -dc-ip 10.0.0.10 -request

# Or on-host with Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

Comment se déroule l’attaque Kerberoasting, étape par étape ?

L’attaque est courte et ne nécessite rien de plus qu’un seul compte de domaine fonctionnel. Énumérer les comptes possédant un SPN, demander un TGS pour chacun, extraire la portion chiffrée de chaque ticket, puis la casser hors ligne. Quatre mouvements, et seuls les deux premiers touchent au réseau.

La phase de requête est celle où Rubeus et le GetUserSPNs d’Impacket font leur travail. Ils interrogent l’annuaire à la recherche d’objets utilisateur dont l’attribut servicePrincipalName est défini, déclenchent un TGS-REQ pour chacun et mettent en forme les tickets renvoyés en chaînes prêtes pour hashcat. La plupart des outils vous laissent aussi forcer RC4 afin de récupérer le type de hachage le plus rapide, ce qui est précisément le comportement qu’un défenseur peut surveiller. Un hachage Kerberoast RC4 commence par $krb5tgs$23$; AES256 revient sous la forme $krb5tgs$18$.

La phase de cassage relève du pur calcul hors ligne. Les tickets RC4 utilisent le mode hashcat 13100. Les tickets AES sont plus lents, mais s’effritent tout de même face à une liste de mots correcte, avec les modes 19600 (AES128) et 19700 (AES256).

# RC4 (etype 23 / 0x17) - fastest to crack
hashcat -m 13100 hashes.txt rockyou.txt -r rules/best64.rule

# AES256 (etype 18) - slower, still viable against weak passwords
hashcat -m 19700 hashes.txt rockyou.txt

Notez que rien ne rappelle le Domain Controller pendant que le cassage tourne. Une fois les tickets capturés, l’attaquant peut débrancher le câble réseau et continuer à moudre. Un mot de passe court ou basé sur un dictionnaire peut tomber en quelques minutes. Voilà pourquoi la robustesse du mot de passe du compte de service, c’est tout l’enjeu.

Pourquoi des mots de passe de compte de service faibles rendent-ils cela si dangereux ?

Parce que toute la défense du ticket chiffré repose sur l’entropie du mot de passe, et rien d’autre. Kerberos ne limite pas le rythme des tentatives hors ligne. Il n’y a aucun verrouillage de compte. Il n’y a aucune alerte une fois que le ticket a quitté le KDC. Un mot de passe de dix caractères bâti sur un mot du dictionnaire et deux chiffres n’est pas un ralentisseur face à un GPU moderne. Un mot de passe véritablement aléatoire de 25 caractères est un mur de brique.

La réutilisation et l’obsolescence aggravent les choses. Les mots de passe des comptes de service ne changent presque jamais, si bien que celui que vous cassez aujourd’hui peut avoir été valide pendant des années, et valide en même temps sur les environnements de test, de préproduction et de production. Nous avons vu un seul compte cassé déverrouiller des dizaines de serveurs simplement parce qu’il avait été ajouté au groupe Administrateurs local de chaque machine sur laquelle il tournait.

Comment Kerberoasting s’enchaîne-t-il jusqu’au Domain Admin ?

Casser le mot de passe est le pivot, pas la fin. Ce qui vient ensuite dépend du niveau de privilège du compte, et les comptes de service sont réputés pour la dérive des privilèges. Les chaînes que nous rencontrons le plus souvent ressemblent à ceci :

• Le compte est administrateur local sur de nombreux hôtes ; nous obtenons donc l’exécution de code et extrayons davantage d’identifiants de LSASS sur chacun d’eux, ramassant au passage des sessions d’administrateur de domaine mises en cache.
• Le compte a été ajouté directement dans Domain Admins ou un groupe tout aussi puissant, généralement “pour le moment” pendant une migration, puis jamais retiré. C’est toute la mission résumée en une ligne.
• Le compte détient des droits d’annuaire dangereux, comme la capacité de réinitialiser les mots de passe d’autres utilisateurs ou d’écrire l’appartenance à un groupe, ce que BloodHound tracera comme un chemin vers le Tier 0.

Le fait est qu’une attaque Kerberoasting s’arrête rarement à un seul compte. C’est un point d’appui qui se transforme en déplacement latéral, puis en élévation de privilèges, et les chemins les plus courts vers le Domain Admin sont presque toujours ceux dont personne ne soupçonnait l’existence. BloodHound rend ces chemins rapides à trouver, pour l’attaquant comme pour vous.

Comment détecter une attaque Kerberoasting ?

La détection se concentre sur les requêtes de tickets de service Kerberos, journalisées sous l’événement 4769 sur les Domain Controllers. Prises isolément, ces entrées ne sont que du bruit. Le signal tient à la forme. Surveillez un compte utilisateur qui demande des tickets pour un grand nombre de SPN distincts dans une fenêtre de temps resserrée, et surtout les requêtes qui spécifient RC4 (type de chiffrement de ticket 0x17) dans un environnement censé fonctionner en AES. Les clients modernes négocient AES par défaut, donc une rafale de requêtes RC4 est une empreinte Kerberoasting classique.

Le contrôle au signal le plus fort que nous recommandons est un SPN piège. Créez un compte utilisateur leurre, attachez-lui un SPN qui ne correspond à aucun service réel, donnez-lui un long mot de passe aléatoire et n’y touchez jamais. Aucun processus légitime ne devrait jamais demander son ticket ; un seul 4769 nommant ce compte est donc un indicateur d’intrusion quasi certain, avec presque aucun faux positif. Associez-le à une alerte sur les volumes anormaux de RC4 et vous attraperez la plupart des roastings opportunistes avant même que le cassage ne se termine.

Comment prévenir Kerberoasting ?

La prévention revient à supprimer les deux ingrédients : les mots de passe faibles et l’exposition inutile. Par ordre de priorité, voici ce que nous conseillons à nos clients.

• Passez aux gMSA. Les Group Managed Service Accounts reçoivent de longs mots de passe aléatoires que le domaine renouvelle de lui-même, de sorte que leurs tickets sont pratiquement incassables. Migrez chaque compte de service qui peut en prendre en charge un.
• Utilisez de longs mots de passe aléatoires là où les gMSA ne conviennent pas. Pour les comptes qui doivent rester des objets utilisateur standard, définissez un mot de passe aléatoire de 25 caractères ou plus. À cette longueur, même un ticket RC4 ne vaut pas la peine d’être cassé.
• Imposez AES et abandonnez RC4. Réglez msDS-SupportedEncryptionTypes sur AES uniquement et retirez RC4 à l’échelle du domaine. Cela ralentit toute tentative de cassage et transforme chaque requête RC4 restante en un signal de détection net.
• Appliquez le moindre privilège. Sortez les comptes de service de Domain Admins et des autres groupes de Tier 0, n’accordez que les droits dont le service a réellement besoin, et auditez l’appartenance aux groupes d’administrateurs locaux.
• Élaguez les SPN périmés. Chaque SPN sur un compte utilisateur est une surface d’attaque. Retirez les SPN des comptes qui n’exécutent plus le service concerné.
• Adoptez un cloisonnement des administrateurs. Isolez les identités de Tier 0 pour qu’un compte de service applicatif cassé ne puisse jamais atteindre les contrôleurs de domaine ni les identifiants d’administrateur de domaine, tout simplement.

Comment CyberXplore vous aide

Kerberoasting est l’une des premières choses vers lesquelles notre équipe se tourne lors de toute mission interne, parce que c’est rapide, discret et que ça marche si souvent. Notre évaluation de la sécurité Active Directory cartographie vos véritables chemins d’attaque comme le ferait un intrus : énumération des SPN, test de la robustesse des mots de passe des comptes de service et traçage de chaque chaîne qui aboutit au Domain Admin, avant de vous remettre une liste de correctifs priorisée construite autour des gMSA, de l’application d’AES et du cloisonnement. Si vous voulez savoir si un seul utilisateur hameçonné pourrait s’emparer de tout votre domaine, demandez un devis et nous vous montrerons exactement jusqu’où cela va.

FAQ

Une attaque Kerberoasting nécessite-t-elle des droits d’administrateur ?

Non, et c’est pourquoi elle est partout. Tout compte de domaine authentifié, y compris un utilisateur à faibles privilèges ou un service compromis, peut énumérer les SPN et demander des tickets de service. Le KDC ne vérifie pas l’autorisation avant d’émettre le ticket, donc aucun droit particulier n’est nécessaire pour repartir avec du matériel cassable.

Le passage à AES arrête-t-il complètement Kerberoasting ?

Non, mais cela aide beaucoup. Les tickets AES sont bien plus lents à casser que RC4, si bien qu’un mot de passe robuste derrière AES est pratiquement à l’abri. Cela dit, un mot de passe faible derrière AES peut encore tomber, donc AES ne remplace pas de longs mots de passe aléatoires ni les gMSA. L’imposer convertit aussi toute requête RC4 résiduelle en un signal de détection utile.

Combien de temps faut-il pour casser un hachage Kerberoast ?

Cela dépend entièrement de la robustesse du mot de passe et du type de chiffrement. Un ticket RC4 faible bâti sur un mot du dictionnaire peut tomber en quelques secondes à quelques minutes sur un GPU moderne. Un mot de passe véritablement aléatoire de 25 caractères, ou un mot de passe gMSA, ne se cassera dans aucun délai réaliste. Il n’y a aucun verrouillage côté serveur pour freiner l’attaquant, donc l’entropie est la seule défense qui compte.

Quelle est la différence entre Kerberoasting et l’AS-REP roasting ?

Les deux cassent du matériel Kerberos hors ligne, mais ils frappent des cibles différentes. Kerberoasting (T1558.003) attaque les comptes de service dotés de SPN en cassant des tickets de service. L’AS-REP roasting (T1558.004) vise les comptes dont la préauthentification Kerberos est désactivée et casse l’AS-REP à la place. L’AS-REP roasting peut se faire sans aucun identifiant valide, du moment que vous connaissez un nom d’utilisateur cible.

Les gMSA sont-ils vraiment immunisés contre Kerberoasting ?

En pratique, oui. Un mot de passe gMSA est une longue valeur aléatoire que le domaine renouvelle automatiquement ; ainsi, même si son ticket peut être demandé et capturé, le casser est irréalisable. La seule réserve : quiconque se voit accorder le droit de lire le mot de passe géré du gMSA peut le récupérer directement, alors protégez soigneusement cette autorisation.

Comment puis-je tester si mon domaine est vulnérable ?

Menez une énumération contrôlée des comptes dotés de SPN et évaluez la robustesse de leurs mots de passe, idéalement dans le cadre d’une évaluation Active Directory complète. Le GetUserSPNs d’Impacket ou Rubeus feront remonter chaque compte roastable, et les SPN pièges couplés à la surveillance de l’événement 4769 vous diront si des tentatives sont déjà en cours. Le faire comme un exercice autorisé vous donne la même vue qu’un attaquant, avant qu’il ne la prenne.