Active Directory AS-REP Roasting Comptes de Service Privilégiés : Les Comptes Que la Pré-Authentification Était Censée Protéger

Active directory AS-REP roasting comptes de service privilégiés est le cas à enjeux plus élevés que couvre cet article : des comptes Kerberos avec la pré-authentification désactivée qui se trouvent en plus dans un groupe privilégié ou fonctionnent comme compte de service — pas un utilisateur standard quelconque.

Active Directory AS-REP Roasting Comptes de Service Privilégiés

Le catalogue EtcSec suit le cas des comptes privilégiés séparément sous ADMIN_ASREP_ROASTABLE (Critique), car un compte déjà membre de Domain Admins, Enterprise Admins ou d'un autre groupe Tier 0 avec ce flag activé transforme l'AS-REP roasting en une course de cracking hors ligne directe vers le DA, et non en une chaîne de mouvement latéral à plusieurs étapes. Pour la version générale de cette attaque, applicable à tout compte, voir AS-REP Roasting : collecter des hashes sans identifiants — cet article est plus restreint, centré sur le cluster des comptes privilégiés et de service que l'autre article ne cible pas.

Le flag sous-jacent est DONT_REQ_PREAUTH (0x400000 / décimal 4194304) dans l'attribut userAccountControl (Microsoft Learn : UserAccountControl property flags). Quand il est activé, n'importe quel client peut demander une réponse Kerberos Authentication Server (AS-REP) pour ce compte, et la réponse revient avec une portion chiffrée à l'aide d'une clé dérivée du mot de passe du compte — sans que le client ait jamais à prouver qu'il connaît ce mot de passe. MITRE ATT&CK T1558.004 référence cela comme « Steal or Forge Kerberos Tickets: AS-REP Roasting ».

La plupart des articles génériques traitent ce sujet comme une simple mesure d'hygiène applicable à tous les comptes utilisateurs. Ce cadrage passe à côté de deux clusters spécifiques qui comptent davantage :

• Comptes privilégiés sans pré-authentification (ADMIN_ASREP_ROASTABLE, Critique) — appartenance à un groupe Tier 0 combinée à un hash roastable.
• Comptes de service avec le cluster de mauvaises configurations adjacentes — pas de pré-authentification (SERVICE_ACCOUNT_NO_PREAUTH), ouverture de session interactive autorisée (SERVICE_ACCOUNT_INTERACTIVE), et un mot de passe qui n'a pas été changé depuis plus d'un an (SERVICE_ACCOUNT_OLD_PASSWORD). Chacun est de sévérité Haute pris isolément ; ensemble, ils signifient que le hash est facile à obtenir et, une fois cracké, reste valide longtemps sur un compte qui peut aussi être détourné pour un accès interactif.

Pourquoi le flag finit par être activé sur des comptes réels

DONT_REQ_PREAUTH est rarement activé par malveillance — c'est généralement un reliquat d'un besoin de compatibilité spécifique jamais nettoyé. Les causes documentées incluent les migrations SIDHistory inter-domaines, où certaines solutions tierces de VPN ou de fédération n'arrivent pas à finaliser la pré-authentification Kerberos pour les identités migrées à moins que le flag ne soit temporairement désactivé pendant la bascule (Quest support KB 4313059), ainsi que la compatibilité avec des applications ou appliances legacy, où une ancienne bibliothèque client Kerberos ne sait pas du tout gérer la pré-authentification (Tenable : How to Stop the Kerberos Pre-Authentication Attack ; JumpCloud : What Is Kerberos Pre-Authentication?). La migration ou l'appliance legacy finit par être décommissionnée ; le flag reste activé indéfiniment sur le compte parce que plus personne ne le revérifie.

Comment ça fonctionne

La pré-authentification Kerberos existe précisément pour bloquer cette classe d'attaque : le client doit chiffrer un timestamp avec une clé dérivée de son mot de passe et l'envoyer dans l'AS-REQ avant que le KDC n'émette quoi que ce soit. Sans cette exigence, la séquence se réduit à quatre étapes : l'attaquant envoie une AS-REQ pour le nom d'utilisateur ciblé sans mot de passe et sans authentification préalable au domaine, tant que le compte est énumérable (LDAP, RPC, ou une liste de noms d'utilisateurs fuitée) ; le KDC répond immédiatement par une AS-REP car la pré-authentification n'est pas requise ; une partie de cette AS-REP est chiffrée avec une clé dérivée du mot de passe du compte ; et l'attaquant crack cette portion hors ligne, sans aucune journalisation côté domaine des tentatives de mot de passe échouées, puisque chaque essai se déroule sur le matériel de l'attaquant, pas contre le DC.

La vitesse de cracking dépend du type de chiffrement Kerberos négocié. Si le compte autorise encore RC4 (etype 23), l'attaquant demande RC4, et le mode hashcat 18200 ($krb5asrep$23$...) le crack plusieurs ordres de grandeur plus vite qu'une réponse AES-256 (etype 18). Le fallback RC4 vaut la peine d'être corrigé en même temps — voir Kerberos RC4 Fallback in Active Directory pour la détection et la suppression de cette dérive.

La chaîne d'attaque

L'AS-REP roasting est rarement isolé dans une compromission réelle. Un walkthrough publié du lab ShadowGate par Hack Smarter Labs — « ShadowGate Active Directory Lab Walkthrough » par incoggeek — décrit une chaîne qui commence par une énumération SMB anonyme, passe à l'AS-REP roasting comme première étape authentifiée, puis bascule vers un abus d'ACL cartographié par BloodHound (un droit GenericWrite exploité via Shadow Credentials) et des attaques d'enrôlement AD CS (ESC8, via une authentification forcée par PetitPotam vers le point de terminaison web d'enrôlement de la CA) jusqu'à un certificat de contrôleur de domaine. L'AS-REP roasting est ce qui transforme un point d'entrée totalement non authentifié en premier secret crackable de cette chaîne — la même raison pour laquelle Active Directory Attack Paths to Domain Admin traite une étape précoce de roasting Kerberos comme une arête pivot, et exactement pourquoi un constat ADMIN_ASREP_ROASTABLE sur un compte Tier 0 est noté Critique plutôt que traité comme de l'hygiène courante.

Étape 1 — Énumérer et demander

# Impacket -- énumère chaque compte de usersfile.txt avec la pré-auth désactivée
# et récupère les hashes AS-REP crackables sans aucun identifiant de domaine valide
impacket-GetNPUsers CORP.LOCAL/ -no-pass -usersfile usersfile.txt -format hashcat -outputfile asrep_hashes.txt

Étape 2 — Cracker hors ligne

# Cracker hors ligne les hashes $krb5asrep$23$... obtenus (mode 18200 = Kerberos 5, AS-REP, etype 23)
hashcat -m 18200 asrep_hashes.txt rockyou.txt

Détection

Le signal le plus fiable est l'Event ID 4768 de Windows Security (demande de ticket d'authentification Kerberos) avec Pre-Authentication Type 0, qui ne se produit légitimement que lorsque le compte cible a la pré-auth désactivée (MITRE ATT&CK Detection Strategy DET0113 ; HackTheBox : AS-REP roasting detection). Associez-le au type de chiffrement négocié : 0x17 (RC4) combiné à Pre-Auth Type 0 est l'indicateur combiné le plus fort, car un attaquant rétrograde délibérément vers RC4 pour accélérer le cracking hors ligne. Pour la référence plus large de politique d'audit et d'Event ID sur laquelle repose cette détection, voir Active Directory Monitoring: Security Event IDs That Matter.

Deux requêtes PowerShell couvrent directement les détecteurs de ce cluster :

# Comptes privilégiés avec pré-auth désactivée (candidats ADMIN_ASREP_ROASTABLE)
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (adminCount -eq 1)} `
    -Properties userAccountControl, adminCount, ServicePrincipalName, MemberOf |
    Select-Object Name, DistinguishedName, ServicePrincipalName

# Comptes de service (avec SPN) avec pré-auth désactivée, plus l'ancienneté du mot de passe
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (ServicePrincipalName -like '*')} `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate |
    Select-Object Name, ServicePrincipalName, PasswordLastSet,
        @{N='PasswordAgeDays';E={(New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days}}

SERVICE_ACCOUNT_INTERACTIVE n'est pas un flag userAccountControl — c'est un constat comportemental. Confirmez-le en corrélant le sAMAccountName du compte de service avec les événements 4624 ayant un Logon Type 2 (Interactive) ou 10 (RemoteInteractive/RDP). Un vrai compte de service ne devrait montrer que Logon Type 3 (Network) ou 5 (Service).

Remédiation

Pour les comptes privilégiés

Retirez le flag : décochez « Ne pas exiger la préauthentification Kerberos » dans l'onglet Compte du compte, ou exécutez Set-ADAccountControl -Identity <account> -DoesNotRequirePreAuth $false. Relancez la requête de détection ci-dessus et confirmez qu'elle retourne zéro résultat. Si le compte a été marqué à cause d'une migration SIDHistory passée ou d'une bascule de fédération, confirmez que cette migration est entièrement terminée — SIDHistory nettoyée comprise — avant de réactiver la pré-auth, afin qu'elle ne casse pas une dépendance encore active.

Pour les comptes de service

1. Migrer les comptes de service roastables vers gMSA. Les Group Managed Service Accounts font tourner automatiquement un mot de passe de 120 caractères et ne peuvent, par conception, pas être utilisés pour une ouverture de session interactive — ce qui referme SERVICE_ACCOUNT_OLD_PASSWORD et SERVICE_ACCOUNT_INTERACTIVE en une seule opération. Voir gMSA Password Exposure in Active Directory pour les réserves sur qui peut encore lire le mot de passe d'un gMSA une fois déployé.
2. Restreindre explicitement l'ouverture de session interactive. Là où un compte ne peut pas encore migrer vers gMSA, appliquez « Refuser l'ouverture de session locale » et « Refuser l'ouverture de session par les services Bureau à distance » via une GPO limitée à l'OU du compte de service, et restreignez « Ouvrir une session en tant que service » aux seuls hôtes qui en ont réellement besoin.
3. Faire tourner le mot de passe et imposer Kerberos AES. Définissez dès maintenant un mot de passe fort et unique, et placez le compte sous une politique de mot de passe ou une Fine-Grained Password Policy qui impose réellement la rotation au lieu de le laisser statique pendant un an ou plus. Séparément, imposez AES plutôt que RC4 via « Sécurité réseau : configurer les types de chiffrement autorisés pour Kerberos » — cela ne corrige pas l'absence d'exigence de pré-auth, mais augmente le coût de cracking de chaque ticket que le compte négocie légitimement.
4. Ne pas utiliser Protected Users comme correctif. Le groupe de sécurité Protected Users est le bon contrôle pour les comptes privilégiés humains, mais Microsoft déconseille explicitement d'y ajouter des comptes de service ou d'ordinateur : l'appartenance bloque la mise en cache des identifiants, donc un compte de service qui ne peut pas joindre un DC même brièvement échouera complètement. L'appartenance ne retire pas non plus le flag DONT_REQ_PREAUTH — un compte de service laissé dans le groupe avec ce flag toujours activé reste exactement aussi roastable qu'avant. Voir Active Directory Privileged Accounts: Protected Users, Delegation, and Service Account Gaps pour savoir où ce groupe s'applique et où il ne s'applique pas.

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec vérifie directement ce cluster : ADMIN_ASREP_ROASTABLE marque les membres de groupes privilégiés avec la pré-authentification Kerberos désactivée, SERVICE_ACCOUNT_NO_PREAUTH couvre le même flag sur tout compte de service porteur d'un SPN, SERVICE_ACCOUNT_INTERACTIVE marque les comptes de service observés ou configurés pour une ouverture de session interactive, et SERVICE_ACCOUNT_OLD_PASSWORD marque les comptes de service dont le mot de passe n'a pas tourné dans les délais de la politique. Aucun de ces contrôles ne nécessite de simulation d'attaque en direct — ce sont des vérifications d'attribut LDAP et de comportement de connexion exécutées à chaque passage d'audit.