Extraction des mots de passe des comptes de service avec Kerberoasting

Dans notre article sur la reconnaissance LDAP reconnaissance post, nous avons exploré comment un attaquant peut effectuer une reconnaissance pour découvrir des comptes de service à cibler dans un domaine Active Directory (AD). Examinons maintenant une méthode qu'un attaquant peut utiliser pour compromettre ces comptes et exploiter leurs privilèges : le Kerberoasting. Cette technique est particulièrement effrayante car elle ne nécessite aucun privilège d'administrateur dans le domaine, est très facile à réaliser et est pratiquement indétectable.

Kerberoasting : Vue d'ensemble

Kerberoasting est une attaque qui abuse d'une fonctionnalité du protocole Kerberos pour récolter les hachages de mots de passe des comptes utilisateurs d'Active Directory : tout utilisateur de domaine authentifié peut demander des tickets de service pour un compte en spécifiant son Nom Principal de Service (SPN), et le service de délivrance de tickets (TGS) sur le contrôleur de domaine retournera un ticket qui est chiffré en utilisant le hachage NTLM du mot de passe du compte.

Par conséquent, une fois qu'un adversaire a découvert les SPN des comptes de service en utilisant une tactique telle que la reconnaissance LDAP, il peut collecter des tickets pour tous ces comptes. En emportant ces données hors ligne, ils peuvent effectuer une attaque par force brute pour craquer le mot de passe en clair de chaque compte de service — sans aucun risque de détection ou de blocage de compte.

Il ne faut que quelques minutes à un attaquant pour accéder à un domaine, collecter des tickets et commencer le processus de craquage. À partir de là, c'est juste une question de temps avant qu'ils ne compromettent un ou plusieurs comptes de service, qu'ils peuvent utiliser pour voler ou chiffrer des données sensibles ou causer d'autres dommages.

Les adversaires se concentrent sur les comptes de service pour plusieurs raisons. Premièrement, ces comptes ont souvent des privilèges bien plus étendus que les autres comptes d'utilisateurs AD, donc les compromettre donne à l'attaquant un accès plus important. De plus, les mots de passe des comptes de service changent rarement, donc l'adversaire est susceptible de conserver l'accès pendant longtemps. Pour comprendre les types d'accès qui peuvent être obtenus en utilisant le Kerberoasting, regardez la liste des SPN d'Active Directory maintenue par Sean Metcalf.

Kerberoasting : Comment ça fonctionne

Étape 1. Obtenez les SPNs des comptes de service.

. Il existe de nombreuses façons d'obtenir ces SPN, y compris :

• Requêtes PowerShell et reconnaissance LDAP
• Module Active Directory pour PowerShell
• Script GetUserSPNs dans le Kerberoast toolkit
• Commande Get-NetUser de PowerSploit

Étape 2. Demandez des tickets de service pour les SPN des comptes de service.

Exécutez simplement quelques lignes de PowerShell, et un ticket de service sera retourné et stocké en mémoire dans votre système.

      Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList ‘MSSQLSvc/jefflab-sql02.jefflab.local:1433’
      

Étape 3. Extraire les tickets de service en utilisant Mimikatz.

Mimikatz extraira les tickets locaux et les sauvegardera sur le disque pour un craquage hors ligne. Installez simplement Mimikatz et lancez une seule commande :

Étape 4. Déchiffrer les tickets.

Les tickets Kerberos sont chiffrés avec le mot de passe du compte de service associé au SPN spécifié dans la demande de ticket. Les outils Kerberoasting fournissent un script Python pour craquer les tickets et fournir leurs mots de passe en clair en exécutant un dictionnaire de hachages de mots de passe contre eux. Cela peut nécessiter une certaine configuration pour s'assurer que vous avez l'environnement requis pour exécuter le script, mais ce blog couvre ces détails.

Alternativement, vous pouvez collecter les tickets Kerberos en utilisant le script GetUserSPNs et les déchiffrer avec l'outil de récupération de mot de passe Hashcat.

Protection contre les attaques de Kerberoasting

La principale atténuation des attaques de Kerberoasting consiste à s'assurer que tous les comptes de service utilisent des mots de passe longs et complexes qui sont plus difficiles à craquer, et à les faire tourner régulièrement pour minimiser le temps pendant lequel le compte pourrait être utilisé par un adversaire qui parvient à craquer un mot de passe. L'utilisation de comptes de service gérés par groupe est une meilleure pratique pour attribuer des mots de passe aléatoires et complexes qui peuvent être changés automatiquement.

Puisque les adversaires craquent les tickets hors ligne, le processus ne génère aucun trafic réseau, rendant cette partie de l'attaque indétectable. Mais vous pouvez repérer les étapes antérieures en surveillant Active Directory avec une solution de sécurité solide. En particulier, les comptes de service sont normalement utilisés depuis les mêmes systèmes de la même manière, alors surveillez les demandes d'authentification anormales. De plus, surveillez les pics de demandes de tickets de service.

Enfin, les spécialistes de la sécurité recommandent également de désactiver le chiffrement basé sur RC4. Sinon, même si un compte utilisateur prend en charge le chiffrement AES, un attaquant peut demander un ticket chiffré en RC4, qui est plus facile à craquer qu'un ticket créé avec le chiffrement AES.

Kerberoasting permet à un attaquant disposant de n’importe quel compte de domaine standard de demander des tickets chiffrés pour les comptes de service, puis de casser leurs mots de passe hors ligne, où aucune politique de verrouillage ne s’applique et où le contrôleur de domaine n’est pas impliqué.

Qu'est-ce que le Kerberoasting ?

Il réussit contre les comptes faiblement protégés, et 76 % des organisations ne gouvernent ni ne surveillent pleinement les identités non humaines, y compris les comptes de service, selon le Netwrix 2026 Data and Identity Security Report.

L'attaque commence par une liste de ces comptes, qu'un attaquant peut constituer via LDAP reconnaissance.

Kerberoasting est une attaque d'Active Directory (AD) qui transforme une fonctionnalité normale de Kerberos en une opportunité de craquer des mots de passe. Kerberos permet à tout utilisateur authentifié de demander un ticket de service à un contrôleur de domaine, et le ticket est chiffré avec une clé dérivée du mot de passe du compte de service.

Comment les attaquants extraient les mots de passe des comptes de service avec Kerberoasting

L'extraction s'effectue en quatre étapes, et Rubeus ainsi que GetUserSPNs.py d'Impacket combinent les trois premières en une seule commande tandis que Hashcat gère la quatrième.

1. Trouvez les comptes qui ont des SPN

2. Demandez des tickets de service pour les SPN

Un attaquant qui collecte ces tickets peut deviner les mots de passe hors ligne jusqu'à ce qu'un soit déchiffré. Les cibles sont des comptes utilisateurs avec service principal names (SPNs), y compris la plupart des service accounts. L'attaque ne nécessite pas de droits élevés pour commencer.

Un attaquant avec n'importe quel compte de domaine peut lister les comptes avec SPN via une requête LDAP, une requête PowerShell ou le module Active Directory pour PowerShell. Rubeus et GetUserSPNs.py énumèrent également seuls les comptes kerberoastables, et Rubeus peut fournir des statistiques à leur sujet sans envoyer de demandes de ticket.

Un SPN nomme une instance de service en trois parties, comme dans MSSQLSvc/jefflab-sql02.jefflab.local:1433Expand, qui donne la classe de service, l'hôte et le port. La classe de service indique ce qu'un compte compromis peut atteindre, comme l'accès à la base de données pour MSSQLSvc.

Deux lignes de PowerShell demandent un ticket pour un SPN nommé, et Windows le stocke en mémoire.

Rubeus automatise la demande pour chaque compte kerberoastable et peut écrire les résultats dans un fichier.

Kerberos prouve l'identité et laisse l'autorisation au service (RFC 4120), donc le contrôleur de domaine ne vérifie pas si le demandeur peut utiliser le service avant d'émettre un ticket. Tout utilisateur authentifié reçoit donc un ticket chiffré avec une clé dérivée du mot de passe du compte de service.

3. Extraire les tickets de service

Impacket's GetUserSPNs.py fait de même avec son option -request, qui génère les tickets dans un format accepté par John the Ripper et Hashcat.

Lorsqu’un compte avec la pré-authentification Kerberos désactivée existe, l’option /nopreauth de Rubeus demande des tickets de service en envoyant des messages AS-REQ (Authentication Service Request) via celui-ci.

4. Cassez les tickets

Un ticket demandé avec les lignes PowerShell ci-dessus reste en mémoire jusqu'à ce que l'attaquant l'exporte. Mimikatz liste les tickets dans la session en cours et les écrit dans des fichiers pour un craquage hors ligne avec une seule commande.

Rubeus et GetUserSPNs.py avec -request sautent cette étape, car ils génèrent directement des hashes cassables.

Pourquoi le type de chiffrement du ticket est important

Le cracking s'exécute sur le matériel de l'attaquant, donc aucune politique de verrouillage ne s'applique, et le contrôleur de domaine ne voit rien après la demande de ticket. Hashcat teste les mots de passe devinés contre chaque ticket et récupère le mot de passe en clair lorsqu'une supposition le déchiffre. Il accepte le format généré par GetUserSPNs.py et dispose d'un mode séparé pour chaque type de chiffrement.

Netwrix Threat Prevention bloque en temps réel les attaques DCSync, Kerberoasting et Pass-the-Hash sur Active Directory. Demandez une démo.

Les tickets RC4 se cassent le plus vite

Le type de chiffrement d’un ticket, RC4 (Rivest Cipher 4) ou AES (Advanced Encryption Standard), détermine la rapidité avec laquelle un attaquant peut le deviner, et Microsoft a modifié ses paramètres par défaut en 2026.

Les attaquants peuvent demander RC4 pour les comptes qui prennent en charge AES

Les tickets AES ralentissent les tentatives de devinette mais cèdent toujours aux mots de passe faibles

La clé d’un ticket RC4 est le hash NT LAN Manager (NTLM) du compte, un hash non salé du mot de passe (RFC 4757). Sans sel, le même mot de passe produit la même clé pour chaque compte, et chaque tentative coûte un calcul de hash.

Rubeus demande par défaut le type de chiffrement le plus élevé pris en charge pour chaque compte, mais son option /usetgtdeleg demande des tickets RC4 pour les comptes qui supportent AES, et son option /rc4opsec ignore les comptes activés AES.

GetUserSPNs.py d'Impacket demande également RC4 par défaut sauf si -no-rc4 est défini. Supprimer RC4 des types de chiffrement pris en charge par le compte de service ferme cette voie de rétrogradation.

Les trois types peuvent être craqués, donc la longueur et l'aléa du mot de passe déterminent le résultat.

La mise à jour d'avril 2026 a modifié le contrôleur de domaine par défaut

Protection des comptes de service contre le Kerberoasting

Les clés AES proviennent d'une dérivation de clé salée qui effectue 4 096 itérations par défaut (RFC 3962), rendant chaque tentative plus coûteuse. L'option /aes de Rubeus cible les comptes activés AES et demande leurs tickets AES, et Hashcat dispose d'un mode séparé pour chaque type de chiffrement de ticket.

Le changement ne concerne pas les comptes qui autorisent explicitement RC4 via cet attribut, et une valeur par défaut de domaine définie explicitement est respectée telle qu'écrite. Ces comptes peuvent toujours recevoir des tickets RC4, ce sont donc eux qu'il faut trouver en premier.

La mise à jour KB5073381 de Microsoft a commencé avec des événements d’audit en janvier 2026. Le 14 avril 2026, elle a modifié la valeur par défaut du contrôleur de domaine pour que les comptes sans valeur explicite msDS-SupportedEncryptionTypes soient supposés ne prendre en charge que AES-SHA1, et les mises à jour publiées en juillet 2026 ou après ne prennent plus en charge la valeur du registre qui permettait aux administrateurs d’annuler ce changement.

Chaque contrôle limite une partie différente de l’attaque, et tous utilisent les fonctionnalités natives d’Active Directory et de Windows.

Déplacer les comptes de service vers des comptes gérés

Définissez des mots de passe longs et aléatoires pour le reste

Réinitialisez les mots de passe et appliquez AES

Recherche de Netwrix sur l'attaque BadSuccessor, qui exploite les dMSA pour l'escalade de privilèges, recommande d'auditer qui détient les droits CreateChild, WriteProperty, WriteDACL, GenericAll et WriteOwner sur les unités organisationnelles avant leur déploiement.

Les comptes de service gérés en groupe (gMSAs) utilisent des mots de passe aléatoires de 120 caractères que Active Directory fait tourner, de sorte que les attaquants n'ont rien de faible à deviner. Les comptes de service gérés délégués (dMSAs) ont également Active Directory qui gère les identifiants.

Pour les comptes qui ne peuvent pas être déplacés, MITRE ATT&CK recommande des mots de passe idéalement de 25 caractères ou plus. La génération aléatoire est aussi importante que la longueur, car les listes de mots pour le craquage sont construites à partir des mots de passe choisis par les utilisateurs.

Les clés AES sont générées lorsqu'un mot de passe est défini ou modifié, donc un compte dont le mot de passe est antérieur au support AES n'en possède pas jusqu'à sa réinitialisation, et un compte uniquement AES sans clés ne peut pas recevoir de tickets.

Supprimez les SPN dont les comptes n'ont pas besoin

Testez chaque service avant de le restreindre, car les services qui ne supportent pas AES, y compris certains appareils non Windows, cessent de s'authentifier une fois RC4 supprimé.

Réinitialisez d'abord le mot de passe, puis vérifiez l'attribut msDS-SupportedEncryptionTypes du compte pour les paramètres explicites RC4 et limitez-le à AES128 et AES256 (valeur 24).

Chaque SPN sur un compte utilisateur rend ce compte accessible, alors listez-les tous et comparez chacun avec un service en cours d'exécution.

Contrôlez qui peut ajouter des SPN

Limiter les privilèges du compte de service

Enregistrer les demandes de tickets de service

Le compte krbtgt apparaît dans les résultats par conception et ne doit pas être modifié. Pour tout autre SPN pointant vers un hôte désaffecté ou une application retirée, vérifiez-le avec setspn -L <account>Expand et supprimez-le avec setspn -D <SPN> <account>Expand.

Dans le targeted Kerberoasting, un attaquant disposant des droits GenericAll, GenericWrite, WriteProperty ou Validated Write sur Service Principal Name d’un compte ajoute un SPN, rendant le compte vulnérable au roast. Vérifiez les listes de contrôle d’accès sur les comptes de service et retirez ces droits à toute personne ne gérant pas le compte. Les membres du groupe intégré Account Operators les détiennent généralement.

Activez la sous-catégorie Audit Kerberos Service Ticket Operations sur les contrôleurs de domaine, qui enregistre chaque requête sous l’ID d’événement 4769. MITRE conseille de surveiller les requêtes anormales utilisant RC4, indiquées par Ticket Encryption Type 0x17, tandis que les tickets AES affichent 0x11 ou 0x12.

Le roasting via un compte sans pré-authentification envoie plutôt des messages AS-REQ, donc ces requêtes sont enregistrées comme Événement ID 4768, et la même vérification RC4 s’applique à elles.

Un mot de passe compromis donne à un attaquant tout ce que le compte peut faire. Retirez les comptes de service des groupes privilégiés tels que Domain Admins, et accordez uniquement les droits utilisés par le service, selon le principe du moindre privilège. Ce travail fait partie d’un plus vaste renforcement de la sécurité d’Active Directory.

Le dépôt Kerberos-Crypto de Microsoft inclut un script Get-KerbEncryptionUsage.ps1 qui lit les deux types d’événements, et l’exécuter avec -Encryption RC4 et -SearchScope AllKdcs liste les requêtes RC4 sur chaque contrôleur de domaine.

Comment Netwrix aide à se défendre contre le Kerberoasting

Bloquez les tentatives de Kerberoasting en temps réel

Les produits Netwrix ajoutent trois contrôles au-delà des paramètres natifs de Windows : bloquer l’attaque, détecter ce qui suit et évaluer Active Directory pour les faiblesses qu’il exploite.

Détecter les attaques basées sur l'identité

Netwrix Threat Prevention bloque les tentatives de Kerberoasting, DCSync et Pass-the-Hash contre Active Directory avant qu’elles ne réussissent. Cela donne aux équipes un point d’application au moment de l’attaque, que la revue des journaux ne peut pas fournir.

Évaluer la posture de sécurité d’Active Directory

Commencez par les comptes qui autorisent encore RC4

Netwrix Threat Manager identifie le vol d’identifiants, les mouvements latéraux et l’escalade de privilèges, qui sont des attaques basées sur l’identité pouvant suivre un mot de passe de compte de service compromis. Il détecte également lorsqu’un SPN est ajouté à un compte privilégié, étape de configuration du Kerberoasting ciblé.

Le Kerberoasting nécessite seulement un mot de passe faible de compte de service, donc la défense fonctionne mieux comme une séquence appliquée compte par compte.

Netwrix PingCastle évalue la sécurité d’Active Directory et identifie les mauvaises configurations, les chemins d’attaque et l’exposition aux privilèges.

Les comptes qui ne peuvent pas devenir des comptes gérés ont besoin de mots de passe longs et aléatoires pour résister aux tentatives de devinette hors ligne. La demande de ticket est la seule étape que les défenseurs peuvent encore observer, donc la journaliser couvre ce que l’hygiène des mots de passe ne peut pas.

Après le changement par défaut de Microsoft en avril 2026, les comptes qui autorisent explicitement RC4, soit sur le compte, soit via un paramètre de domaine par défaut explicitement défini, peuvent toujours recevoir des tickets RC4, ils passent donc en premier. Déplacez ce qui peut être déplacé vers des comptes gérés, puis réinitialisez le reste et limitez-les à AES.

Demandez une démo pour voir comment Netwrix Threat Prevention arrête les tentatives de Kerberoasting contre vos comptes de service Active Directory avant qu'elles ne réussissent.