Dans un environnement Active Directory, Kerberos est souvent perçu comme robuste et sécurisé. Pourtant, certaines configurations insuffisantes peuvent exposer des failles importantes.
L’attaque AS-REP Roasting en est un excellent exemple : elle permet à un attaquant d’obtenir des hashes Kerberos sans posséder de compte valide, en exploitant une mauvaise configuration liée à la pré-authentification. Pour cela il faut comprendre ce qu'est Kerberos (expliqué ici)

Cet article décrit en détail :

• comment fonctionne Kerberos,

• le rôle de la pré-authentification,

• comment l’AS-REP Roasting exploite ce mécanisme,

• pourquoi cette attaque est dangereuse,

• comment s’en protéger efficacement.

Le rôle critique de la pré-authentification Kerberos

Lorsqu’un utilisateur veut s’authentifier, il envoie une requête AS-REQ au KDC.
Pour éviter les attaques par usurpation, Kerberos exige en principe une pré-authentification, c’est-à-dire : l’utilisateur doit prouver qu’il connaît son mot de passe avant que le KDC lui renvoie un ticket. Cette preuve est habituellement un timestamp chiffré avec sa clé dérivée du mot de passe.

Sans pré-authentification :

• n’importe qui peut demander un ticket pour n’importe quel utilisateur

• le KDC renvoie un paquet chiffré

• ce paquet devient un hash crackable

C’est exactement ce que l’AS-REP Roasting exploite.

Où se situe la vulnérabilité ?

Dans Active Directory, certains comptes peuvent avoir l’attribut suivant activé :

“Do not require Kerberos preauthentication”
en LDAP : DONT_REQ_PREAUTH

Lorsque cette option est activée :

L’utilisateur n’a plus besoin de prouver son identité pour demander un ticket.
Le KDC renvoie directement un AS-REP chiffré.

Cet AS-REP contient un champ chiffré avec la clé de l’utilisateur.
Donc :

Le hash du mot de passe est exposé.
Il peut être cracké hors-ligne.

AS-REP Roasting : fonctionnement détaillé

Voici le flux complet de l’attaque :

1. Identification des comptes vulnérables

L’attaquant identifie les comptes ayant DONT_REQ_PREAUTH = true.

Cela peut se faire soit via LDAP anonyme (si mal configuré), par un compte utilisateur basique ou des outils GetNPUsers.py (Impacket)/Rubeus asreproast

2. Requête AS-REQ falsifiée

L’attaquant envoie une requête AS-REQ au KDC au nom de l’utilisateur vulnérable — sans authentification.

3. Le KDC renvoie l’AS-REP

Comme la pré-auth est désactivée, le KDC renvoie directement l’AS-REP contenant les données chiffrées ainsi que la clé dérivée du mot de passe utilisateur.

4. Cracking hors-ligne

L’attaquant peut alors tenter de casser le hash avec Hashcat / John, par brute-force ou dictionnaire.

Pourquoi cette attaque est dangereuse ?

Contrairement au Kerberoasting, cette attaque n'a pas besoin de compte AD directement. Elle est même possible depuis l’extérieur si le KDC est exposé. Elle est aussi très silencieuse, au niveau des logs elle ressemble à un comportement nominal.

Il suffit d'un seul compte et il est possible de récupérer un hash exploitable, en extraire un mot de passe (s'il est faible) et parfois même de compromettre par la suite un compte à hauts privilèges.

Les comptes à risque sont principalement ceux créés manuellement par des admins pressés, des comptes de service mal configurés. certains sont laissés inactifs, d'autres hérités par erreur après une migration AD... Il est possible de trouver parfois des environnements avec 2, 10, parfois plus de 50+ comptes vulnérables.

Comment savoir si son domaine est vulnérable et comment s’en protéger efficacement ?

Voici une stratégie de défense réellement praticable : Ne JAMAIS désactiver la pré-authentification. Il s'agit de la règle n°1.
Il n’y a aucune raison légitime d’utiliser l’option : “Do not require Kerberos preauthentication”. A corriger donc en priorité.

Il y a une liste de questions simples à se poser :

• Possède t-on des comptes avec DONT_REQ_PREAUTH ?

• Des comptes utilisateurs sans MFA ?

• Des KDC exposés ?

• Des mots de passe faibles ?

• Pas de monitoring Kerberos ?

Si un seul des points est “oui”, alors l’AS-REP Roasting est possible. Il faut Auditer régulièrement les comptes vulnérables, pour cela une commande powershell simple :

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}

D'autre moyens restent très simples pour rendre cette attaque inexploitable comme utiliser des mots de passe solides ou encore tout simplement créer une DMZ pour ne pas exposer son KDC depuis l'extérieur.

AS-REP Roasting exploite une configuration rarement contrôlée : la pré-authentification Kerberos.
Contrairement à Kerberoasting, il n’exige même pas un compte valide, ce qui en fait une attaque très accessible pour un attaquant interne ou externe.

Les conséquences peuvent être lourdes :

• compromission de comptes utilisateurs

• escalade de privilèges

• pivot vers des systèmes critiques

• propagation d’une compromission AD

La bonne nouvelle est qu’il est simplement évitable, en appliquant quelques bonnes pratiques :

• réactiver la pré-auth sur tous les comptes

• imposer des mots de passe robustes

• surveiller les requêtes AS-REQ

• auditer régulièrement l’AD

• ne jamais exposer un DC

AS-REP Roasting souligne une vérité :
Les vulnérabilités AD sont souvent des erreurs de configuration, pas des failles techniques.