ADCS ESC9, ESC10, ESC11 : escalade de certificats au-delà d'ESC1-ESC8

Qu'est-ce que l'escalade de certificats ADCS ESC9, ESC10, ESC11

L'escalade de certificats ADCS ESC9, ESC10, ESC11 désigne l'ensemble des techniques d'escalade de privilèges Active Directory Certificate Services (AD CS) publiées après la recherche originale « Certified Pre-Owned », qui a introduit ESC1 à ESC8. Là où les huit premiers chemins se concentrent sur les mauvaises configurations de modèles, les paramètres dangereux de l'AC et l'enrôlement web HTTP, ESC9, ESC10 et ESC11 ciblent la couche qui détermine si un certificat correspond réellement au bon compte : l'extension de sécurité intégrée au certificat, la configuration de mappage de certificats du contrôleur de domaine, et l'application du chiffrement sur l'interface RPC d'enrôlement de l'AC.

Ces trois techniques existent à cause du même changement sous-jacent : la mise à jour de Microsoft de mai 2022 (KB5014754) a introduit l'extension de sécurité szOID_NTDS_CA_SECURITY_EXT, qui intègre le SID du principal demandeur dans le certificat émis afin que le KDC puisse lier fortement ce certificat à un seul compte. ESC9, ESC10 et ESC11 sont trois façons différentes dont cette liaison peut échouer à protéger un environnement — l'une au niveau du modèle, l'une au niveau du contrôleur de domaine/Schannel, et l'une au niveau du transport RPC.

Comment ça fonctionne

ESC9 — Absence d'extension de sécurité

ESC9 existe lorsque le msPKI-Enrollment-Flag d'un modèle de certificat inclut le bit CT_FLAG_NO_SECURITY_EXTENSION (0x80000). La documentation Certify de SpecterOps décrit ce paramètre comme supprimant l'extension szOID_NTDS_CA_SECURITY_EXT sur tout certificat émis à partir de ce modèle. L'effet est que le processus de mappage de certificat se comporte comme si StrongCertificateBindingEnforcement était réglé sur 0, quelle que soit sa valeur réelle dans le registre du contrôleur de domaine, car il n'y a aucun SID dans le certificat à vérifier.

À lui seul, ce drapeau n'est pas exploitable. Il devient ESC9 lorsqu'il est combiné à une seconde condition que les attaquants recherchent déjà sur les modèles adjacents à ESC1-ESC8 : un principal peu privilégié disposant de GenericWrite (ou équivalent) sur un autre compte. Un attaquant disposant de GenericWrite sur un compte victime peut modifier le userPrincipalName de ce compte pour qu'il corresponde à une cible privilégiée (par exemple le sAMAccountName d'un administrateur), enrôler un certificat depuis le modèle marqué ESC9 en tant que compte victime, puis s'authentifier en tant que cible usurpée — car le certificat résultant ne porte aucune extension SID pour contredire l'UPN falsifié.

ESC10 — Mappage de certificat faible (à l'échelle du domaine)

ESC10 produit le même résultat pratique qu'ESC9 — une authentification qui se résout vers le mauvais compte — mais la mauvaise configuration réside dans le contrôleur de domaine ou dans Schannel, pas sur un seul modèle de certificat. SpecterOps et la recherche communautaire (dont le wiki Certify et des analyses ADCS indépendantes) décrivent deux variantes :

• Cas A — La valeur de registre CertificateMappingMethods de Schannel sur le contrôleur de domaine inclut le mappage UPN. Un attaquant capable d'écrire dans le userPrincipalName d'un compte victime (là encore via GenericWrite ou équivalent) le règle pour correspondre à un principal cible, puis s'authentifie via Schannel (authentification client TLS) avec n'importe quel certificat dont le sujet ou le SAN reflète l'UPN falsifié.
• Cas B — StrongCertificateBindingEnforcement sur le contrôleur de domaine est explicitement réglé sur 0 (mode Compatibilité) plutôt que sur la valeur par défaut appliquée, de sorte qu'une extension SID manquante ou non correspondante est acceptée plutôt que rejetée, pour chaque modèle et chaque principal — pas seulement un modèle marqué comme dans ESC9.

La différence opérationnelle clé par rapport à ESC9 : ESC10 n'est pas limité à un seul modèle de certificat, ce qui étend généralement le pool de comptes exploitables à l'ensemble du domaine.

ESC11 — Relais NTLM vers l'interface RPC de l'AC

ESC11 est le pendant côté transport RPC d'ESC8 (relais NTLM vers l'enrôlement web HTTP). Les autorités de certification exposent l'interface RPC ICertPassage (MS-ICPR) pour les demandes de certificat. Selon la documentation Certify de SpecterOps et des recherches indépendantes de Compass Security, le fait que cette interface applique ou non le chiffrement au niveau paquet est contrôlé par le drapeau d'interface IF_ENFORCEENCRYPTICERTREQUEST sur l'AC. Ce drapeau est activé par défaut mais est fréquemment désactivé pour rester compatible avec des clients plus anciens incapables de négocier RPC_C_AUTHN_LEVEL_PKT_PRIVACY.

Lorsque le drapeau est désactivé, un attaquant qui contraint une victime (par exemple un compte machine de contrôleur de domaine) à s'authentifier via NTLM peut relayer cette authentification vers l'interface RPC de l'AC — contournant les mêmes protections d'enrôlement web qu'ESC8 couvre, mais via RPC plutôt que HTTP, et indépendamment du fait que l'enrôlement web soit même installé.

La chaîne d'attaque

🚨 Danger : les trois techniques peuvent aboutir au même résultat qu'ESC1-ESC8 — un certificat utilisable pour l'authentification Kerberos PKINIT en tant qu'administrateur de domaine ou contrôleur de domaine. L'escalade via GenericWrite s'enchaîne directement avec Abus d'ACL et DCSync : les chemins silencieux vers Domain Admin. L'étape de relais d'ESC11 utilise les mêmes primitives de contrainte/relais couvertes dans Attaques par relais NTLM : détournement de l'authentification dans AD.

Détection

Remédiation

1. Retirer CT_FLAG_NO_SECURITY_EXTENSION des modèles (ESC9). Auditez le msPKI-Enrollment-Flag de chaque modèle de certificat. Tout modèle capable d'authentification portant ce drapeau devrait le voir retiré, sauf raison documentée et revue — et cette raison ne devrait pas inclure des droits d'enrôlement non privilégiés.
2. Faire passer les contrôleurs de domaine en Full Enforcement (ESC10, Cas B). Confirmez que StrongCertificateBindingEnforcement n'est pas figé à 0. Selon la chronologie du KB5014754 de Microsoft, les contrôleurs de domaine sans valeur de registre explicite sont passés en mode Full Enforcement dès la mise à jour de février 2025, et la clé de registre elle-même a cessé d'être prise en compte après la mise à jour de septembre 2025 — un 0 explicite laissé en place est donc une régression délibérée qui doit être identifiée et justifiée.
3. Désactiver les méthodes de mappage Schannel faibles (ESC10, Cas A). Passez en revue CertificateMappingMethods sur chaque contrôleur de domaine et tout serveur terminant une authentification TLS par certificat client. Les méthodes faibles (Sujet/Émetteur, Émetteur seul, UPN) devraient rester désactivées ; seules les méthodes fortes (S4U2Self, S4U2Self explicite) devraient être autorisées, sauf application héritée spécifique et documentée l'exigeant.
4. Appliquer le chiffrement RPC sur chaque AC (ESC11). Exécutez certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST sur chaque AC, puis redémarrez le service Services de certificats (net stop certsvc && net start certsvc). Validez ensuite avec certutil -config "<CA>" -getreg CA\InterfaceFlags et confirmez la présence de 0x200.
5. Fermer l'exposition GenericWrite sous-jacente. ESC9 et ESC10 Cas A nécessitent tous deux qu'un attaquant dispose déjà d'un accès en écriture au userPrincipalName d'un compte victime. Passez en revue les ACL à la recherche de droits GenericWrite, GenericAll, WriteProperty, ou équivalents à Validated-SPN trop larges sur les objets utilisateur, en particulier depuis des groupes de helpdesk ou de provisioning, dans la même passe de remédiation.
6. Retester après chaque changement. Les changements de mappage de certificat et de chiffrement RPC peuvent casser des clients hérités (anciennes versions de Windows, clients RPC non-Windows, middleware de carte à puce ancien). Déployez les changements via un groupe pilote représentatif avant d'appliquer à l'échelle du domaine, et gardez la revue des événements KDC/Schannel de la section détection active pendant le déploiement pour confirmer qu'aucune authentification légitime ne commence à échouer.

✅ Action rapide : si le temps ne permet qu'une seule action aujourd'hui, exécutez la vérification certutil -config "<CA>" -getreg CA\InterfaceFlags sur chaque AC. ESC11 ne nécessite aucun privilège d'annuaire pour être exploité — seulement un accès réseau et une primitive de contrainte — ce qui en fait le chemin le plus accessible des trois.

Comment EtcSec détecte cette exposition

Les contrôles d'audit AD d'EtcSec correspondent directement à chaque technique : ESC9_NO_SECURITY_EXTENSION signale les modèles de certificat portant CT_FLAG_NO_SECURITY_EXTENSION sur un modèle capable d'authentification, ESC10_WEAK_CERTIFICATE_MAPPING examine la configuration de mappage de certificat du contrôleur de domaine et de Schannel à la recherche de paramètres en mode compatibilité, et ESC11_ICERT_REQUEST_ENFORCEMENT vérifie l'application du chiffrement RPC sur chaque AC découverte. Comme ESC9 et ESC10 Cas A dépendent tous deux d'un prérequis de type GenericWrite, EtcSec corrèle également ces constats avec la surface d'exposition ACL plus large, afin qu'un drapeau de modèle ou un paramètre de registre soit priorisé selon qu'un attaquant dispose réellement d'un chemin d'abus — et non signalé de façon isolée.

Si vous construisez une revue AD CS complète plutôt que de vérifier une technique à la fois, associez cet article à Comment auditer la sécurité Active Directory : que revoir en premier et comment prouver la remédiation pour la checklist Tier 0 complète dans laquelle s'inscrivent ces chemins.

Références principales

• SpecterOps / Certify — ESC9 : No Security Extension
• SpecterOps / Certify — ESC10 : Weak Certificate Mapping
• SpecterOps / Certify — ESC11 : NTLM Relay to AD CS RPC Interfaces
• Microsoft Support : KB5014754 — Certificate-based authentication changes on Windows domain controllers
• Microsoft Defender for Identity : Enforce encryption for RPC certificate enrollment interface (ESC11)
• Compass Security : Relaying to AD Certificate Services over RPC