TL;DR
Le Kerberoasting est une technique d’attaque post-exploitation ciblant les environnements Active Directory. Elle exploite une faiblesse structurelle du protocole Kerberos : n’importe quel utilisateur authentifié peut demander un ticket de service (ST) chiffré avec le mot de passe d’un compte applicatif, puis tenter de retrouver ce mot de passe hors ligne par attaque par dictionnaire ou force brute.
L’attaque ne nécessite aucun privilège élevé pour démarrer. Un simple compte utilisateur du domaine suffit. C’est l’un des premiers réflexes d’un pentester après avoir obtenu un premier accès sur un réseau Windows.
0
privilège requis pour lancer l’attaque depuis un compte du domaine
RC4
algorithme par défaut : tickets crackables en quelques minutes sur GPU
88 %
des domaines AD contiennent au moins un compte vulnérable (SANS, 2024)
Dans la grande majorité des missions de pentest Active Directory, le Kerberoasting figure dans les premières actions menées après l’obtention d’un pied initial sur le domaine. Et pour une raison simple : l’attaque exploite une propriété fondamentale du protocole Kerberos, présente dans tous les environnements Windows Active Directory sans exception, et ne nécessite aucun droit particulier pour être lancée.
Elle est à distinguer d’autres techniques d’attaque sur Kerberos comme l’AS-REP Roasting (qui cible les comptes n’ayant pas de pré-authentification Kerberos requise) ou l’attaque Pass-the-Ticket (qui réutilise des tickets existants). Ces trois vecteurs s’appuient sur Kerberos, mais ils n’exploitent pas le même mécanisme et ne ciblent pas les mêmes comptes. Le Kerberoasting cible spécifiquement les comptes utilisateurs possédant un attribut SPN (Service Principal Name) renseigné.
Cet article explique comment fonctionne le Kerberoasting au niveau du protocole, pourquoi certains environnements y sont plus exposés que d’autres, comment la détection est possible côté Blue Team, et quelles mesures réduisent réellement la surface d’exposition.
Protocole
Kerberos en quelques lignes : ce qu’il faut comprendre avant l’attaque
TGT, TGS, KDC, SPN : le vocabulaire qui explique la vulnérabilité
Kerberos est le protocole d’authentification utilisé par défaut dans tous les environnements Windows Active Directory depuis Windows 2000. Comprendre son fonctionnement est indispensable pour comprendre pourquoi le Kerberoasting est possible structurellement, et pas seulement à cause d’une erreur de configuration.
Lorsqu’un utilisateur s’authentifie sur le domaine, il obtient du contrôleur de domaine (KDC, Key Distribution Center) un premier ticket : le TGT (Ticket Granting Ticket). Ce ticket prouve son identité sur le domaine pour une durée définie (généralement 10 heures).
Lorsque cet utilisateur veut accéder à un service du domaine (un serveur de fichiers, une base de données, une application web interne), il présente son TGT au KDC et demande un Ticket de Service (ST, Service Ticket) pour ce service spécifique. Le KDC génère ce ticket en chiffrant une partie de son contenu avec le mot de passe (ou plus précisément sa dérivée cryptographique) du compte associé au service. L’utilisateur reçoit ce ticket et le présente au service pour s’authentifier.
Un service est identifié dans Active Directory par son attribut SPN (Service Principal Name). C’est cet attribut qui dit au KDC "ce compte est associé à tel service". Tout compte du domaine disposant d’un attribut SPN renseigné peut faire l’objet d’une demande de ticket de service de la part de n’importe quel utilisateur authentifié sur le domaine. C’est cette propriété que le Kerberoasting exploite.
Glossaire rapide
Key Distribution Center. Le contrôleur de domaine qui distribue les tickets Kerberos.
Ticket Granting Ticket. Ticket d’identité obtenu lors de l’authentification initiale sur le domaine.
Service Ticket. Ticket permettant l’accès à un service spécifique, chiffré avec le secret du compte service.
Service Principal Name. Attribut AD identifiant un service associé à un compte. Présence d’un SPN = ticket de service demandable par n’importe qui.
Ticket Granting Service. Phase du protocole où l’utilisateur demande un ST au KDC.
Mécanisme
Comment fonctionne le Kerberoasting ?
De la demande de ticket à la récupération du mot de passe en clair
Le Kerberoasting tire son nom de la technique de rôtis au barbecue (roasting), par analogie avec le fait de "griller" (craquer) des tickets Kerberos. L’attaque se déroule en trois phases distinctes, chacune ne nécessitant qu’un accès réseau standard sur le domaine.
Identification des comptes vulnérables
Un attaquant disposant d’un compte utilisateur quelconque du domaine peut requêter l’annuaire LDAP pour lister tous les comptes possédant un attribut SPN renseigné. Cette requête ne nécessite aucun droit particulier : n’importe quel utilisateur authentifié peut lire ces attributs. L’outil BloodHound effectue cette cartographie automatiquement lors de la phase de reconnaissance du domaine et affiche les comptes vulnérables avec leur niveau de criticité.
Demande du ticket de service (ST) et récupération
Pour chaque compte vulnérable identifié, l’attaquant initie une demande TGS auprès du KDC, en demandant un ticket de service pour le SPN du compte ciblé. Le KDC génère le ticket et le chiffre avec la dérivée du mot de passe du compte de service. Aucune interaction avec le service cible n’a lieu : seule une communication avec le contrôleur de domaine est nécessaire. Le ticket est alors exporté dans un format lisible par les outils de cracking.
Cryptanalyse hors ligne : attaque par dictionnaire ou force brute
Le ticket récupéré contient des informations partiellement connues de l’attaquant (SPN, clé de session), ce qui permet une attaque de type known-plaintext attack. Le craquage est effectué hors ligne, sur la machine de l’attaquant, sans générer de trafic vers le réseau cible. Si le mot de passe du compte est faible ou présent dans un dictionnaire, il est récupéré en clair. L’attaquant peut alors utiliser ce compte pour progresser dans le domaine, potentiellement vers une élévation de privilèges.
⚠️ Le caractère offensif du Kerberoasting réside dans son indétectabilité presque totale lors de la phase de collecte des tickets. Une demande TGS est une opération parfaitement légitime dans Kerberos. Si un attaquant en fait une douzaine en une minute, cela peut ressembler à un simple accès à des services internes.
Exposition
Pourquoi certains environnements sont plus exposés que d’autres
Comptes machines, comptes utilisateurs, RC4 vs AES : les facteurs déterminants
Tous les comptes avec un SPN ne sont pas également vulnérables. La facilité de craquage du ticket dépend de deux facteurs : le type de compte associé au service, et l’algorithme de chiffrement utilisé pour générer le ticket.
Comptes machines vs comptes utilisateurs
Dans Active Directory, les comptes machines (objets de type "computer") ont leurs mots de passe gérés automatiquement par le contrôleur de domaine. Ces mots de passe font 120 caractères générés aléatoirement et sont renouvelés automatiquement toutes les 30 jours. En pratique, aucun outil de cracking ne peut venir à bout d’un tel mot de passe dans un temps utile. Les services associés à des comptes machines sont donc théoriquement vulnérables au Kerberoasting, mais l’exploitation n’est pas réalisable.
Les comptes utilisateurs (objets de type "user") avec un SPN sont dans une situation radicalement différente. Leurs mots de passe ne sont pas gérés automatiquement. En pratique, beaucoup de comptes de service créés pour des applications métier ont des mots de passe simples, parfois inchangés depuis des années, voire depuis la création du compte. Ces comptes sont les cibles prioritaires du Kerberoasting.
🔴 Compte utilisateur + SPN + RC4
La cible idéale pour un Kerberoasting. Ticket chiffré en RC4, crackable en quelques minutes sur un GPU moderne avec un dictionnaire. Situation la plus fréquente dans les domaines non durcis.
🟡 Compte utilisateur + SPN + AES
Plus difficile à craquer mais pas impossible. L’algorithme AES-256 rend l’attaque par dictionnaire beaucoup plus lente. Un mot de passe faible reste crackable, mais la fenêtre d’exploitation se réduit.
🟢 Compte machine + SPN
Théoriquement vulnérable, pratiquement inexploitable. Mot de passe de 120 caractères aléatoires, renouvelé tous les 30 jours. Aucun outil de cracking ne peut en venir à bout dans un délai utile.
Le rôle déterminant de l’algorithme de chiffrement : RC4 vs AES
L’algorithme utilisé pour chiffrer le ticket de service est l’autre facteur clé. Par défaut, si l’attribut msDS-SupportedEncryptionTypes du compte n’est pas explicitement configuré pour exiger AES, le KDC utilisera RC4 pour générer le ticket. RC4 est un algorithme considéré comme faible : sur un GPU grand public de 2024, un ticket RC4 peut être soumis à des centaines de millions de tentatives par seconde avec un outil comme Hashcat.
C’est la combinaison "compte utilisateur + SPN + algorithme RC4 + mot de passe faible ou présent dans un dictionnaire" qui rend le Kerberoasting concrètement dangereux dans les environnements réels. Et cette combinaison, nos pentesters la rencontrent régulièrement lors des missions d’audit Active Directory.
Variante
Kerberoasting ciblé et AS-REP Roasting : les variantes à connaître
Deux vecteurs connexes que le Kerberoasting classique ne couvre pas
Le Kerberoasting "classique" tel que décrit ci-dessus cible tous les comptes avec SPN simultanément. Il existe une variante plus discrète : le Kerberoasting ciblé, qui consiste à ne demander qu’un seul ticket de service pour un compte spécifique préalablement identifié comme prioritaire (compte de service d’administration, compte avec des droits élevés sur des ressources critiques). Cette approche ciblée génère beaucoup moins de bruit réseau et échappe plus facilement aux règles de détection basées sur le volume de requêtes TGS.
🔗 L’AS-REP Roasting est une technique différente mais souvent mentionnée dans le même contexte. Elle cible les comptes pour lesquels la pré-authentification Kerberos est désactivée (attribut DONT_REQ_PREAUTH). Pour ces comptes, n’importe qui peut demander un TGT chiffré avec le mot de passe du compte, sans même être authentifié sur le domaine. Le craquage hors ligne s’effectue de la même façon qu’en Kerberoasting.
Détection
Comment détecter une tentative de Kerberoasting ?
Ce que voit la Blue Team et les signaux à surveiller
La détection du Kerberoasting est difficile parce que les requêtes TGS sont des opérations légitimes dans Kerberos. Un utilisateur qui accède à plusieurs services dans la journée génère naturellement plusieurs requêtes TGS. C’est la corrélation des événements, et non l’événement individuel, qui suggère une activité malveillante.
La surveillance Active Directory en continu constitue la première ligne de détection. Les signaux à corréler sont les suivants.
📋 ID d’événement 4769
L’événement Windows 4769 (Demande de ticket de service Kerberos) est journalisé sur le contrôleur de domaine. Un volume anormalement élevé de ces événements depuis un seul compte utilisateur, en particulier avec un type de chiffrement RC4 (valeur 0x17), est un signal fort.
🔍 Requêtes RC4 anormales
Si l’environnement est en cours de migration vers AES exclusif, toute requête TGS avec chiffrement RC4 est immédiatement suspecte. Filtrer les événements 4769 avec TicketEncryptionType = 0x17 sur des comptes qui ne devraient pas générer ce type de requêtes.
🕵️ Corrélation comportementale
Un compte utilisateur standard qui génère des demandes TGS pour des dizaines de comptes de service distincts en moins d’une minute est un indicateur comportemental fort. Les solutions SIEM et les honeytokens AD (comptes-appâts avec SPN) sont particulièrement efficaces pour cette détection.
🍯 Placer des honeytokens dans Active Directory (comptes utilisateurs fictifs avec un SPN et des droits minimes, que personne ne devrait jamais interroger) est l’une des détections les plus fiables du Kerberoasting. Toute demande TGS vers un honeytoken est une alerte immédiate, presque sans faux positif.
Mesures
Comment protéger son Active Directory contre le Kerberoasting
Des mesures structurelles, pas seulement une politique de mots de passe
La protection contre le Kerberoasting s’articule autour de quatre axes complémentaires. Aucun d’eux seul ne suffit : c’est leur combinaison qui réduit significativement la surface d’attaque.
1. Migrer vers les comptes de service administrés (gMSA)
Les comptes de service administrés de groupe (gMSA, Group Managed Service Accounts) sont la réponse de Microsoft au problème des comptes de service utilisateurs. Un gMSA a son mot de passe géré automatiquement par Active Directory : 240 caractères aléatoires, renouvelés périodiquement, impossibles à extraire ou à réutiliser directement. Utiliser des gMSA pour tous les services applicatifs qui le permettent est la mesure la plus efficace pour éliminer structurellement le Kerberoasting sur ces comptes.
2. Forcer AES et désactiver RC4 sur les comptes à SPN
Pour les comptes de service qui ne peuvent pas être migrés vers gMSA, forcer l’utilisation de l’algorithme AES via l’attribut msDS-SupportedEncryptionTypes réduit considérablement la faisabilité du craquage. Les tickets AES-256 nécessitent des ressources de calcul plusieurs centaines de fois supérieures aux tickets RC4 pour un même dictionnaire de mots de passe. Un mot de passe fort deviens alors virtuellement impossible à craquer dans un délai utile.
3. Politique de mots de passe robuste sur les comptes de service
Pour les comptes qui ne peuvent être ni migrés en gMSA ni configurés pour AES exclusif, la complexité du mot de passe est le dernier rempart. Une politique stricte doit être appliquée sur ces comptes : longueur minimale de 25 caractères, caractères aléatoires, rotation régulière (au moins annuelle), absence de mots du dictionnaire ou de patterns prédictibles. Ces mots de passe n’ont pas besoin d’être mémorisés par un humain : ils doivent être stockés dans un gestionnaire de secrets (coffre-fort PAM).
4. Nettoyer les SPN inutiles et auditer régulièrement
Dans beaucoup d’environnements, des comptes possèdent un attribut SPN renseigné sans que le service correspondant ne soit encore actif. Ces SPN orphelins augmentent la surface d’attaque sans servir aucun usage métier. Un audit régulier des comptes avec SPN, comparé à la liste des services en production, permet d’éliminer ces expositions inutiles. L’outil BloodHound permet de cartographier ces comptes en quelques secondes et d’identifier ceux qui représentent un chemin vers des ressources critiques.
5. Utiliser le groupe Protected Users
Le groupe Protected Users d’Active Directory impose des restrictions supplémentaires aux comptes qui en sont membres : interdiction de l’authentification NTLM, utilisation obligatoire de Kerberos, chiffrement AES uniquement, durée de vie TGT réduite. Ajouter les comptes privilégiés à ce groupe n’élimine pas la vulnérabilité Kerberoasting pour les comptes de service (qui par définition doivent être accessibles), mais protège les comptes à très hauts privilèges contre les techniques connexes comme le LLMNR/NBT-NS Poisoning et certaines formes d’usurpation d’identité.
Missions
Comment le Kerberoasting s’intègre dans nos audits Active Directory
De la reconnaissance à l’élévation de privilèges : le cheminement réel en pentest
Dans le cadre d’un audit Active Directory mené par PIIRATES, le Kerberoasting intervient systématiquement dans la phase de post-exploitation initiale, après l’obtention d’un premier compte du domaine. La séquence typique est la suivante : cartographie des comptes vulnérables avec BloodHound, analyse des chemins offerts par ces comptes vers des ressources à haute valeur, tentative de craquage hors ligne, et si le mot de passe est récupéré, utilisation du compte pour progresser dans le domaine.
Ce qui distingue une mission PIIRATES d’un simple scan automatique, c’est la phase d’analyse humaine qui suit la cartographie. Trouver un compte avec SPN est une information brute. Comprendre que ce compte de service est membre du groupe "Domain Admins" ou dispose d’un contrôle complet sur une unité organisationnelle critique, c’est là que l’expertise du pentester ajoute de la valeur. C’est cette lecture contextuelle de l’environnement, impossible à automatiser, qui transforme un finding technique en démonstration d’impact métier réel.
Le Kerberoasting est par ailleurs rarement exploité seul. En mission, il est souvent combiné avec d’autres techniques : capture d’authentifications LLMNR/NBT-NS pour obtenir le premier compte du domaine, puis Kerberoasting pour chercher un compte de service avec plus de privilèges, puis techniques d’élévation de privilèges pour atteindre les droits Domain Admin. Ces chaînes d’attaque multi-vecteurs sont celles que nos rapports d’audit documentent et que les organisations doivent comprendre pour prioriser leurs corrections.
Testez votre exposition
Votre domaine Active Directory contient-il des comptes vulnérables au Kerberoasting ?
Un audit Active Directory PIIRATES cartographie les comptes vulnérables, les chemins d’exploitation et vous livre un plan de remédiation priorisé selon l’impact métier réel.
Demander un audit Active Directory PIIRATESLe Kerberoasting est une attaque post-exploitation ciblant les environnements Active Directory. Elle exploite le fait que n’importe quel utilisateur authentifié sur le domaine peut demander un ticket de service (ST) chiffré avec le mot de passe d’un compte associé à un service (via son attribut SPN). L’attaquant récupère ce ticket et tente de retrouver le mot de passe hors ligne par attaque par dictionnaire ou force brute. Aucun privilège élevé n’est requis pour lancer l’attaque.
Un SPN (Service Principal Name) est un attribut Active Directory qui identifie un service associé à un compte. La présence d’un SPN sur un compte signifie que n’importe quel utilisateur authentifié peut demander un ticket de service pour ce compte au KDC. C’est cette propriété que le Kerberoasting exploite : les tickets de service demandés sont chiffrés avec le mot de passe du compte, et peuvent être soumis à un craquage hors ligne.
Le Kerberoasting cible les comptes avec SPN renseigné et nécessite d’être authentifié sur le domaine. L’AS-REP Roasting cible les comptes pour lesquels la pré-authentification Kerberos est désactivée (attribut DONT_REQ_PREAUTH), et ne nécessite pas d’être préalablement authentifié. Dans les deux cas, un ticket chiffré avec le mot de passe du compte est récupéré et soumis à un craquage hors ligne. Les deux techniques sont complémentaires lors d’un pentest AD.
Par défaut, le KDC utilise RC4 pour chiffrer les tickets de service si l’attribut msDS-SupportedEncryptionTypes du compte n’est pas configuré pour AES. RC4 est un algorithme considéré comme faible : sur un GPU modern, un ticket RC4 peut être soumis à des centaines de millions de tentatives de craquage par seconde. Un mot de passe de service présent dans un dictionnaire courant peut être retrouvé en quelques minutes.
Un gMSA (Group Managed Service Account) est un type de compte Active Directory dont le mot de passe est géré automatiquement par le contrôleur de domaine : 240 caractères aléatoires, renouvelés périodiquement, impossible à extraire ou à réutiliser directement. Un gMSA peut avoir un SPN et donc être associé à un service, mais son mot de passe est structurellement impossible à craquer. C’est la mesure la plus efficace pour éliminer l’exposition Kerberoasting sur les comptes de service.
Oui, mais la détection est difficile parce qu’une demande TGS est une opération légitime dans Kerberos. Les indicateurs les plus fiables sont : un volume anormal de demandes TGS avec chiffrement RC4 (ID d’événement 4769 avec TicketEncryptionType = 0x17) depuis un même compte en peu de temps, et l’interaction avec des honeytokens (comptes-appâts avec SPN). Une surveillance Active Directory avec corrélation comportementale est nécessaire.
Le Kerberoasting cible les comptes AD avec SPN : 0 privilège requis, craquage RC4 en quelques minutes. Principe, détection Blue Team, gMSA, Protected Users Group et impact en pentest.
