En juin 2021, Will Schroeder et Lee Christensen de SpecterOps publient Certified Pre-Owned. Le rapport documente systématiquement comment Active Directory Certificate Services peut servir de vecteur d'élévation de privilèges et de persistance dans un domaine. Ils classifient ces chemins d'attaque de ESC1 à ESC8.
Depuis, la liste s'est allongée. ESC9 à ESC14 ont été documentés par la communauté sécurité. Chaque nouvelle découverte confirme le même problème fondamental : ADCS a été conçu pour la commodité, pas pour des conditions adverses.
Cet article propose un panorama technique de chaque classe ESC connue. Non pas comme un guide de pentest, mais comme une analyse architecturale de pourquoi ces vulnérabilités existent et ce qu'elles révèlent sur le modèle de sécurité d'ADCS.
ESC1 : Templates de certificats mal configurés
La classe ESC la plus exploitée. Un template de certificat autorise le demandeur à spécifier un Subject Alternative Name (SAN). Si des utilisateurs non privilégiés peuvent s'enrôler, ils peuvent demander un certificat pour n'importe quel utilisateur, y compris les Domain Admins.
Trois conditions doivent être réunies simultanément : le template autorise la spécification du SAN, l'enrollment est permis pour des utilisateurs non privilégiés, et l'Extended Key Usage inclut Client Authentication ou Smart Card Logon.
La cause racine n'est pas un bug. C'est un choix de design. ADCS autorise la configuration flexible du SAN pour supporter des scénarios légitimes. Mais les permissions par défaut restreignent rarement qui peut utiliser cette flexibilité.
ESC2 : Templates mal configurés (Any Purpose)
Similaire à ESC1, mais l'EKU du template est défini sur "Any Purpose" ou ne contient aucun EKU. Un certificat sans restriction d'EKU peut être utilisé pour l'authentification client, la signature de code, ou tout autre usage.
Le résultat est identique : un utilisateur non privilégié obtient un certificat qui donne un accès à l'échelle du domaine.
ESC3 : Abus d'Enrollment Agent
ADCS supporte un modèle de délégation où les Enrollment Agents peuvent demander des certificats au nom d'autres utilisateurs. Si le template Enrollment Agent est accessible aux utilisateurs non privilégiés, un attaquant s'enrôle comme agent, puis demande des certificats pour des comptes privilégiés.
C'est une attaque en deux étapes qui exploite un mécanisme de délégation légitime. Le modèle de permissions rend la restriction difficile sans casser les workflows existants.
ESC4 : ACLs vulnérables sur les templates
L'objet template de certificat possède sa propre Access Control List dans Active Directory. Si un utilisateur non privilégié a un accès en écriture sur le template (WriteProperty, WriteDacl ou WriteOwner), il peut modifier le template pour activer les conditions ESC1, demander le certificat, puis annuler les modifications.
La fenêtre d'attaque peut être de quelques secondes. L'audit des modifications de templates n'est pas activé par défaut.
ESC5 : ACLs vulnérables sur les objets PKI
Extension de ESC4 au-delà des templates. Tout objet lié à la PKI dans Active Directory avec des ACLs faibles devient une cible : l'objet CA lui-même, l'objet NTAuthCertificates, le conteneur PKI, ou le conteneur Enrollment Services.
Le contrôle de ces objets peut mener à l'ajout de CA frauduleuses dans le store NTAuth, ce qui signifie que le domaine fait confiance aux certificats émis par l'attaquant.
ESC6 : EDITF_ATTRIBUTESUBJECTALTNAME2
Un flag sur la configuration de la CA elle-même. Lorsque ce flag est activé, la CA autorise le demandeur à spécifier un SAN dans n'importe quelle demande de certificat, indépendamment de ce que dit le template.
Cela transforme effectivement chaque template en template vulnérable à ESC1. Le flag a historiquement été activé par de nombreux administrateurs parce que la documentation Microsoft le suggérait pour certains cas d'usage. Une seule valeur de registre compromet l'ensemble de la CA.
ESC7 : ACLs vulnérables sur la CA
Si un utilisateur possède les permissions ManageCA ou ManageCertificates sur l'autorité de certification, il peut modifier la configuration de la CA (activer EDITF_ATTRIBUTESUBJECTALTNAME2), approuver les demandes en attente, ou émettre des certificats directement.
Combiné avec ESC6, l'accès ManageCA fournit un chemin direct vers la compromission du domaine.
ESC8 : NTLM Relay vers les endpoints HTTP d'AD CS
ADCS expose des endpoints HTTP d'enrollment (Certificate Enrollment Web Service, Certificate Enrollment Policy Web Service). Ces endpoints acceptent souvent l'authentification NTLM sans Extended Protection for Authentication (EPA).
Un attaquant qui peut forcer l'authentification NTLM depuis un contrôleur de domaine (via PetitPotam, PrinterBug, ou des techniques similaires) redirige l'authentification vers l'endpoint HTTP d'ADCS et obtient un certificat pour le contrôleur de domaine. Ce certificat donne une compromission complète du domaine.
ESC8 est particulièrement dévastateur parce qu'il combine deux faiblesses répandues : le relay NTLM et les endpoints HTTP ADCS. Il ne nécessite aucun privilège préalable sur l'infrastructure ADCS.
ESC9 : Absence de Security Extension sur les certificats
Introduit dans les recherches postérieures au rapport original. Quand l'extension szOID_NTDS_CA_SECURITY_EXT n'est pas imposée, le mapping entre un certificat et un compte Active Directory repose uniquement sur les champs SAN ou Subject. Un attaquant avec un accès en écriture sur le userPrincipalName d'un autre utilisateur peut obtenir un certificat, puis modifier le UPN.
Le certificat reste valide et se mappe sur le compte cible.
ESC10 : Mappings de certificats faibles
Lié à ESC9. Si le contrôleur de domaine utilise un mapping faible pour l'authentification par certificat (clé de registre StrongCertificateBindingEnforcement à 0 ou 1), un attaquant peut exploiter la logique de mapping pour s'authentifier comme un autre utilisateur.
Microsoft a traité ce problème progressivement via KB5014754, mais de nombreux environnements retardent l'application en raison de préoccupations de compatibilité.
ESC11 : NTLM Relay vers ICPR (RPC)
Similaire à ESC8, mais ciblant l'interface d'enrollment RPC (ICertPassage Remote Protocol) plutôt que HTTP. Si la CA n'impose pas le Packet Privacy sur l'interface RPC, les attaques par relay NTLM sont possibles.
Cette variante est moins connue que ESC8 mais affecte les environnements qui ont désactivé les endpoints HTTP en pensant être protégés contre les attaques par relay.
ESC12 : Accès shell au serveur CA
Lorsque la clé privée de la CA est stockée de manière accessible aux administrateurs ayant un accès shell sur le serveur CA, le matériel cryptographique peut être extrait. Ce n'est pas strictement une vulnérabilité du protocole ADCS, mais un risque opérationnel inhérent à la façon dont de nombreuses organisations déploient leurs CA.
Une clé privée de CA compromise signifie que chaque certificat jamais émis par cette CA doit être considéré comme non fiable.
ESC13 : Abus de OID Group Link
Documenté en 2024. ADCS permet de lier un OID de politique d'émission à un groupe de sécurité. Si un utilisateur peut obtenir un certificat avec cette politique d'émission, le certificat lui accorde effectivement les permissions du groupe lié.
Un attaquant qui peut s'enrôler dans un template avec un OID policy lié obtient l'appartenance au groupe sans en être membre direct. Cela contourne les contrôles d'accès traditionnels basés sur les groupes.
Le pattern : du design, pas des bugs
Chaque classe ESC partage des caractéristiques communes.
Elles exploitent des fonctionnalités qui marchent comme prévu. Les templates, les enrollment agents, les ACLs, les flags CA, l'authentification NTLM sont tous des mécanismes ADCS légitimes.
Elles sont difficiles à détecter. La plupart des attaques laissent des traces minimales dans les configurations d'audit par défaut. Les modifications de templates peuvent être annulées. Les certificats sont valides pendant toute leur durée de vie.
Elles sont difficiles à prévenir sans réduire les fonctionnalités. Restreindre les permissions des templates, désactiver NTLM, imposer un strong certificate mapping : tout cela nécessite un effort opérationnel significatif et peut casser les workflows existants.
Appliquer des correctifs traite des vecteurs d'attaque spécifiques mais ne change pas l'architecture. ESC1 existait depuis le jour où ADCS a été publié. ESC13 a été documenté plus de vingt ans plus tard. La courbe de découverte ne s'aplatit pas.
Ce que cela signifie pour la stratégie PKI
La série ESC démontre que la sécurité d'ADCS est fondamentalement limitée par son architecture. L'intégration profonde avec Active Directory signifie que chaque erreur de configuration des permissions AD est potentiellement une vulnérabilité PKI. Les configurations par défaut privilégient l'utilisabilité à la sécurité. La surface d'attaque croît avec chaque template, chaque endpoint d'enrollment, et chaque relation de confiance CA.
Pour les organisations qui utilisent ADCS, les priorités immédiates sont claires : auditer les permissions des templates, désactiver EDITF_ATTRIBUTESUBJECTALTNAME2, imposer le strong certificate mapping, restreindre les permissions administratives de la CA, et supprimer les endpoints HTTP inutiles.
Mais ce sont des mitigations, pas des solutions. L'architecture sous-jacente reste.
La question stratégique est de savoir si ADCS doit continuer à être le composant PKI central, ou si les nouveaux besoins en certificats doivent être traités par une infrastructure conçue avec ces modèles de menaces en tête. Une couche de gouvernance qui offre une visibilité sur toutes les autorités de certification, impose des politiques cohérentes et détecte les émissions anormales traite le risque systémique que le durcissement CA par CA ne peut pas couvrir.
