ESC1 à ESC8 et les attaques golden certificate montrent pourquoi la configuration ADCS et une clé privée CA unique restent des risques structurels. Comment la signature MPC à seuil et la révocation temps réel changent le modèle.
Active Directory Certificate Services (ADCS) reste la PKI d'entreprise par défaut dans de nombreux estates Windows. La recherche publique a montré que plusieurs de ses chemins de privilège les plus graves ne sont pas « des CVE non patchées en attente du Patch Tuesday ». Ce sont des outcomes de configuration et d'architecture : templates de certificats qui font confiance au requester, chemins d'enrolment qui acceptent le NTLM relay, et une clé privée CA qui vit en un seul endroit.
Cette page résume les problèmes structurels, crédite la recherche publique qui les a documentés, et décrit comment un autre modèle de signature CA (MPC à seuil, enforcement cryptographique du SAN, pas d'enrolment NTLM, révocation temps réel) traite les modes de défaillance que le patching seul ne peut pas résoudre.
Des chercheurs de SpecterOps ont documenté une famille de techniques d'escalade de privilèges ADCS couramment étiquetées ESC1 à ESC8. Les détails varient selon le template et le chemin d'enrolment ; le pattern, non :
| Pattern | Ce qui casse |
|---|---|
| ESC1 | Des templates mal configurés permettent à un utilisateur authentifié de demander un certificat qui impersonne efficacement un autre principal (par exemple en contrôlant le subject alternative name). Le privilège domaine suit alors le certificat, pas le compte d'origine. |
| ESC8 | L'enrolment web qui accepte NTLM peut être abusé via relay : un attaquant coerce l'authentification et enrol contre la CA sous l'identité relayée. |
| ESC2–ESC7 (famille) | Mauvaises configurations liées de templates, enrolment agents et permissions CA qui convertissent ADCS d'un service d'identité en chemin d'escalade domain-admin. |
Le point architectural important : plusieurs de ces chemins réussissent parce qu'ADCS fait confiance à des flags de configuration et à des ACL Active Directory que les opérateurs audient rarement de bout en bout. Une organisation peut être « fully patched » et rester exposée.
Des CVE publiées ont traité au fil du temps des faiblesses spécifiques d'ADCS et d'enrolment associées (par exemple des issues suivies sous des identifiants tels que CVE-2022-26923 et des advisories ADCS ultérieurs). Traitez les IDs CVE comme la preuve que vendors et chercheurs reconnaissent la classe de problème ; ne traitez pas un dashboard de patches vert comme la preuve que le risque template de classe ESC a disparu.
Le crédit pour le mapping public systématique d'ESC1–ESC8 appartient aux publications de recherche ADCS de SpecterOps. Cette page ne liste pas d'outillage offensif ; le dossier de recherche suffit à justifier une conversation de design.
Si un attaquant obtient la clé privée CA, il peut forger des certificats pour des sujets arbitraires aussi longtemps que les relying parties font confiance à cette CA. C'est le scénario golden certificate : forgery indéfinie jusqu'à ce que chaque ancre de confiance qui embarque la CA soit remplacée.
Dans un déploiement ADCS classique, la clé privée CA siège typiquement dans une partition HSM ou un key store logiciel. Cette concentration est exactement la cible à haute valeur. Patcher les bugs d'enrolment ne change pas le fait qu'un seul vol réussi de la clé CA termine l'histoire de confiance pour cette hiérarchie.
Les issues de classe ESC1 à ESC4 découlent largement du design des templates et des permissions, pas d'un seul bug de corruption mémoire que l'on ferme avec une cumulative update. Tant que :
la surface d'escalade reste un problème de configuration et de protocole. Les équipes sécurité qui ne suivent que les CVE sous-estiment le risque résiduel.
Une PKI conçue pour retirer ces modes de défaillance ne ressemble pas à « ADCS plus de meilleurs guides de hardening » :
Rien de cela ne remplace l'inventaire, le monitoring ou la discipline du cycle de vie des certificats. Cela change l'architecture de confiance en dessous.
Le produit PKI et certificats de DuoKey combine le cycle de vie des certificats (émettre, renouveler, retirer, auditer) avec une protection de clés adossée au MPC, pour que le matériel de signature CA et à haute valeur ne soit pas un secret d'une seule appliance. Le même plan de contrôle qui gouverne les certificats s'articule aussi avec les identités agentiques pour les principals non humains qui ont besoin de certificats machine sans hériter de la dette de templates ADCS.
Forme pratique de programme :
Q : Peut-on garder ADCS si on harden les templates ?
Vous pouvez réduire le risque. Les issues de classe ESC montrent que la revue des templates et ACL est obligatoire si ADCS reste. Le hardening ne vous donne pas des clés CA à seuil et ne retire pas à lui seul la concentration golden certificate.
Q : Est-ce uniquement un problème Windows ?
ADCS est le cas d'étude d'entreprise courant à cause du couplage Active Directory. Toute CA qui stocke une clé privée monolithique et fait confiance à une liaison d'identité d'enrolment faible a les mêmes risques structurels.
Q : Pourquoi ne pas nommer les outils d'exploit ici ?
Les identifiants CVE publics et la recherche SpecterOps suffisent à établir le problème sur un site produit public. Les détails d'outillage appartiennent à un atelier technique privé, pas au copy marketing.
Les défaillances ADCS qui comptent le plus pour un compromis de domaine sont souvent des défaillances de configuration et de custody de clé : impersonation de style ESC1 via templates, relay de style ESC8 contre l'enrolment NTLM, et une clé CA qui devient un golden certificate une fois volée. Le patching aide là où une CVE existe. Il ne réécrit pas la confiance des templates ni ne découpe une clé CA monolithique. Signature MPC à seuil, liaison SAN cryptographique, enrolment sans NTLM et révocation temps réel sont les réponses architecturales.
Écrit par
Nagib Aouini
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
