ADCS ESC2, ESC3, ESC5, ESC7 : escalade de certificats entre les techniques les plus connues

Qu'est-ce que les chemins d'escalade de certificats ADCS ESC2 ESC3 ESC5 ESC7

Les chemins d'escalade de certificats ADCS ESC2 ESC3 ESC5 ESC7 se situent dans l'espace entre deux extrémités bien couvertes de la surface d'attaque d'Active Directory Certificate Services (AD CS). Les travaux de recherche Certified Pre-Owned de SpecterOps ont nommé huit techniques, ESC1 à ESC8, et des recherches ultérieures ont ajouté ESC9, ESC10 et ESC11. Ce corpus couvre déjà ces deux extrémités : Chemins attaque ADCS : comment des erreurs de certificats deviennent des chemins d'escalade Active Directory couvre ESC1, ESC4, ESC6 et ESC8, et ADCS ESC9, ESC10, ESC11 : escalade de certificats au-delà d'ESC1-ESC8 couvre les techniques de la couche de mapping publiées après KB5014754. ESC2, ESC3, ESC5 et ESC7 sont les quatre techniques de la numérotation originale de SpecterOps qu'aucun des deux articles ne couvre.

Cet écart compte, car ces quatre techniques ne sont pas un reliquat aléatoire : elles s'enchaînent dans les mêmes chemins d'attaque Active Directory que l'analyse de type BloodHound cartographie pour toute autre technique Tier 0. ESC2 et ESC3 sont des techniques de niveau template, comme ESC1, mais au lieu d'un template qui fuite qui un certificat peut authentifier, elles fuitent à quoi un certificat peut servir une fois émis — soit à n'importe quel usage, soit à l'usage spécifique de demander des certificats au nom d'un tiers. ESC5 et ESC7 sont des techniques de contrôle d'accès, comme ESC4, mais au lieu d'une ACL sur un seul template de certificat, elles portent sur les objets et permissions qui contrôlent chaque template et chaque certificat que la CA émettra jamais : le contrôle d'accès propre de la CA, et les conteneurs PKI dans Active Directory qui hébergent les templates, les enregistrements de CA, et la liste des CA auxquelles les contrôleurs de domaine font confiance pour l'authentification.

Un environnement qui a déjà corrigé chaque résultat ESC1, ESC4, ESC6 et ESC8, ainsi que chaque résultat ESC9, ESC10 et ESC11, peut malgré tout conserver un chemin actif vers Domain Admin via ces quatre techniques — parce qu'aucun des autres contrôles ne vérifie la portée des EKU, la délégation d'agent d'enrôlement, ou le contrôle d'accès au niveau des objets PKI et de la CA.

Comment ça fonctionne

ESC2 — Templates Any Purpose ou sans EKU

ESC2 est un template de certificat dont l'Extended Key Usage (EKU) est soit l'OID Any Purpose (2.5.29.37.0), soit ne définit aucun EKU du tout, ce que Windows traite comme un template équivalent à une CA subordonnée utilisable pour n'importe quel usage. Selon la documentation Certify de SpecterOps, exploiter ceci nécessite simultanément : que le principal de l'attaquant dispose de droits d'enrôlement au niveau de la CA, que ce même principal dispose de droits d'enrôlement sur le template spécifique, que le template n'exige pas d'approbation par un manager, que le template n'exige pas de signatures autorisées (co-signées), et que l'EKU du template soit Any Purpose ou totalement absent.

Lorsque ces conditions sont réunies, l'attaquant enrôle un certificat depuis le template et obtient un identifiant que Windows acceptera pour n'importe quel usage consommateur de certificat — y compris, selon la documentation de SpecterOps, le même rôle « Certificate Request Agent » dont dépend ESC3. Autrement dit, un template ESC2 peut servir à amorcer une attaque d'agent d'enrôlement de type ESC3 même s'il ne déclare jamais explicitement l'EKU Certificate Request Agent. C'est aussi pourquoi les résultats ESC2 doivent toujours être vérifiés par rapport aux autres templates publiés de la CA avant d'être écartés comme peu sévères : un certificat Any Purpose n'est dangereux qu'à hauteur de ce que la CA permet d'en faire par ailleurs.

ESC3 — Templates agent d'enrôlement (chaîne à deux templates)

ESC3 est une chaîne à deux templates, pas une erreur de configuration isolée. Le premier template doit porter l'EKU Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1) — le même OID que Microsoft documente comme l'extension de politique d'application d'agent d'enrôlement utilisée pour l'émission de cartes à puce. Selon la documentation de SpecterOps, ce premier template nécessite les mêmes prérequis d'enrôlement qu'ESC2 (droits d'enrôlement au niveau CA et template, aucune approbation par un manager, aucune signature autorisée) plus cet EKU spécifique.

Une fois que l'attaquant détient ce certificat d'agent d'enrôlement, il lui faut un second template : un template qui ne restreint pas qui peut agir en tant qu'agent d'enrôlement, dans lequel l'attaquant peut s'enrôler, qui n'exige pas d'approbation par un manager, et dont l'EKU est compatible avec le rôle d'agent — authentification client, PKINIT, ouverture de session par carte à puce, Any Purpose, ou aucun EKU du tout. Une fois ces deux éléments réunis, l'attaquant demande un certificat depuis le second template au nom d'une identité cible, comme un Domain Admin, en utilisant le certificat d'agent d'enrôlement pour signer la demande. Le certificat obtenu authentifie comme la cible, pas comme l'attaquant.

La documentation Microsoft sur la fonctionnalité Restricted Enrollment Agent, introduite dans Windows Server 2008 Enterprise, décrit précisément pourquoi ceci est dangereux par défaut : avant cette fonctionnalité, « il n'est pas possible de permettre à un agent d'enrôlement d'enrôler uniquement un certain groupe d'utilisateurs », si bien que tout certificat d'agent d'enrôlement valide pouvait servir à demander un certificat au nom de n'importe quel utilisateur de l'organisation, y compris des Domain Admins. Restricted Enrollment Agent permet à un administrateur de CA de restreindre quels templates et quels groupes de sécurité cibles chaque certificat d'agent d'enrôlement peut viser — mais uniquement sur une CA en édition Enterprise, et uniquement si la fonctionnalité a réellement été configurée.

ESC5 — Contrôle d'accès vulnérable sur les objets PKI

ESC5 n'est pas du tout un problème de template. C'est un problème d'ACL Active Directory sur les objets qui rendent l'ensemble de la PKI digne de confiance. Selon la documentation de SpecterOps, les objets concernés sont :

• l'objet ordinateur AD propre du serveur CA
• le serveur RPC/DCOM du serveur CA
• l'arborescence du conteneur Public Key Services dans le contexte de nommage Configuration (CN=Public Key Services,CN=Services,CN=Configuration,DC=...), y compris ses sous-conteneurs Certificate Templates, Certification Authorities et Enrollment Services
• l'objet NTAuthCertificates à l'intérieur de ce conteneur

Selon la documentation du protocole [MS-WCCE] de Microsoft, l'objet NTAuthCertificates contient un attribut multivalué de certificats de signature de CA encodés en DER — en pratique, la liste des CA auxquelles les contrôleurs de domaine font confiance pour l'authentification par certificat (y compris l'ouverture de session par carte à puce). Si un attaquant peut écrire sur cet objet, il peut ajouter une CA malveillante à la liste de confiance ; chaque certificat que cette CA malveillante signera ensuite devient alors approuvé pour l'authentification de domaine. La documentation de SpecterOps donne un exemple concret du risque général : Domain Users détenant GenericAll sur le conteneur Certificate Templates et ses descendants — un contrôle total sur chaque définition de template de certificat de la forêt, depuis un groupe au périmètre par défaut.

La sévérité d'un résultat ESC5 dépend entièrement de l'objet exposé et à qui. Un accès en écriture au conteneur Certificate Templates permet à un attaquant de créer ou modifier des templates pour leur donner une forme ESC1/ESC2/ESC3 depuis zéro, en contournant tout durcissement déjà réalisé sur les templates existants. Un accès en écriture à l'objet ordinateur de la CA ou à son serveur RPC/DCOM peut mener à la compromission de l'hôte de la CA lui-même, et avec lui, de la clé privée de la CA — la même classe d'impact documentée dans Certighost CVE-2026-54121 ADCS : les utilisateurs à faibles privilèges peuvent usurper un contrôleur de domaine, où une faille AD CS différente permettait à un utilisateur à faibles privilèges d'usurper un contrôleur de domaine.

ESC7 — Contrôle d'accès vulnérable sur l'autorité de certification

ESC7 vit sur le descripteur de sécurité propre de l'objet CA, pas sur des objets AD — et contrairement à ESC6, ce n'est pas un indicateur de registre. Les CA Windows prennent en charge la séparation des rôles via deux droits d'accès configurables dans l'onglet Sécurité de la console Autorité de certification : ManageCA (rôle d'administrateur de CA) et ManageCertificates (rôle de gestionnaire/officier de certificats).

Selon la documentation de SpecterOps, détenir ManageCA permet à un principal de modifier la configuration de la CA à l'échelle globale — y compris basculer l'indicateur EDITF_ATTRIBUTESUBJECTALTNAME2 dont dépend ESC6, réactiver des templates vulnérables précédemment désactivés, et activer les conditions dont dépendent ESC11 et ESC16. Cela signifie qu'un attaquant qui ne détient que ManageCA — sans aucune erreur de configuration de template en vue — peut fabriquer des conditions ESC6 ou ESC11 à volonté. La documentation de SpecterOps décrit aussi un abus plus direct de ManageCA : demander un certificat depuis un template qui exige une approbation par un manager, laisser la demande échouer et rester en attente, puis utiliser ManageCA conjointement avec ManageCertificates pour forcer l'émission de cette demande en attente, indépendamment de l'exigence d'approbation censée la bloquer.

ManageCertificates seul permet à un principal de gérer et d'émettre des certificats en attente d'approbation. Selon la documentation de SpecterOps, cela permet un contournement de type ESC1 via les politiques d'émission liées à des groupes : demander un certificat depuis un template soumis à approbation, utiliser ManageCertificates pour injecter un OID de politique d'émission lié à un groupe dans la demande en attente, puis l'émettre — obtenant un certificat dont la politique d'émission correspond à un groupe privilégié, sans jamais satisfaire le contrôle d'approbation par un manager que le template était censé imposer.

La chaîne d'attaque

Le motif commun aux quatre techniques : ESC2 et ESC3 abusent de ce qu'un template est autorisé à faire une fois qu'un certificat en sort ; ESC5 et ESC7 abusent de qui est autorisé à contrôler les templates et la CA en premier lieu. Cette seconde catégorie explique pourquoi corriger chaque template individuel signalé par ESC1, ESC2, ESC3, ESC4 ou ESC6 ne referme pas la porte — un attaquant disposant d'un accès ESC5 ou ESC7 peut simplement recréer la condition vulnérable une fois la revue terminée.

🚨 Danger : ESC3 et les variantes en écriture d'ESC5 aboutissent tous deux au même résultat qu'ESC1 — un certificat qui authentifie comme une identité cible, convertible en TGT Kerberos et utilisable pour usurper cette identité, y compris un Domain Admin. L'escalade vers l'ACL d'un objet PKI démarre fréquemment comme une reconnaissance ordinaire d'abus ACL et DCSync plutôt que comme une technique spécifique à AD CS.

Détection

Remédiation

1. Supprimer les templates d'authentification Any Purpose et sans EKU (ESC2). Restreindre la liste EKU de chaque template publié à ce dont il a réellement besoin. Si un template doit vraiment rester réutilisable pour plusieurs usages, conserver des exigences d'approbation par un manager et de signature autorisée plutôt que de s'appuyer uniquement sur un EKU restreint.
2. Restreindre les templates agent d'enrôlement (ESC3). Configurer Restricted Enrollment Agent sur chaque CA en édition Enterprise qui émet des certificats Certificate Request Agent, en limitant chaque agent d'enrôlement à des templates spécifiques et des groupes de sécurité cibles spécifiques plutôt que de le laisser sans restriction. Là où Restricted Enrollment Agent n'est pas disponible, limiter qui peut s'enrôler dans le template agent d'enrôlement au groupe le plus restreint et le mieux géré possible.
3. Durcir les ACL des objets PKI (ESC5). Revoir les ACL sur les conteneurs Certificate Templates, Certification Authorities et Enrollment Services, sur l'objet NTAuthCertificates, et sur l'objet ordinateur AD de chaque serveur CA. Retirer GenericAll, WriteDacl, WriteOwner, et les droits équivalents à tout principal en dehors du groupe d'administration PKI Tier 0 prévu.
4. Resserrer la séparation des rôles de la CA (ESC7). Revoir l'onglet Sécurité de chaque CA et confirmer que Manage CA et Issue and Manage Certificates ne sont détenus que par les comptes qui en ont besoin. Traiter les deux comme des privilèges équivalents à Tier 0, pas comme des réglages par défaut d'administration IT générale — voir Durcissement Active Directory : quoi verrouiller d'abord et comment le valider pour comprendre comment ceci s'intègre dans une revue de privilèges Tier 0 plus large.
5. Revoir le traitement des demandes en attente. Confirmer que forcer l'émission d'une demande de certificat refusée ou en attente n'est pas systématiquement accessible aux mêmes principals qui peuvent aussi demander des certificats — cette combinaison est exactement ce qui rend possible le contournement d'approbation ESC7.
6. Retester après chaque changement. Les restrictions d'agent d'enrôlement et les changements d'ACL PKI peuvent casser des workflows légitimes d'émission de cartes à puce et d'administration déléguée. Valider avec un groupe pilote représentatif avant d'appliquer les changements à l'échelle de la CA, et maintenir la revue du journal d'audit de la CA de la section détection active pendant le déploiement.

Où cela s'inscrit : ANSSI R36, R37, et le reste du corpus ADCS

Le guide de l'ANSSI sur l'administration sécurisée d'Active Directory (ANSSI-PA-099) traite le risque PKI sur Tier 0 comme sa propre recommandation numérotée, indépendante de l'hygiène générale des certificats. R36 indique que dès lors qu'une PKI peut générer des certificats utilisables pour l'authentification vers Tier 0, cette PKI « ne doit pas offrir de chemins d'attaque vers le Tier 0 depuis des niveaux de confiance inférieurs, que ce soit par l'administration des systèmes qui l'hébergent, par la délégation de droits sur les capacités de génération de certificats, ou par les templates de certificats publiés » — une description quasi exacte de ce qu'abusent ESC5 et ESC7 (le contrôle délégué sur la capacité de génération de certificats, c'est-à-dire la CA et ses objets PKI) et de ce qu'abuse ESC2 (des templates publiés qui accordent plus de capacité que prévu). Le même guide mentionne séparément R37, qui traite de la robustesse cryptographique des certificats (interdiction des signatures DSA, exigence de hachages SHA-2/SHA-3, et tailles minimales de clé RSA) — une préoccupation réelle mais distincte des erreurs de configuration d'EKU et d'ACL couvertes ici, à auditer en complément de ces quatre techniques plutôt qu'à leur place.

Cet article ne reformule volontairement pas ESC1, ESC4, ESC6 ou ESC8 — voir Chemins attaque ADCS : comment des erreurs de certificats deviennent des chemins d'escalade Active Directory pour ceux-ci — ni ESC9, ESC10, ESC11, qui relèvent de la couche de mapping de certificats et de chiffrement RPC couverte dans ADCS ESC9, ESC10, ESC11 et son article complémentaire sur le mappage de certificat faible. Une revue AD CS complète nécessite les trois articles, ainsi que la checklist Tier 0 plus large dans Audit de sécurité Active Directory : quoi vérifier d'abord et comment prouver la remediation, car aucune des onze techniques ne se substitue à une autre.

Comment EtcSec détecte cela

Les contrôles d'audit AD d'EtcSec correspondent directement à chaque technique couverte ici : ESC2_ANY_PURPOSE signale les templates capables d'authentification avec un EKU Any Purpose ou vide et sans contrôle d'approbation, ESC3_ENROLLMENT_AGENT signale les templates Certificate Request Agent et leurs cibles en aval non restreintes, ESC5_PKI_OBJECT_ACL revoit les ACL sur l'arborescence du conteneur Public Key Services, NTAuthCertificates, et les objets ordinateur des CA, et ESC7_CA_VULNERABLE_ACL revoit la séparation des rôles au niveau de la CA pour des octrois ManageCA et ManageCertificates trop larges. Les résultats des quatre techniques remontent dans PATH_CERTIFICATE_ESC lorsqu'ils forment un chemin actif vers Domain Admin, si bien qu'un signalement de template ou une entrée d'ACL est priorisé selon son accessibilité réelle — pas signalé isolément.

Références principales

• SpecterOps / Certify — Escalation Techniques Overview
• SpecterOps / Certify — ESC2: Misconfigured Any Purpose
• SpecterOps / Certify — ESC3: Misconfigured Certificate Request Agent
• SpecterOps / Certify — ESC5: Vulnerable PKI Object Access Control
• SpecterOps / Certify — ESC7: Vulnerable Certificate Authority Access Control
• Certified Pre-Owned: Abusing Active Directory Certificate Services
• Microsoft: AD CS Restricted Enrollment Agent
• Microsoft: [MS-WCCE] NTAuthCertificates Object
• ANSSI-PA-099 : Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory