Ariovis

Chemin d'attaque Active Directory · Kerberos · MITRE ATT&CK T1558.004

AS-REP Roasting : quand Active Directory remet du matériau à casser hors ligne

L'AS-REP Roasting exploite une configuration précise : un compte Active Directory pour lequel la pré-authentification Kerberos n'est pas exigée. Le contrôleur de domaine peut alors délivrer une réponse Kerberos contenant des données protégées par le secret du compte, sans que l'utilisateur ait d'abord prouvé qu'il connaissait ce secret.

L'attaquant peut emporter ces données et tenter de retrouver le mot de passe hors ligne. La vraie question devient alors : que permet d'atteindre cette identité si le secret tombe ?

Revenir au cas d'usage : sécuriser Active Directory et réduire les chemins d'attaque
MITRE ATT&CK
T1558.004
Tactique
Credential Access
Composant
Kerberos / KDC
Condition
Pré-authentification Kerberos désactivée
Objet AD
userAccountControl
Flag
DONT_REQ_PREAUTH
Valeur
0x400000 / 4194304
Signal Windows majeur
Event ID 4768 · Pre-Authentication Type = 0

Le chemin d'attaque, étape par étape

Deux points d'entrée différents mènent au même matériau exploitable. La suite, en revanche, dépend entièrement de ce que l'identité concernée permet réellement de faire dans l'annuaire.

Branche A · Accès au domaine

  1. 01Accès authentifié au domaine
  2. 02Énumération des comptes de l'annuaire
  3. 03Identification d'un compte sans pré-authentification

Branche B · Nom d'utilisateur connu

  1. 01Nom de compte plausible ou déjà connu
  2. 02Requête AS-REQ ciblée sur cette identité

Convergence · Obtention du secret

  1. 01Compte porteur du flag DONT_REQ_PREAUTH
  2. 02AS-REQ sans preuve préalable du secret
  3. 03Réponse AS-REP délivrée par le KDC
  4. 04Récupération des données chiffrées
  5. 05Tentative de cassage hors ligne
  6. 06Secret utilisateur récupéré si le mot de passe est suffisamment faible
Rupture : obtenir le secret ≠ atteindre une ressource critique

Impact réel dans l'annuaire

  1. 01Authentification avec un compte valide
  2. 02Exploration des groupes, délégations et ressources accessibles
  3. 03Éventuel chemin vers un actif critique

Le roast n'est pas le chemin complet. Le danger dépend de ce que contrôle l'identité compromise.

Ce que la pré-authentification Kerberos change

Dans un échange Kerberos standard, le client ne reçoit rien d'exploitable avant d'avoir démontré qu'il détient bien le secret du compte.

  1. 01Le client prépare notamment une preuve chiffrée avec une clé dérivée de son secret.
  2. 02Le KDC vérifie que le demandeur possède bien cette clé.
  3. 03Le KDC délivre ensuite le TGT si la vérification réussit.

L'intérêt est simple : le KDC ne livre pas directement, à n'importe quel demandeur, les éléments nécessaires à une tentative de cassage hors ligne.

Avec DONT_REQ_PREAUTH, cette étape de vérification préalable disparaît pour le compte concerné. Le serveur peut donc retourner une réponse AS-REP sans avoir préalablement obtenu cette preuve.

Une partie de la réponse contient des données chiffrées à l'aide d'une clé dérivée du secret du compte. Les outils de sécurité offensive savent transformer ces données dans un format permettant de tester hors ligne des candidats de mot de passe.

On parle couramment de « hash AS-REP ». C'est un raccourci opérationnel utile pour se comprendre entre équipes, mais l'AS-REP ne contient pas le mot de passe ni son empreinte telle quelle.

DONT_REQ_PREAUTH : un seul bit suffit à créer l'exposition

L'exposition ne provient pas d'une vulnérabilité logicielle mais d'un attribut de l'objet compte dans l'annuaire.

Attribut
userAccountControl
Flag
DONT_REQ_PREAUTH
Hexadécimal
0x400000
Décimal
4194304
Signification
le compte n'est pas tenu de présenter les données de pré-authentification Kerberos attendues.
  • compatibilité historique avec un composant tiers ;
  • applications anciennes dont le comportement Kerberos était limité ;
  • migrations et bascules d'annuaire ;
  • exceptions temporaires jamais retirées ;
  • configuration manuelle héritée, reproduite par copie de compte.

Toutes les occurrences ne proviennent pas d'un système legacy. Un compte peut porter ce flag à la suite d'un modèle de création dupliqué, d'un script d'administration ou d'un choix ponctuel jamais réévalué. La cause doit être établie compte par compte.

Le problème n'est pas Kerberos. Le problème est l'exception devenue permanente.

Un compte roastable n'est pas forcément critique. Son environnement peut l'être.

C'est le point qui distingue une lecture par chemins d'attaque d'un simple constat de mauvaise configuration. Un compte dispensé de pré-authentification peut être de nature très variée.

  • un compte utilisateur banal ;
  • un ancien compte applicatif ;
  • un compte de service historique ;
  • un compte disposant indirectement de groupes sensibles ;
  • une identité contrôlant une ressource qui permet elle-même de progresser.

La question habituelle

Combien de comptes sont roastables ?

La bonne question

Qu'est-ce que ces comptes permettent de contrôler ?

Exemple conceptuel de progression

  1. 01Utilisateur
  2. 02Membre d'un groupe applicatif
  3. 03Groupe disposant d'une délégation
  4. 04Droit de modification sur un serveur
  5. 05Session d'administration présente
  6. 06Chemin vers une identité privilégiée

C'est la logique des relations de contrôle décrite par l'ANSSI dans ses recommandations de sécurité relatives à Active Directory : une faiblesse isolée devient critique lorsqu'elle permet de progresser vers des ressources de confiance.

Prioriser un correctif AD uniquement selon la gravité théorique de la faiblesse manque une partie du problème. Il faut mesurer les chemins qu'elle ouvre ou qu'elle raccourcit.

AS-REP Roasting et Kerberoasting : deux phases différentes du même protocole

Les deux techniques cherchent à obtenir hors ligne un secret protégeant des données Kerberos, mais elles ne visent ni les mêmes comptes ni le même échange.

CritèreAS-REP RoastingKerberoasting
CibleComptes ne nécessitant pas la pré-authentification Kerberos.Comptes associés à un ou plusieurs services identifiés par un SPN.
Échange KerberosAS-REQ / AS-REP, au moment de la demande de TGT.Demande de ticket de service, échange TGS.
Condition particulièreFlag DONT_REQ_PREAUTH positionné sur le compte.SPN exploitable associé au compte ciblé.
Secret attaqué hors ligneOui : l'attaquant cherche à retrouver le secret protégeant les données Kerberos.Oui : même objectif, à partir d'un élément lié au ticket de service.
Privilèges nécessairesUn compte du domaine facilite l'énumération, mais un nom d'utilisateur plausible peut suffire à tester une requête.Une identité déjà authentifiée dans le domaine est généralement nécessaire.
ImpactDépend des privilèges et des chemins accessibles à l'identité dont le secret est récupéré.Même logique : l'impact se mesure aux droits du compte compromis.
Comparer avec le Kerberoasting

Ce que le contrôleur de domaine peut montrer

La détection repose d'abord sur les journaux des contrôleurs de domaine, à condition de les collecter et de les interpréter avec le contexte de l'identité concernée.

Event ID 4768 — A Kerberos authentication ticket (TGT) was requested

  • L'événement est émis sur les contrôleurs de domaine.
  • Un Pre-Authentication Type égal à 0 signifie qu'aucune pré-authentification n'a été utilisée.
  • Microsoft considère les comptes configurés ainsi comme un risque de sécurité.
  • Un événement 4768 avec un Pre-Authentication Type 0 constitue donc un signal fort à analyser.
Un événement 4768 avec PreAuthType 0 ne prouve pas une attaque. Il démontre une authentification sans pré-authentification. Il faut ensuite déterminer si le compte, la source, la fréquence et le contexte correspondent à un usage légitime.

Ce qu'il faut regarder dans l'événement et autour

  • TargetUserName
  • Adresse IP cliente
  • PreAuthType
  • Type de chiffrement du ticket
  • Fréquence des demandes
  • Nombre de comptes différents interrogés
  • Comportement ultérieur de l'identité
  • Event ID 4769 lorsque pertinent

Corrélations recommandées par MITRE

  • Event 4768 avec un Pre-Authentication Type 0 ;
  • activité ultérieure de tickets de service, Event 4769 ;
  • recours éventuel à RC4, etype 0x17 ;
  • énumération anormale des comptes configurés sans pré-authentification.

Microsoft a fait évoluer les informations disponibles dans l'événement 4768 sur les Windows Server 2016 et ultérieurs mis à jour avec les correctifs de sécurité de janvier 2025 et suivants. Une règle SIEM ne doit donc pas dépendre aveuglément d'un parsing historique : le format et les champs disponibles doivent être vérifiés sur le parc réellement déployé.

Détecter l'AS-REP Roasting n'est pas seulement chercher un Event ID. C'est relier la demande Kerberos à l'identité, à sa source et à ce qu'elle fait ensuite.

Le meilleur AS-REP Roasting est celui qui n'a rien à roaster

Avant la détection vient l'inventaire : savoir quels comptes portent le flag, puis comprendre ce qu'ils permettraient d'atteindre.

Contrôle de configuration

Inventorier les comptes dont l'attribut DoesNotRequirePreAuth est actif est un contrôle simple, en lecture seule, réalisable avec le module Active Directory PowerShell.

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth |
  Select-Object SamAccountName, Enabled, DoesNotRequirePreAuth

Cette commande est un exemple de contrôle ponctuel, pas une couverture exhaustive d'un audit Active Directory : elle ne couvre ni les comptes désactivés à réexaminer, ni les autres classes d'objets, ni les autres domaines de la forêt.

Un script vous dit quels comptes portent le flag. Il ne vous dit pas forcément lesquels créent le chemin d'attaque le plus critique.

01

Inventaire

Lister les comptes concernés et leur état d'activation.

02

Analyse de risque

Qualifier chaque compte : usage réel, propriétaire, robustesse du secret, dépendances.

03

Cartographie des chemins

Relier ces comptes aux groupes, délégations, ACL et ressources qu'ils permettent d'atteindre.

04

Remédiation priorisée

Traiter d'abord les comptes dont la compromission raccourcit le plus un chemin vers le Tier 0.

Casser le chemin d'attaque

La correction se traite par ordre d'effet : supprimer l'exception quand c'est possible, comprendre pourquoi elle existait, puis réduire ce que le secret permettrait d'obtenir.

  1. Priorité 1

    Réactiver la pré-authentification Kerberos

    Partout où aucune dépendance technique ne l'interdit. Le cmdlet Microsoft Set-ADAccountControl dispose du paramètre -DoesNotRequirePreAuth ; la cible défensive est DoesNotRequirePreAuth = False. Une modification massive en production ne doit jamais être recommandée sans avoir qualifié les éventuelles dépendances historiques.

  2. Priorité 2

    Identifier pourquoi l'exception existait

    Application historique, migration, ancien compte technique, configuration devenue inutile : sans cette réponse, le flag réapparaîtra tôt ou tard.

  3. Priorité 3

    Renforcer les secrets des comptes qui doivent conserver l'exception

    MITRE recommande notamment des mots de passe robustes et un chiffrement Kerberos moderne, AES plutôt que RC4 lorsque c'est possible. Renforcer le mot de passe ou passer à AES réduit le risque de cassage : cela ne rend pas souhaitable le maintien de DONT_REQ_PREAUTH.

  4. Priorité 4

    Analyser les droits du compte

    Ce que le secret permettrait réellement d'obtenir se lit dans l'annuaire.

    • groupes d'appartenance, directs et imbriqués ;
    • délégations Kerberos et administratives ;
    • ACL positionnées sur les objets sensibles ;
    • accès administratifs sur les serveurs ;
    • accès applicatifs sensibles ;
    • chemins vers le Tier 0.
  5. Priorité 5

    Surveiller toute future réactivation du flag

    La correction ne doit pas être ponctuelle : une création de compte par copie, un script d'exploitation ou une exception accordée en urgence peuvent recréer exactement le même risque.

Zero Standing Privileges limite l'impact, pas le roast

Retirer les privilèges permanents ne corrige pas DONT_REQ_PREAUTH et n'empêche pas une tentative d'AS-REP Roasting.

En revanche, si une identité compromise n'a aucun privilège sensible permanent et doit obtenir ses capacités élevées de manière contrôlée et temporaire, la valeur opérationnelle du secret volé diminue fortement.

La prévention Kerberos et la réduction du privilège répondent donc à deux endroits différents du même chemin d'attaque.

Moindre privilège : la définition et ses limites opérationnelles

Ce qu'un diagnostic doit réellement chercher

Détecter DONT_REQ_PREAUTH est relativement simple. Décider quoi corriger en premier l'est moins.

Un diagnostic Active Directory utile rapproche la configuration des comptes de leurs privilèges, délégations, groupes, actifs accessibles et chemins vers les ressources sensibles.

L'objectif n'est donc pas simplement de produire une liste de mauvaises configurations, mais de distinguer les faiblesses isolées des chemins réellement exploitables et de construire une remédiation priorisée.

Ariovis aide à identifier, prioriser, corriger et surveiller les conditions qui rendent ce chemin exploitable. C'est une contribution à votre trajectoire de durcissement, parmi d'autres contrôles internes.

  • audit de sécurité Active Directory ;
  • analyse des comptes à privilèges ;
  • analyse des délégations, groupes et droits sensibles ;
  • revue des chemins d'attaque liés aux identités ;
  • recommandations de durcissement ;
  • plan de remédiation priorisé ;
  • supervision et détection ;
  • amélioration de la traçabilité ;
  • accompagnement à la correction.
Découvrir l'offre Sécurité des identités et Active DirectoryÉvaluer mon Active DirectoryTester l'exploitabilité réelle de mes chemins d'identité

Questions fréquentes

Quelle est la différence entre AS-REP Roasting et Kerberoasting ?
L'AS-REP Roasting vise des comptes pour lesquels la pré-authentification Kerberos n'est pas exigée : la réponse AS-REP du KDC contient alors des données protégées par le secret du compte. Le Kerberoasting vise des comptes associés à un SPN et s'appuie sur la demande d'un ticket de service, côté TGS. Les deux techniques cherchent ensuite à retrouver un secret hors ligne, mais elles n'exploitent ni la même phase du protocole ni la même mauvaise pratique.
Faut-il déjà avoir compromis un compte Active Directory ?
Non, pas nécessairement. Un nom de compte connu peut suffire à tester une requête AS-REQ. Disposer d'un compte du domaine facilite toutefois nettement l'énumération LDAP des comptes mal configurés, et donc le ciblage.
Event ID 4768 avec PreAuthType 0 prouve-t-il une attaque ?
Non. Il indique qu'une demande de TGT a été traitée sans pré-authentification. Le contexte, la source, la fréquence et l'activité ultérieure de l'identité doivent être analysés avant de conclure.
Un mot de passe fort suffit-il ?
Il augmente fortement le coût du cassage hors ligne, mais il ne corrige pas la mauvaise configuration. La pré-authentification doit être réactivée lorsque cela est possible.
Le MFA bloque-t-il l'AS-REP Roasting ?
Un MFA utilisé sur une application ou un parcours d'accès distinct ne corrige pas la configuration Kerberos du compte dans Active Directory. Le traitement principal reste la suppression de l'exception de pré-authentification ; d'autres contrôles peuvent ensuite réduire les usages possibles du secret compromis.
AES supprime-t-il le risque ?
Un chiffrement moderne est préférable à RC4 et rend certaines attaques plus coûteuses, mais laisser volontairement la pré-authentification désactivée demeure une faiblesse à traiter.

Sources et références

Sources de premier rang utilisées pour cette fiche.

Aller plus loin

Les contenus Ariovis qui prolongent directement ce sujet.

Échanger sur les chemins d'attaque de mon annuaire