cyber / pentest-red-team
Kerberoasting et attaques du protocole Kerberos
Explication
Ce que vous allez apprendre
- Décrire précisément le flux d'authentification Kerberos dans Active Directory
- Expliquer pourquoi n'importe quel utilisateur authentifié peut demander un ticket de service (TGS)
- Réaliser le lien entre un mot de passe de compte de service faible et le risque de Kerberoasting
- Comprendre le rôle des gMSA comme mitigation structurelle de ce risque
- Situer Kerberoasting parmi les attaques Kerberos les plus critiques (Golden Ticket, DCSync)
Dans quel contexte ?
Lors d'un audit Active Directory sur un domaine de lab, un auditeur dispose déjà d'un compte utilisateur de domaine ordinaire, sans aucun privilège particulier. Il souhaite savoir si un compte de service disposant potentiellement de droits élevés — par exemple un compte utilisé par une application métier critique — protège correctement son mot de passe. Le Kerberoasting permet de répondre à cette question sans jamais avoir besoin d'un accès privilégié préalable, ce qui explique pourquoi cette attaque reste, des années après sa découverte initiale, l'une des plus fréquemment rencontrées en audit réel.
D'abord, comprendre le flux Kerberos normal
Kerberos fonctionne en plusieurs échanges successifs : le client demande un ticket d'authentification initial (TGT) au contrôleur de domaine (KDC), puis présente ce TGT pour obtenir un ticket de service (TGS) spécifique à une ressource. Le point clé, souvent mal compris, est que ce TGS est chiffré avec le hash du mot de passe du compte de service ciblé — pas celui de l'utilisateur qui en fait la demande.
Prérequis
Cette leçon suppose une lecture attentive de la leçon précédente sur la reconnaissance Active Directory, car elle en approfondit directement un mécanisme.
| Étape du flux Kerberos | Ce qui est échangé |
|---|---|
| AS-REQ / AS-REP | Le client obtient un TGT chiffré avec la clé dérivée de son propre mot de passe |
| TGS-REQ / TGS-REP | Le client obtient un TGS chiffré avec le hash du compte de service ciblé |
| AP-REQ | Le client présente le TGS directement au service pour y accéder |
Une fois ce mécanisme compris, l'attaque devient limpide
Puisque n'importe quel compte de domaine authentifié peut demander un TGS pour n'importe quel SPN (nom de principal de service), un attaquant récupère ce ticket et tente de le "casser" hors ligne avec un outil comme hashcat. Si le mot de passe du compte de service est faible ou ancien, il finit par céder — sans jamais générer d'alerte côté KDC, car la demande de TGS elle-même est une opération parfaitement légitime et routinière.
Piège courant
Croire que Kerberoasting nécessite des privilèges administratifs est une confusion fréquente chez les débutants. C'est précisément l'inverse qui rend cette attaque si dangereuse : elle ne nécessite qu'un compte de domaine ordinaire, ce qui la rend accessible dès la toute première étape d'un accès initial réussi.
Il reste une mitigation structurelle particulièrement efficace
Les gMSA (group Managed Service Accounts) génèrent et renouvellent automatiquement un mot de passe de plus de 120 caractères, jamais connu d'un humain et donc pratiquement incraquable hors ligne. Ils suppriment le facteur humain — le choix ou la réutilisation d'un mot de passe faible — qui rend le Kerberoasting possible en premier lieu.
Bonne pratique
Recommande systématiquement la migration vers des gMSA pour tout compte de service disposant d'un SPN dans un rapport d'audit AD. C'est une mitigation qui élimine le risque à la racine, plutôt qu'une simple politique de complexité de mot de passe toujours contournable par un choix humain malheureux.
Au-delà de Kerberoasting, des attaques encore plus critiques comme Golden Ticket ou DCSync visent une compromission totale et persistante du domaine — un niveau de gravité qui aide à comprendre pourquoi la prochaine leçon distingue précisément un simple pentest d'un exercice de red teaming, bien plus ambitieux dans ses objectifs.
Commandes & code
Kerberoasting et attaques du protocole Kerberos
Kerberos est le protocole d'authentification standard d'Active Directory ; sa conception introduit des surfaces d'attaque spécifiques bien documentées défensivement.
# Rappel simplifié du flux Kerberos dans AD
1. Client -> KDC (AS-REQ) : demande un Ticket Granting Ticket (TGT) avec ses identifiants
2. KDC -> Client (AS-REP) : renvoie le TGT chiffré avec la clé dérivée du mot de passe du compte
3. Client -> KDC (TGS-REQ) : présente le TGT, demande un ticket de service (TGS) pour une ressource
4. KDC -> Client (TGS-REP) : renvoie un TGS chiffré avec le hash du COMPTE DE SERVICE ciblé
5. Client -> Service (AP-REQ) : présente le TGS au service pour accéder à la ressource# Kerberoasting : demander un TGS pour un compte de service (SPN), puis le craquer hors ligne
# Le TGS est chiffré avec le hash NTLM du mot de passe du compte de service : s'il est faible, il tombe
GetUserSPNs.py lab.local/utilisateur:motdepasse -request -outputfile tickets_a_analyser.txt
hashcat -m 13100 tickets_a_analyser.txt rockyou.txt
# Aucun privilège élevé requis : n'importe quel compte de domaine authentifié peut demander un TGS# Pourquoi cette attaque fonctionne (mécanisme, pas juste la commande)
- N'importe quel utilisateur authentifié du domaine peut demander un TGS pour n'importe quel SPN
- Le TGS est chiffré avec le hash du mot de passe du COMPTE DE SERVICE, pas celui du demandeur
- Si ce mot de passe est faible/ancien, il devient crackable hors ligne, sans alerter le KDC# Mitigation défensive : mots de passe de comptes de service longs, aléatoires, et gMSA
# Les gMSA (group Managed Service Accounts) génèrent et renouvellent automatiquement un mot de passe
# de 120+ caractères, gérable sans jamais être connu d'un humain
New-ADServiceAccount -Name "svc-app-gmsa" -DNSHostName "app01.lab.local" -PrincipalsAllowedToRetrieveManagedPassword "APP01$"# Autres attaques Kerberos à connaître (niveau expert, à but de compréhension défensive)
Golden Ticket : falsification d'un TGT avec le hash krbtgt compromis -> accès total et persistant au domaine
Silver Ticket : falsification d'un TGS pour un service précis, sans passer par le KDC
Pass-the-Ticket: réutilisation d'un ticket Kerberos volé sur une autre session/machine
DCSync : abus des permissions de réplication AD pour extraire tous les hashes du domaineRésumé
- Kerberoasting exploite le fait que tout utilisateur authentifié peut demander un TGS pour un SPN.
- La force réelle de la protection dépend uniquement de la robustesse du mot de passe du compte de service.
- Les gMSA éliminent structurellement ce risque en supprimant le facteur humain du mot de passe.
- Golden/Silver Ticket et DCSync représentent l'escalade ultime : compromission totale et persistante du domaine.
Exercices pratiques
Mission : Kerberoaster le compte de service applicatif NordShield
Objectif : Démontrer un Kerberoasting sur un compte de service à risque et recommander une mitigation structurelle plutôt que ponctuelle.
Contexte
Un compte de domaine standard NordShield te permet de tester si le compte de service svc-app, utilisé par une application métier critique, protège correctement son mot de passe.