Kerberoasting et AS-REP Roasting

Deux attaques, un même terrain de jeu : le KDC

Kerberoasting et AS-REP Roasting partagent une propriété qui les rend redoutablement efficaces en engagement offensif : elles ne nécessitent aucune interaction avec le service final, aucune élévation de privilège préalable, et surtout aucun risque de verrouillage de compte par tentative de mot de passe erronée. Tout se joue avec le contrôleur de domaine, qui répond à des requêtes Kerberos parfaitement légitimes du point de vue du protocole. Le matériau récupéré — un ticket de service ou une AS-REP — est ensuite cassé hors ligne, à la vitesse du matériel de l'attaquant, sans que le domaine ne voie passer la moindre tentative supplémentaire.

Si vous avez suivi le chapitre précédent sur les fondamentaux Kerberos, vous savez déjà que chaque ticket est chiffré avec la clé de celui qui doit le lire. Les deux techniques présentées ici exploitent chacune un point différent de cette mécanique : le Kerberoasting vise la clé du compte de service portant un SPN, l'AS-REP Roasting vise la clé du compte utilisateur lui-même, en profitant d'une étape de vérification que Kerberos rend optionnelle.

À l'issue de ce chapitre, vous devez savoir distinguer précisément les conditions de faisabilité des deux attaques, produire les commandes d'énumération et d'extraction correspondantes, et surtout être capable d'expliquer à un client pourquoi une découverte Kerberoastable sur un compte à faible privilège apparent reste une priorité de remédiation élevée.

Kerberoasting : exploiter la clé d'un compte de service

Mécanisme précis

Tout utilisateur authentifié du domaine peut demander un ticket de service (TGS) pour n'importe quel SPN enregistré, sans droit particulier sur le compte propriétaire. Le TGS obtenu contient une portion chiffrée avec le hash NT dérivé du mot de passe de ce compte de service. L'attaquant n'a besoin de rien d'autre qu'une session de domaine valide, même avec les droits les plus bas, pour demander ces tickets en masse et les emporter pour un craquage hors ligne.

La séquence typique en engagement :

1. Énumération des SPN — identifier tous les comptes porteurs d'un SPN, en priorité les comptes utilisateur (les comptes machine sont rarement intéressants, leur mot de passe étant généré aléatoirement et renouvelé automatiquement)
2. Demande de TGS pour chacun de ces SPN, avec la session courante
3. Extraction du ticket au format compatible hashcat/John
4. Craquage hors ligne, contre une wordlist ou en brute-force ciblé

# Énumération et extraction (Impacket)
GetUserSPNs.py corp.local/jdupont:'Password123!' -dc-ip 10.10.10.10 -request

# Depuis Windows, avec Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

# Craquage hors ligne
hashcat -m 13100 hashes.txt rockyou.txt

Sur un domaine de taille moyenne, il n'est pas rare de trouver vingt à cinquante comptes avec SPN, souvent des comptes de service SQL Server, IIS ou applicatifs métier créés des années auparavant. Le compte svc_reporting, jamais renouvelé depuis sa création et doté d'un mot de passe de douze caractères sans rotation, tombe en quelques minutes sur un GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire récent — alors que le compte machine WKSTN042$, avec son mot de passe aléatoire de 120 caractères généré par AD, ne tombera jamais.

Conditions de faisabilité

Un compte de service Kerberoastable n'a souvent, sur le papier, aucun privilège d'administration explicite. Mais il accumule fréquemment des droits locaux sur plusieurs serveurs (service Windows exécuté avec ce compte), des accès à des partages sensibles, ou une appartenance héritée à un groupe applicatif large. Le mot de passe cassé ouvre alors un mouvement latéral disproportionné par rapport à l'apparence du compte dans l'annuaire. Documentez toujours l'usage réel du compte, pas seulement ses groupes AD directs.

AS-REP Roasting : exploiter l'absence de pré-authentification

Mécanisme précis

La pré-authentification Kerberos impose au client de prouver, dès l'AS-REQ, qu'il connaît le mot de passe du compte — en chiffrant un horodatage avec le hash NT dérivé de ce mot de passe. Cette étape peut être désactivée sur un compte via l'attribut DONT_REQ_PREAUTH (visible dans les outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire sous le nom « Do not require Kerberos preauthentication »). Un compte ainsi configuré répond à une AS-REQ non authentifiée par une AS-REP dont une portion est chiffrée avec le hash NT du compte cible lui-même — sans qu'aucune preuve de connaissance du mot de passe n'ait été exigée.

Conséquence directe : un attaquant qui connaît simplement le nom d'un compte vulnérable (aucun mot de passe requis, aucune session de domaine nécessaire dans certains cas) peut obtenir ce matériau chiffré et le casser hors ligne, exactement comme pour un TGS Kerberoastable.

# Énumération et extraction sans authentification préalable (Impacket)
GetNPUsers.py corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.10.10

# Avec une session authentifiée existante
GetNPUsers.py corp.local/jdupont:'Password123!' -request

# Craquage hors ligne
hashcat -m 18200 asrep_hashes.txt rockyou.txt

L'attribut DONT_REQ_PREAUTH n'est pas une erreur de configuration exotique. Il a longtemps été activé volontairement pour la compatibilité avec certaines implémentations Kerberos tierces (systèmes Unix/Linux anciens, appliances réseau) incapables de gérer correctement la pré-authentification. Ces exceptions techniques, posées il y a des années pour un besoin ponctuel, survivent souvent bien après la disparition du système qui les justifiait.

Conditions de faisabilité

• L'attribut DONT_REQ_PREAUTH doit être positionné sur le compte visé — ce n'est jamais le cas par défaut sur un compte AD standard
• Connaître le nom du compte suffit ; une session de domaine n'est pas strictement nécessaire pour l'énumération non authentifiée, mais elle facilite grandement la reconnaissance des noms de comptes valides
• Comme pour le Kerberoasting, la solidité réelle du mot de passe détermine le temps de craquage effectif
• Aucun verrouillage de compte n'est déclenché par cette technique, car aucune tentative d'authentification échouée n'est produite au sens classique du terme

Avant de lancer un AS-REP Roasting ciblé, vérifiez systématiquement si un compte que vous soupçonnez déjà (compte de service, compte hérité d'une migration, compte technique documenté dans une politique de sécurité obsolète) porte cet attribut, via Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth. C'est souvent plus rapide que de tester en aveugle tous les comptes du domaine, et cela évite de générer un volume de requêtes non authentifiées qui peut, lui, être repéré par une supervision réseau.

Détection : ce que voit un défenseur

Les deux attaques laissent des traces dans les journaux du contrôleur de domaine, à condition que l'audit Kerberos soit correctement configuré (catégorie Audit Kerberos Service Ticket Operations et Audit Kerberos Authentication Service).

Un basculement du type de chiffrement d'un ticket vers RC4 (0x17) sur un environnement où le domaine est configuré pour privilégier AES est un indicateur solide d'outil de Kerberoasting (beaucoup d'outils historiques forcent RC4 pour accélérer le craquage), mais certains environnements legacy négocient encore RC4 nativement pour des raisons de compatibilité. Corrélez toujours ce signal avec le volume de requêtes et la diversité des SPN visés avant de qualifier un incident.

Priorisation de la remédiation

Toutes les découvertes Kerberoastables ou AS-REP Roastables ne se valent pas. Une grille de priorisation simple, à documenter dans le rapport :

1. Critique — compte avec SPN ou DONT_REQ_PREAUTH, membre direct ou indirect d'un groupe à privilèges (Domain Admins, Enterprise Admins, administrateurs locaux sur des serveurs sensibles), et mot de passe cassé pendant le test
2. Élevée — compte avec SPN ou DONT_REQ_PREAUTH sans appartenance privilégiée directe, mais avec un accès étendu à des ressources métier (partages, bases de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire) ou mot de passe cassé en moins de 24 heures avec une wordlist standard
3. Moyenne — compte identifié comme vulnérable en théorie, mais mot de passe non cassé pendant la fenêtre de test avec les moyens disponibles (ce qui ne garantit pas sa robustesse à long terme, seulement sa résistance aux moyens engagés)
4. Faible / à surveiller — comptes techniques isolés, sans accès sensible documenté, mais dont l'exposition doit néanmoins être corrigée par hygiène générale

Un compte dont vous n'avez pas réussi à casser le mot de passe pendant l'engagement n'est pas un compte sûr : c'est un compte que vous n'avez pas eu le temps ou les ressources de casser. La recommandation de remédiation (SPN sur gMSA, réactivation de la pré-authentification, migration vers AES) doit être formulée indépendamment du résultat du craquage, sur la seule base de la configuration exposée.

Côté remédiation technique, les leviers structurels priment sur le simple changement de mot de passe :

• Migrer les comptes de service vers des gMSA quand l'application le permet — mot de passe de 240 caractères, rotation automatique, non exploitable par Kerberoasting en pratique
• Désactiver DONT_REQ_PREAUTH sauf contrainte de compatibilité documentée et justifiée, réévaluée périodiquement
• Forcer AES256 pour les comptes qui doivent rester sur SPN classique, via l'attribut msDS-SupportedEncryptionTypes
• Politique de mots de passe renforcée et rotation effective pour tout compte de service qui ne peut pas migrer vers un gMSA à court terme
• Activer l'audit Kerberos (4768/4769) si ce n'est pas déjà fait, condition préalable à toute détection

Documenter la preuve pour le client

Un constat Kerberoasting ou AS-REP Roasting doit être présenté avec une preuve reproductible et non ambiguë, sans exposer le mot de passe en clair dans le corps du rapport :

• Nom du compte concerné et SPN ou attribut en cause, avec capture de la commande d'énumération (LDAP anonyme ou authentifié selon le cas)
• Horodatage de l'extraction et, si le mot de passe a été cassé, mention du temps de craquage et de la méthode (wordlist, masque, règle) sans révéler le mot de passe lui-même dans le corps principal — le communiquer séparément et de façon sécurisée au point de contact technique
• Impact concret retracé jusqu'à un objectif métier si possible (mouvement latéral réalisé, accès obtenu grâce à ce compte), pas seulement une classification CVSS générique
• Recommandation priorisée selon la grille ci-dessus, avec une distinction claire entre correction immédiate (rotation du mot de passe) et correction structurelle (migration gMSA, désactivation de l'exception preauth)

Mentionner « le mot de passe du compte svc_backup, membre du groupe Backup Operators sur douze serveurs, a été cassé en 4 minutes avec une wordlist publique » convainc davantage un comité de décision qu'un simple libellé de sévérité. Documentez systématiquement le temps de craquage observé quand vous en avez la mesure.

Pièges fréquents en engagement

• Confondre un compte avec SPN et un compte forcément privilégié : la criticité dépend de l'usage réel du compte, pas de sa seule présence dans la liste des SPN
• Lancer un Kerberoasting massif sans session de domaine valide alors que la cible ne permet pas l'énumération LDAP anonyme — vérifiez d'abord le niveau d'accès requis dans votre contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire
• Oublier de tester l'AS-REP Roasting en parallèle du Kerberoasting : ce sont deux surfaces distinctes, et un domaine peut être vulnérable à l'une sans l'être à l'autre
• Attribuer à tort un chiffrement RC4 observé à une attaque, alors qu'il peut résulter d'une configuration legacy du domaine sans lien avec un outil offensif
• Considérer la remédiation comme terminée après un simple changement de mot de passe, sans traiter la cause structurelle (SPN qui reste exploitable dès le prochain mot de passe faible choisi par un administrateur)

Ce qu'il faut retenir

1. Le Kerberoasting cible la clé d'un compte de service via un TGS ; l'AS-REP Roasting cible la clé d'un compte utilisateur via une AS-REP obtenue sans pré-authentification
2. Les deux attaques se cassent hors ligne, sans verrouillage de compte ni trace de tentative d'authentification échouée classique
3. La détection repose sur l'audit Kerberos (Event ID 4769 et 4768) et sur la corrélation entre type de chiffrement, volume et diversité des cibles
4. La remédiation prioritaire est structurelle (gMSA, AES, suppression de l'exception preauth), pas seulement un changement ponctuel de mot de passe
5. La criticité d'une découverte se juge sur l'usage réel du compte, jamais sur le seul résultat binaire du craquage pendant la fenêtre de test

Un compte de service ou un compte utilisateur compromis par ces techniques devient souvent le point de départ d'un mouvement latéral ou d'une élévation de privilège traités dans les chapitres suivants. Gardez une trace précise de chaque secret obtenu ici : il sera régulièrement réutilisé comme prérequis dans les scénarios d'attaque à venir.