Kerberoasting : ce que c'est, comment ça marche, comment s'en protéger.

Le kerberoasting n'exploite aucune faille logicielle, aucun correctif à installer, aucun CVE. Il détourne un comportement parfaitement normal du protocole Kerberos, celui qui gère les connexions dans la quasi-totalité des réseaux d'entreprise sous Active Directory. C'est ce qui le rend redoutable : on ne peut pas « patcher » Kerberos pour l'empêcher, on ne peut que retirer à l'attaquant ce dont il a besoin pour réussir.

Cette technique porte une référence officielle dans le référentiel MITRE ATT&CK : T1558.003. Ce guide explique le mécanisme sans jargon, comment savoir si votre annuaire y est exposé, et les étapes de remédiation dans l'ordre. Il ne montre pas comment mener l'attaque : aucune commande d'extraction de ticket n'est donnée ici.

1. Qu'est-ce que le kerberoasting, en une image

Imaginez un bal masqué où l'entrée est gratuite pour tout invité déjà muni d'une simple carte d'accès à la soirée. À l'entrée, un guichet remet à chaque invité un ticket scellé à la cire pour chaque salon auquel il souhaite accéder - un salon par service de l'établissement (la restauration, le vestiaire, le bar…). Le sceau de cire de chaque ticket est fabriqué à partir du mot de passe du salon lui-même : c'est ainsi que le salon reconnaîtra que le ticket est légitime quand l'invité se présentera.

Rien n'empêche un invité de demander des tickets pour tous les salons, un par un, sans jamais s'y présenter, puis de rentrer chez lui et d'essayer de casser les cachets de cire tranquillement, sans témoin. Certains sceaux, faits avec une cire ancienne et fine, cèdent en quelques instants. D'autres, épais et modernes, résistent indéfiniment.

2. Comment ça fonctionne, techniquement

Dans Active Directory, un compte de service (celui qui fait tourner une base de données, un site intranet, un serveur de fichiers…) peut porter un SPN (Service Principal Name) - une étiquette qui dit « ce compte représente tel service, sur telle machine ». N'importe quel utilisateur authentifié du domaine, même avec les droits les plus bas, peut demander au contrôleur de domaine un ticket de service (TGS) pour n'importe quel SPN existant - c'est une fonctionnalité normale et nécessaire du protocole : sans elle, personne ne pourrait se connecter aux services.

Ce ticket est chiffré avec une clé dérivée du mot de passe du compte de service lui-même. Et c'est là que le protocole devient une opportunité pour un attaquant : une fois le ticket obtenu, il peut être emporté et son chiffrement testé hors ligne, sans se reconnecter au réseau et donc sans déclencher de verrouillage de compte après plusieurs essais. Si le mot de passe du compte de service est court, courant, ou ancien, le chiffrement cède. Si en plus le domaine autorise encore le chiffrement RC4 (ancien, plus rapide à casser) plutôt que AES (moderne, beaucoup plus coûteux à casser), l'opération va encore plus vite.

Ce qui rend cette technique si utilisée : elle ne nécessite aucun privilège particulier (un compte utilisateur ordinaire suffit pour demander des tickets) et elle est furtive par nature - demander un ticket de service est une action anodine que des milliers d'utilisateurs légitimes font chaque jour.

3. Savoir si votre annuaire y est exposé

Deux vérifications à faire avec des outils d'administration standard - aucune n'attaque quoi que ce soit, elles interrogent simplement votre propre annuaire.

a. Lister les comptes de service porteurs d'un SPN et leur type de chiffrement autorisé, depuis un poste avec le module PowerShell Active Directory :

PowerShell (contrôleur de domaine ou poste RSAT)

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes |
  Select-Object Name, ServicePrincipalName, msDS-SupportedEncryptionTypes

La colonne msDS-SupportedEncryptionTypes indique le chiffrement autorisé pour ce compte. Une valeur de 4 ou 0 (ou vide) signale un compte qui accepte encore le RC4 - le cas le plus exposé. Une valeur de 24 ou plus indique un compte configuré pour n'accepter que l'AES.

b. Identifier les mots de passe anciens sur ces comptes, un mot de passe qui n'a jamais changé depuis des années étant statistiquement plus faible ou plus susceptible d'avoir fuité :

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties PasswordLastSet, ServicePrincipalName |
  Select-Object Name, PasswordLastSet, ServicePrincipalName |
  Sort-Object PasswordLastSet

Les comptes en haut de la liste, avec les dates les plus anciennes, sont vos premières priorités de remédiation.

4. Détecter une tentative en cours

Chaque demande de ticket de service génère un événement ID 4769 (« A Kerberos service ticket was requested ») sur le contrôleur de domaine. Deux signaux méritent une alerte :

• Un même compte qui demande des tickets pour un grand nombre de SPN différents en peu de temps - un utilisateur normal se connecte à quelques services dans sa journée, pas à des dizaines en quelques minutes.
• Un type de chiffrement RC4 (valeur 0x17, soit 23 en décimal) demandé dans un domaine configuré pour n'accepter que l'AES - dans cette situation, une demande en RC4 est en elle-même suspecte, puisque personne ne devrait plus en avoir besoin.

Ces deux règles se configurent facilement dans un SIEM ou directement via une tâche planifiée qui interroge le journal de sécurité du contrôleur de domaine (canal Security, ID d'événement 4769).

5. Étapes de remédiation, dans l'ordre

Étape 1 - Désactiver le RC4 et forcer l'AES au niveau du domaine

Dans une console de gestion des stratégies de groupe (GPMC), ouvrez ou créez une stratégie appliquée aux contrôleurs de domaine, puis :

Computer Configuration → Policies → Windows Settings →
Security Settings → Local Policies → Security Options →
"Network security: Configure encryption types allowed for Kerberos"

Cochez uniquement AES128_HMAC_SHA1 et AES256_HMAC_SHA1, et décochez RC4_HMAC_MD5 et DES. ⚠️ Testez d'abord sur un groupe restreint de machines : d'anciens équipements ou applications qui ne parlent que RC4 cesseraient de s'authentifier. Un audit préalable (étape 3a ci-dessus) permet de savoir qui serait affecté avant de couper.

Étape 2 - Forcer l'AES compte par compte, pour les comptes de service critiques

En complément de la stratégie de groupe, ou en attendant de pouvoir l'appliquer partout :

Set-ADUser -Identity "nom-du-compte-de-service" -KerberosEncryptionType AES128,AES256

Vérifiez ensuite que la valeur a bien été appliquée :

Get-ADUser -Identity "nom-du-compte-de-service" -Properties msDS-SupportedEncryptionTypes |
  Select-Object msDS-SupportedEncryptionTypes

Étape 3 - Migrer les comptes de service vers des gMSA

C'est la mesure la plus efficace : un gMSA (group Managed Service Account) génère automatiquement un mot de passe aléatoire de 240 caractères et le renouvelle tout seul tous les 30 jours. Un mot de passe de cette longueur, tiré aléatoirement, n'est pas cassable par force brute dans un délai réaliste - le cachet de cire devient, dans notre image, incassable.

a. Créer le compte gMSA (une seule fois par domaine, si ce n'est pas déjà fait, il faut d'abord initialiser la clé racine du domaine : Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10), à n'exécuter qu'une fois) :

New-ADServiceAccount -Name "svc-monapplication" `
  -DNSHostName "monapplication.domaine.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "SRV-APPLI01$"

b. Installer le compte sur le serveur qui héberge le service, depuis ce serveur :

Install-ADServiceAccount -Identity "svc-monapplication"

c. Configurer le service applicatif pour utiliser ce compte à la place de l'ancien compte de service - la marche à suivre dépend du service concerné (dans les propriétés du service Windows, onglet « Se connecter en tant que », le mot de passe n'est alors plus nécessaire, le compte gMSA le gère lui-même).

d. Retirer l'ancien SPN de l'ancien compte une fois la bascule confirmée, pour qu'il ne reste plus une cible utilisable :

setspn -D "SPN/valeur" nom-ancien-compte

Étape 4 - Pour les comptes qui ne peuvent pas migrer vers un gMSA

Certains logiciels anciens n'acceptent pas les gMSA. Dans ce cas : donnez-leur un mot de passe d'au moins 25 caractères, aléatoire (pas une phrase mémorisable), et changez-le au moins une fois par an - ou immédiatement si vous avez le moindre doute de fuite. Un gestionnaire de mots de passe d'entreprise ou un coffre-fort de secrets (Vault, CyberArk…) permet de le stocker sans qu'un humain ait besoin de le retenir.

Étape 5 - Vérifier que la remédiation tient dans le temps

Répétez la commande de l'étape 3a du diagnostic tous les trimestres : un nouveau compte de service créé sans gMSA, ou une application réinstallée qui régénère un ancien compte, ramène le risque en silence si personne ne revérifie.

Sources

• MITRE ATT&CK - T1558.003 Kerberoasting
• Microsoft Learn - Detect and remediate RC4 usage in Kerberos
• ANSSI - recommandations de sécurisation d'Active Directory
• Kenawek - MFA : pourquoi l'authentification multifacteur n'est plus optionnelle
• Kenawek - Vous n'avez pas d'inventaire, vous avez une intuition