AS-REP Roasting — Détection & Remédiation

Qu'est-ce que l'AS-REP Roasting ?

L'AS-REP Roasting est une attaque Active Directory qui vise les comptes pour lesquels la pré-authentification Kerberos est désactivée.

Quand le flag DONT_REQ_PREAUTH est activé sur un utilisateur ou un compte de service, le KDC peut renvoyer une AS-REP sans demander au client de prouver qu'il connaît le mot de passe. Un attaquant qui connaît ou devine un nom de compte valide peut alors demander cette réponse, en extraire la partie chiffrée et tenter un crack hors ligne.

C'est précisément ce qui rend le réglage dangereux : il transforme un compte de domaine en cible de cassage de mot de passe avant qu'une authentification réussie n'ait eu lieu.

La différence avec le Kerberoasting est importante :

le Kerberoasting nécessite une identité de domaine valide pour demander des tickets de service
l'AS-REP Roasting ne nécessite pas d'identifiants valides pour demander une AS-REP sur un compte connu

En revanche, cela ne veut pas dire que l'énumération LDAP anonyme est disponible par défaut. Microsoft a désactivé les opérations LDAP anonymes sur les contrôleurs de domaine Active Directory par défaut à partir de Windows Server 2003, à l'exception d'opérations limitées comme rootDSE et le bind. La découverte de noms de comptes est un sujet distinct de la collecte AS-REP.

Comment l'échange Kerberos est modifié

Dans un échange Kerberos normal, le client envoie une AS-REQ avec des données de pré-authentification, le plus souvent un timestamp chiffré. C'est cette étape qui prouve au KDC que le client connaît le secret du compte.

Si DONT_REQ_PREAUTH est activé, le KDC saute ce contrôle et renvoie immédiatement une AS-REP. La partie chiffrée de cette réponse est protégée avec la clé Kerberos de long terme du compte, elle-même dérivée du mot de passe.

Pour un lecteur technique, deux points comptent :

l'attaque fonctionne parce que la réponse chiffrée est fournie avant authentification réussie
cette réponse est exploitable pour du crack hors ligne, donc la longueur et la qualité du mot de passe changent directement l'impact

Il ne faut pas supposer que tous les comptes roastables renverront le même type de chiffrement. Dans des environnements Windows modernes, des types AES sont attendus dans de nombreux cas ; dans des environnements plus anciens, on peut encore rencontrer du RC4. Le bon modèle mental n'est donc pas « RC4 par défaut », mais « le matériau renvoyé dépend de la configuration Kerberos et des types de chiffrement utilisables dans cet environnement ».

Ce qu'il faut réellement à l'attaquant

Une tentative d'AS-REP Roasting réussie ne demande que trois choses :

Un chemin réseau vers un contrôleur de domaine capable de répondre aux requêtes Kerberos.
Des noms de comptes candidats.
Au moins un compte avec DONT_REQ_PREAUTH activé.

C'est ce qui rend la technique attractive. L'attaquant n'a pas besoin de compromettre d'abord une session Windows ou de voler un premier compte avant de lancer la collecte.

En pratique, les noms de comptes proviennent souvent de :

conventions d'adressage mail ou annuaires publics
accès basique déjà obtenu dans le domaine
exports, scripts ou fichiers historiques
énumération AD authentifiée par un simple compte à faibles privilèges

LDAP anonyme est donc une erreur supplémentaire, pas une condition nécessaire de l'attaque.

La chaîne d'attaque

Étape 1 - Identifier les comptes roastables

Avec un accès authentifié, un simple inventaire AD suffit :

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Sans identifiants, l'attaquant peut quand même tester des noms de comptes connus en envoyant des requêtes AS et en observant quels comptes renvoient du matériau exploitable.

Étape 2 - Demander les réponses AS-REP

# Requête AS-REP pour une liste de noms connus
impacket-GetNPUsers corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.0.1

Avec un compte de domaine valide, l'énumération peut être plus directe :

impacket-GetNPUsers corp.local/user:password -request -dc-ip 10.10.0.1

Sur un poste Windows, Rubeus produit le même résultat :

.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

Étape 3 - Cracker hors ligne

À ce stade, le contrôleur de domaine n'est plus dans la boucle. Les essais de mots de passe se font hors ligne, à la vitesse de l'attaquant.

C'est pour cette raison que les vieux mots de passe de comptes de service, les secrets générés humainement et les mots de passe non expirants sont particulièrement risqués dans ce scénario.

Étape 4 - Exploiter l'identifiant récupéré

Si le mot de passe est retrouvé, le compte compromis peut être utilisé comme n'importe quelle autre identité compromise :

accès interactif si autorisé
LDAP et PowerShell pour étendre la visibilité
mouvement latéral vers les systèmes où le compte a des droits locaux ou délégués
escalade si le compte est lié à des groupes privilégiés, des tâches planifiées, des services ou des applications critiques

Une exception laissée pour une application legacy peut donc devenir la première étape d'un chemin d'identité beaucoup plus large.

Détection

Le meilleur point de détection reste le contrôleur de domaine.

L'Event ID 4768 est le signal central

La documentation Microsoft sur l'Event ID 4768 rend deux champs particulièrement utiles :

Pre-Authentication Type = 0 indique qu'une requête TGT a été faite sans pré-authentification Kerberos
Ticket Encryption Type montre quel type de chiffrement Kerberos a réellement été utilisé

Pour l'AS-REP Roasting, la priorité est donc claire : surveiller les 4768 avec Pre-Authentication Type 0.

Chasses concrètes à mettre en place

Commencez par ces cas :

répétition d'événements 4768 avec Pre-Authentication Type = 0
rafales de requêtes depuis une même IP vers plusieurs comptes
requêtes visant des comptes de service ou des comptes admin qui ne devraient jamais servir à de l'authentification interactive
pics de 4768 Result Code 0x6, qui peuvent révéler une phase de devinette de noms de comptes avant les requêtes valides
changements de comptes qui activent DONT_REQ_PREAUTH, surtout pour des identités de service ou des comptes à privilèges

Exemple de requête SIEM

event.code: "4768" AND
winlog.event_data.PreAuthType: "0" AND
winlog.event_data.Status: "0x0"

Si l'audit des changements d'annuaire est activé, surveillez aussi les modifications qui changent le bit userAccountControl concerné. C'est souvent là qu'on peut attraper l'exception dangereuse avant l'exploitation.

Remediation et correction

La remediation ne s'arrete pas a la reactivation de la pre-authentification. Il faut retirer l'exception, faire tourner le secret deja expose et verifier que les evenements 4768 sans pre-authentification ne concernent plus que des cas strictement documentes.

1. Supprimer les exceptions de pré-authentification non justifiées

Set-ADAccountControl -Identity vulnerable_user -DoesNotRequirePreAuth $false

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false
}

C'est le correctif principal. Si un compte n'a pas un besoin technique démontré, il ne doit pas conserver cette exception.

2. Faire une rotation de mot de passe après le correctif

Il ne faut pas s'arrêter à la réactivation de la pré-authentification. Si le compte était roastable, il faut considérer que le matériau a peut-être déjà été collecté.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
    Set-ADUser -ChangePasswordAtLogon $true

Pour les comptes de service, prévoyez une vraie rotation de secret, pas seulement un changement de flag.

3. Revoir les dépendances legacy

Si une équipe affirme qu'un compte doit rester sans pré-authentification, imposez une revue technique :

quel système en dépend réellement
si ce système peut être modernisé ou isolé
si le compte peut être ramené au minimum de privilèges
si l'ouverture de session interactive, la délégation ou l'appartenance à des groupes larges peuvent être retirées

Une exception de pré-auth sur un compte privilégié ou très réutilisé n'est pas un petit compromis de compatibilité. C'est une exposition hors ligne du secret.

4. Durcir les comptes qui doivent temporairement rester en exception

Si une exception doit survivre quelque temps :

imposez un mot de passe long et aléatoire
retirez les groupes privilégiés partout où c'est possible
restreignez les droits d'ouverture de session
surveillez spécifiquement les 4768 pour ce compte
fixez un propriétaire et une date de revue

5. Ne pas compter sur l'opacité des noms de comptes

Même avec LDAP anonyme désactivé, il faut considérer que les attaquants peuvent quand même reconstituer des listes de noms. Le contrôle durable consiste à supprimer les comptes roastables et à réduire la valeur de ceux qui doivent rester exceptionnels.

Validation après correction

Une clôture propre d'un sujet AS-REP Roasting repose sur quatre vérifications simples :

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} ne retourne que des exceptions documentées.
Les mots de passe des comptes précédemment exposés ont été rotés.
Les 4768 avec Pre-Authentication Type = 0 ont disparu pour les comptes ordinaires et les comptes de service non justifiés.
Toute exception restante a un propriétaire, une justification métier, des contrôles compensatoires et une date de revue.

Si ces quatre points ne sont pas prouvés, le sujet n'est pas réellement fermé.

Erreurs de défense fréquentes

Les erreurs reviennent souvent aux mêmes endroits :

croire que LDAP anonyme est une condition obligatoire de l'attaque
réactiver la pré-authentification sans faire tourner le mot de passe
laisser l'exception sur des comptes de service anciens avec des droits larges
considérer le réglage comme anodin parce que le compte n'est « pas interactif »
corriger un compte visible sans corriger le processus de provisioning qui a créé l'exception

Pour un lecteur technique, le vrai sujet n'est pas la complexité de l'exploit. Le vrai sujet est l'autorité accumulée par le compte exposé.

Références primaires

Comment EtcSec détecte cela

EtcSec signale les comptes avec pré-authentification Kerberos désactivée dans chaque audit AD.

Le constat principal est ASREP_ROASTING_RISK : tout compte avec DONT_REQ_PREAUTH activé est un candidat à l'exposition de mot de passe.

Des constats liés changent souvent la gravité réelle :

PASSWORD_NEVER_EXPIRES
PASSWORD_POLICY_WEAK
WEAK_KERBEROS_POLICY

La combinaison compte plus que le flag seul. Un compte roastable avec un mot de passe faible, ancien ou non expirant est bien plus dangereux qu'une exception temporaire fortement encadrée.

AS-REP Roasting : collecter des hashes sans identifiants