Kerberoasting : protéger vos comptes de service avant qu'ils ne soient cassés hors ligne
Le Kerberoasting ne nécessite aucun privilège particulier : un simple compte du domaine suffit. Il cible les comptes utilisateurs qui portent un nom de principal de service, très souvent des comptes de service anciens, privilégiés et dotés de mots de passe qui n'ont pas changé depuis des années. La bonne nouvelle, c'est que les parades sont connues et efficaces.
Le principe de l'attaque
Lorsqu'un utilisateur veut accéder à un service, il demande au contrôleur de domaine un ticket de service (TGS) pour le SPN correspondant. Une partie de ce ticket est chiffrée avec la clé dérivée du mot de passe du compte qui porte le SPN. L'attaquant demande ces tickets, les extrait et tente de retrouver le mot de passe hors ligne, sans générer d'échec d'authentification. Les comptes d'ordinateur sont peu exposés, car leur mot de passe est long, aléatoire et renouvelé automatiquement. Les comptes utilisateurs avec SPN, eux, dépendent entièrement de la qualité de leur mot de passe.
RC4 contre AES
Le type de chiffrement change beaucoup la donne. Un ticket chiffré en RC4 est nettement plus rapide à attaquer qu'un ticket AES. Or de nombreux comptes de service acceptent encore RC4, soit parce que l'attribut msDS-SupportedEncryptionTypes n'est pas renseigné, soit parce que leur mot de passe date d'avant la génération des clés AES dans le domaine. Microsoft a engagé la sortie progressive de RC4 pour Kerberos ; suivez le calendrier annoncé et testez vos applications avant de forcer AES.
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes, adminCount |
Select-Object SamAccountName, PasswordLastSet, msDS-SupportedEncryptionTypes, adminCount, ServicePrincipalName
Les mesures qui fonctionnent
- Supprimer les SPN inutiles. Un SPN laissé sur un compte après la décommission d'une application offre une cible gratuite.
- Passer aux comptes de service gérés. Les gMSA disposent d'un mot de passe aléatoire long, renouvelé automatiquement, qui rend le cassage irréaliste. Windows Server 2025 introduit les dMSA (comptes de service gérés délégués), conçus pour faciliter la migration des comptes de service classiques ; ils exigent un environnement Windows Server 2025 et méritent d'être évalués prudemment.
- Imposer des mots de passe longs et aléatoires pour les comptes qui ne peuvent pas migrer : 25 caractères ou plus, générés et stockés dans un coffre.
- Forcer AES et réinitialiser le mot de passe des comptes anciens pour générer les clés AES.
- Retirer les privilèges excessifs. Un compte de service membre des Admins du domaine transforme un mot de passe cassé en compromission totale.
Priorité absolue. Commencez par les comptes avec SPN qui ont adminCount=1 ou un mot de passe de plus de trois ans. Ce sont eux que les attaquants ciblent en premier.
Détecter le Kerberoasting
L'événement 4769 (demande de ticket de service), journalisé sur les contrôleurs de domaine lorsque l'audit correspondant est activé, est la source principale. Les signaux utiles sont un type de chiffrement 0x17 (RC4) dans un environnement censé utiliser AES, un grand nombre de demandes pour des SPN différents depuis un même compte en peu de temps, ou des demandes pour des services rarement utilisés. Un compte leurre doté d'un SPN et jamais utilisé légitimement constitue aussi un détecteur très fiable.
Ce qu'un audit vérifie
- les comptes utilisateurs portant un SPN, leur âge de mot de passe et leurs privilèges ;
- les types de chiffrement acceptés par ces comptes ;
- l'usage effectif des gMSA ;
- la configuration de l'audit des tickets de service sur les contrôleurs de domaine.