Chemin d'attaque Active Directory · PKI · AD CS · ESC1 · MITRE ATT&CK T1649
Active Directory Certificate Services ne sert pas seulement à chiffrer ou signer des données : certains certificats deviennent eux-mêmes des moyens d'authentification, au même titre qu'un mot de passe ou qu'un ticket Kerberos.
ESC1 apparaît lorsqu'un modèle combine plusieurs choix dangereux : une population peu privilégiée peut demander un certificat, fournir elle-même l'identité portée par la demande et obtenir un certificat utilisable pour l'authentification, sans contrôle suffisant avant émission.
Le risque n'est donc pas « une mauvaise case à cocher ». Il vient de l'interaction entre le modèle de certificat, ses permissions d'inscription, ses usages autorisés et les contrôles appliqués par l'autorité de certification.
La vraie question
Qui peut demander quel certificat, sous quelle identité, et qui vérifie cette identité avant émission ?
Active Directory Certificate Services fournit les briques Microsoft permettant d'exploiter une infrastructure à clés publiques dans un environnement Windows. La PKI n'est donc pas un service périphérique : elle produit des objets cryptographiques que le système d'information accepte comme preuves.
Un certificat peut représenter une identité humaine, une machine ou une application, et cette représentation est reconnue par les mécanismes d'authentification du domaine lorsque le certificat porte les usages correspondants.
Les certificats peuvent servir notamment
Émet et signe les certificats. Elle applique les contrôles d'émission définis par l'organisation.
Définit qui peut demander quel type de certificat, sous quelles conditions et avec quels usages.
Devient une preuve utilisable par le système selon les usages qui lui ont été accordés.
ESC1 n'est pas un chemin d'attaque complet : c'est une technique qui s'insère dans un chemin lorsque la configuration le permet. Chaque flèche ci-dessous dépend de ce que le modèle, l'autorité de certification et les contrôleurs de domaine autorisent réellement.
Identité peu privilégiée
Droit d'inscription sur un modèle sensible
Modèle autorisant le demandeur à fournir l'identité du certificat
Certificat utilisable pour l'authentification
Certificat émis sans contrôle compensatoire suffisant
Usurpation possible d'une identité plus privilégiée selon le contexte de mapping
Accès à des ressources ou privilèges critiques
Tier 0 si l'identité représentée le permet
Le résultat final n'est pas universel : il dépend du modèle, des extensions portées par le certificat, du mécanisme d'authentification utilisé, des règles de certificate mapping et du niveau de durcissement des contrôleurs de domaine.
Le problème ESC1 n'est pas qu'un certificat ait été émis. Le problème est qu'une identité ait pu choisir elle-même l'identité représentée par un credential que le domaine accepte.
Aucune de ces conditions ne constitue à elle seule une vulnérabilité. C'est leur combinaison, sur un même modèle publié et accessible, qui transforme une fonctionnalité légitime en chemin d'élévation.
Le modèle doit être publié par une autorité de certification utilisable par la population concernée : sans publication ni accessibilité réelle, la configuration reste théorique.
Les ACL du modèle accordent des droits d'enrollment à une population trop large au regard du rôle du modèle, par exemple une population d'utilisateurs ordinaires.
Accorder l'inscription à Domain Users ou Authenticated Users n'est pas incorrect en soi : le risque dépend de ce que le modèle permet ensuite de représenter.
Le modèle utilise le comportement couramment identifié par Supply in the request, ou Enrollee Supplies Subject, ce qui permet à la demande de porter des informations d'identité qui ne sont pas nécessairement dérivées de l'objet Active Directory du demandeur.
Le modèle comporte un usage compatible avec l'authentification. Plusieurs EKU documentés peuvent produire cet effet, et ESC1 ne se réduit pas au seul Client Authentication :
L'absence de contrôles compensatoires laisse les autres paramètres produire leur effet complet, notamment lorsque manquent :
ESC1 n'est donc pas « Enrollee Supplies Subject = vulnérable ». C'est une combinaison de configuration et d'autorisations dont il faut analyser l'effet réel dans l'environnement concerné.
Le Subject Alternative Name permet à un certificat de porter des identités alternatives. Cette capacité est parfaitement légitime et nécessaire dans de nombreux usages techniques, depuis les services web jusqu'aux scénarios d'inscription automatisés.
Le problème n'apparaît donc pas parce qu'un certificat porte un SAN, mais lorsque trois éléments se rencontrent sur le même modèle et que la PKI risque alors de signer une information d'identité qu'elle aurait dû contrôler.
La combinaison problématique
Microsoft a renforcé l'authentification par certificat à la suite de KB5014754, en introduisant une extension liant fortement le certificat au compte Active Directory correspondant et en séquençant la bascule des contrôleurs de domaine vers un mode d'enforcement plus strict.
Depuis février 2025, les contrôleurs de domaine Windows sont passés par défaut en mode d'enforcement renforcé, et depuis les mises à jour Windows du 9 septembre 2025 le mécanisme temporaire permettant de revenir au mode de compatibilité via StrongCertificateBindingEnforcement n'est plus supporté. Les anciennes méthodes de mapping faibles ne doivent donc pas être présentées comme le fonctionnement normal d'un domaine Windows complètement à jour.
Cela change la manière d'évaluer ESC1 : reproduire un scénario de laboratoire de 2021 qui conclut qu'une identité fournie dans le SAN donne automatiquement un accès administrateur ne correspond pas à l'état d'un domaine à jour. ESC1 reste référencé en 2026 par Microsoft Defender for Identity comme une configuration dangereuse, mais son exploitabilité concrète doit être évaluée avec la configuration actuelle des modèles, de la CA, des contrôleurs de domaine et des mécanismes de certificate mapping.
La particularité du risque certificat est de créer un nouveau moyen d'authentification plutôt que de découvrir nécessairement le secret existant du compte ciblé. Là où d'autres techniques cherchent à récupérer ou casser un secret, une configuration ESC1 exploitable permet d'obtenir un credential neuf, signé par une infrastructure que le domaine reconnaît déjà comme digne de confiance.
Cette différence a un effet direct sur la gouvernance : une PKI insuffisamment gouvernée peut court-circuiter les contrôles placés autour des mots de passe, comme la rotation, la complexité ou la surveillance des authentifications par secret, et transformer une mauvaise délégation technique en accès privilégié durable tant que le certificat reste valide et accepté.
Récupérer du matériel à attaquer hors ligne.
Obtenir des secrets déjà existants.
Obtenir, dans une configuration exploitable, un nouveau credential signé par une infrastructure de confiance.
Le coût opérationnel est également différent : révoquer un droit ne suffit pas toujours, car un certificat déjà émis conserve sa validité jusqu'à sa révocation effective et sa prise en compte par les mécanismes de vérification.
La détection d'ESC1 ne repose pas sur une signature unique. Elle combine une lecture de posture, une surveillance de l'émission et une corrélation avec l'usage réel des credentials produits.
Le meilleur signal ESC1 est souvent visible avant l'attaque : il se trouve dans la configuration du modèle. L'inventaire doit couvrir :
Les événements liés aux Certification Services documentent les demandes et les émissions, à condition que la journalisation soit correctement configurée pour produire la télémétrie attendue. Ces événements ne prouvent pas une attaque ESC1 : ils deviennent utiles lorsque le SIEM analyse le demandeur, le modèle, les informations d'identité demandées, l'autorité émettrice, la fréquence et le contexte temporel.
Le signal devient exploitable lorsque l'émission du certificat est corrélée avec l'utilisation ultérieure du credential, notamment via le contexte Kerberos autour de l'Event ID 4768 lorsque cette corrélation est possible dans l'environnement.
AD CS répond à des besoins métier réels. La remédiation consiste à retirer la combinaison qui crée le chemin, en conservant les usages légitimes de la PKI.
Lorsque l'identité peut être dérivée d'Active Directory, préférer cette approche : le modèle produit alors un certificat dont le sujet reflète l'objet annuaire du demandeur.
Supply in the request peut être légitime pour certains scénarios techniques : ne jamais recommander de le désactiver partout sans qualification.
Identifier précisément quelles populations doivent pouvoir demander le certificat, puis retirer les droits excessivement larges lorsqu'ils ne correspondent pas au rôle réel du modèle.
Un modèle qui n'a pas besoin d'être utilisé pour authentifier un utilisateur ne devrait pas porter inutilement les EKU correspondants, car ce sont eux qui transforment le certificat en credential.
Manager approval et signatures autorisées peuvent constituer des mesures compensatoires efficaces sur les modèles les plus sensibles.
L'approbation manuelle n'est pas une solution universelle : elle augmente la charge opérationnelle et doit répondre au risque réel du modèle.
Après correction, vérifier à nouveau les chemins d'attaque et les usages légitimes de la PKI afin de confirmer que la remédiation supprime le risque sans casser les mécanismes métier qui dépendent de l'émission de certificats.
Une autorité capable d'émettre des credentials acceptés par Active Directory participe directement à la chaîne de confiance du domaine. Sa configuration, ses administrateurs, ses modèles et leurs ACL doivent donc être étudiés comme des éléments critiques de l'architecture d'identité, au même titre que les contrôleurs de domaine eux-mêmes.
C'est aussi pourquoi plusieurs mécanismes très différents peuvent aboutir au même résultat : un droit de réplication mal gouverné et un modèle de certificat mal cadré ne se ressemblent pas techniquement, mais tous deux permettent d'atteindre des secrets ou des identités de niveau Tier 0.
Une cartographie Tier 0 limitée à ces deux éléments est insuffisante
Un audit de sécurité Active Directory doit examiner les comptes privilégiés, les groupes, les délégations et les ACL, mais également les mécanismes capables de créer de nouveaux credentials de confiance. Dans un environnement utilisant AD CS, ignorer la PKI revient à analyser une moitié du système d'identité.
Notre démarche ne consiste donc pas à produire une liste d'ESC, mais à qualifier ce que la configuration permet réellement, en tenant compte des mécanismes de certificate mapping en vigueur et des usages métier de la PKI.
La question à laquelle l'audit doit répondre
Cette configuration permet-elle réellement à une identité ordinaire d'atteindre une identité ou une ressource critique ?
Dans un environnement AD CS, cela implique notamment d'analyser
Les autres fiches de la collection. Elles ne constituent pas des étapes obligatoirement successives : chacune s'insère dans un chemin d'attaque selon ce que l'environnement autorise.
Obtenir un secret attaquable à partir d'un compte de service.
Exploiter les droits de réplication pour obtenir les secrets du domaine.
Abuser d'une chaîne de confiance PKI pour obtenir un certificat d'authentification.
Références de premier rang utilisées pour étayer cette fiche.
Microsoft Defender for Identity
Certificates security posture assessment — Prevent users to request a certificate valid for arbitrary users (ESC1)Référence actuelle pour Supply in the request, les EKU d'authentification, les permissions d'enrollment, le manager approval, les signatures autorisées et la qualification actuelle d'ESC1.
Microsoft Support
KB5014754 — Certificate-based authentication changes on Windows domain controllersStrong Certificate Mapping, enforcement, extension SID, évolution 2022-2025 et situation applicable en 2026.
Microsoft — Advanced Audit Policy Configuration
Event ID 4886 — Certificate Services received a certificate requestSignification de l'événement et dépendance à la configuration de l'audit Certification Services.
Microsoft — Advanced Audit Policy Configuration
Event ID 4887 — Certificate Services approved a certificate request and issued a certificateCorrélation entre demande, modèle utilisé et certificat effectivement émis.
SpecterOps
Certified Pre-Owned: Abusing Active Directory Certificate ServicesTravail fondateur définissant la famille ESC et l'analyse historique d'ESC1. Les procédures offensives qu'il contient ne sont pas reprises ici.
MITRE ATT&CK
T1649 — Steal or Forge Authentication CertificatesRattachement du scénario à Credential Access et aux abus de certificats d'authentification.
ANSSI
Points de contrôle Active DirectoryPoints de contrôle de durcissement Active Directory, utiles pour cadrer la gouvernance des objets sensibles et des délégations.
ANSSI
Recommandations de sécurité pour la journalisation des systèmes Microsoft WindowsCadrage de la journalisation Windows en environnement Active Directory, préalable à toute détection fondée sur les événements.
Les contenus Ariovis qui prolongent directement ce sujet.
La page mère : techniques, priorisation et remédiation côté annuaire.
L'offre d'audit AD : délégations, ACL, comptes privilégiés, PKI et chemins d'attaque.
La trajectoire de mise sous contrôle du Tier 0, du constat aux premières remédiations.
