Chemins attaque ADCS expliqués

Chemins attaque ADCS : qu’est-ce qu’un vrai chemin ?

Si vous cherchez la formule exacte chemins attaque adcs et surtout une explication pratique, il faut partir de la chaîne d’abus plutôt que du simple label. Un chemin d’attaque AD CS n’est pas seulement un template faible. C’est la combinaison de règles d’émission, de droits d’enrollment, de contrôle sur la configuration du template ou de la CA, d’endpoints d’enrollment accessibles, et de règles d’authentification par certificat qui permet à une identité peu privilégiée de devenir plus privilégiée ou de rouvrir ce chemin plus tard.

C’est pour cela qu’une revue AD CS ne peut pas s’arrêter à une capture d’écran dans Certificate Templates. Il faut répondre ensemble à cinq questions :

Quelles Enterprise CAs existent dans la forêt ?
Quels templates sont publiés et utilisables pour l’authentification ?
Qui peut enroll, auto-enroll, ou modifier ces templates ?
Quels réglages globaux de la CA élargissent l’abus du sujet ou du SAN ?
Quels endpoints d’enrollment et quels chemins d’authentification rendent ces certificats réellement utilisables en production ?

Dans la recherche Certified Pre-Owned de SpecterOps, les labels ESC nomment des familles d’abus récurrentes. Dans une vraie revue, ce sont des chemins d’attaque parce qu’ils relient la configuration PKI à une escalade d’identité.

Pourquoi les chemins d’attaque ADCS comptent encore dans Active Directory

Microsoft décrit AD CS comme le rôle Windows Server qui émet et gère des certificats PKI pour l’authentification, le chiffrement, le smart card sign-in, TLS, le VPN et d’autres usages de sécurité. Ce même rôle devient une surface d’identité à fort impact lorsque les règles d’émission de certificats et les règles d’authentification par certificat dérivent du moindre privilège.

Les chemins AD CS comptent parce qu’ils ne ressemblent pas tous à un abus admin classique. Certains chemins permettent à un attaquant de demander un certificat qui authentifie comme une autre identité. D’autres lui permettent de modifier d’abord le plan de contrôle, puis de créer ensuite les conditions dangereuses sur le template. D’autres encore s’appuient sur un relais d’authentification vers des endpoints d’enrollment au lieu de modifier directement les paramètres du template. Et certains deviennent une étape dans des chaînes d’escalade plus larges avec les chemins d’attaque Active Directory ou l’abus ACL et DCSync, au lieu d’agir seuls.

Une deuxième raison tient aux angles morts opérationnels. Les équipes sécurité surveillent souvent mieux les resets de mot de passe, les erreurs critiques de mots de passe AD ou la délégation Kerberos que l’émission de certificats. Si l’audit de la CA, la visibilité sur les changements de templates ou les baselines d’authentification par certificat sont faibles, un chemin PKI vulnérable peut rester actif longtemps après l’examen d’autres voies d’escalade.

Pack minimal de preuves

Preuve	Pourquoi c’est important
Inventaire des Enterprise CAs	Confirme quelles CAs et quels services de rôle existent réellement dans la forêt
Templates publiés	Un template non publié ne peut pas être demandé via cette CA
Droits d’enrollment et d’auto-enrollment	Montre si des identités peu privilégiées peuvent obtenir des certificats
ACL des templates	Détermine qui peut altérer le template lui-même
Contrôles de sujet et de SAN	Identifie si les demandeurs peuvent fournir des valeurs d’identité dangereuses
Flags d’édition de la CA	Révèle des réglages globaux comme `EDITF_ATTRIBUTESUBJECTALTNAME2`
État web enrollment, HTTPS et EPA	Détermine si des endpoints relayables restent exposés
Télémétrie d’émission et d’authentification par certificat	Prouve si la supervision voit réellement les demandes, l’émission et l’authentification par certificat

Abus de modèles : ESC1 et les templates d’authentification publiés

ESC1 est l’exemple le plus clair d’un chemin d’abus de template. Microsoft Defender for Identity décrit la condition dangereuse ainsi : si un certificate template a Supply in the request activé et que le certificat est aussi valable pour l’authentification, des attaquants peuvent potentiellement enroll un certificat valable pour des utilisateurs arbitraires.

En pratique, un chemin ESC1 repose souvent sur les conditions suivantes :

le template est publié sur une CA
des identités peu privilégiées peuvent enroll dessus
le template autorise des valeurs de sujet ou de SAN fournies par le demandeur
le certificat peut être utilisé pour l’authentification, par exemple avec un EKU compatible client authentication
aucun contrôle plus fort, comme une manager approval ou des authorized signatures requises, ne bloque l’émission

Le point clé est que le flag seul ne suffit pas. Un template peut avoir un comportement de nommage risqué sans être un vrai chemin actif s’il n’est pas publié ou s’il est limité à une population d’enrollment strictement gouvernée. À l’inverse, un template d’authentification publié, avec un scope faible et des contrôles d’émission faibles, constitue déjà un chemin d’identité et pas seulement un problème de “template hygiene”.

C’est pour cela que la revue doit parler de templates d’authentification publiés, pas seulement de “templates vulnérables” dans l’abstrait. La publication détermine l’exploitabilité.

Chemins de plan de contrôle : ESC4 et ESC6

ESC4 et ESC6 sont des chemins de plan de contrôle. Ils sont dangereux parce qu’ils permettent à un attaquant de créer ou d’élargir un comportement d’émission exploitable, même si le template n’était pas initialement dans un état manifestement dangereux.

Avec ESC4, le problème est l’ACL de l’objet template. Les certificate templates sont des objets Active Directory, et leurs ACL contrôlent non seulement l’enrollment mais aussi qui peut modifier l’objet. Microsoft Defender for Identity signale explicitement le risque quand des groupes non privilégiés reçoivent des permissions qui permettent de changer les paramètres du template, par exemple Full Control ou WriteDACL. Autrement dit, l’attaquant n’a pas besoin que le template soit déjà ESC1 : il peut le faire dériver jusqu’à cet état.

Avec ESC6, le problème se déplace du template vers la CA. Si la CA a le flag EDITF_ATTRIBUTESUBJECTALTNAME2 activé, Microsoft Defender for Identity note que les utilisateurs peuvent spécifier des paramètres SAN dans les demandes de certificat et que cela affecte les templates, qu’ils aient ou non activé individuellement Supply in the request. Cela ne veut pas dire que chaque template devient automatiquement un bouton Domain Admin. Cela veut dire que la CA a élargi la surface de contrôle du sujet, et que n’importe quel template d’authentification publié dans un mauvais périmètre devient bien plus dangereux.

Ces deux chemins appartiennent à la même revue que les abus de permissions et de réplication, parce qu’il s’agit fondamentalement de problèmes de gouvernance sur le plan de contrôle PKI.

Chemins de relais : ESC8 et endpoints d’enrollment

ESC8 est différent de l’abus de template. Le chemin dépend d’endpoints d’enrollment relayables plutôt que des seuls flags du template.

Microsoft documente AD CS web enrollment et les certificate enrollment web services comme des surfaces d’enrollment HTTP. Le support Microsoft KB5005413 explique pourquoi c’est critique : si des attaquants peuvent relayer une authentification NTLM vers des endpoints AD CS vulnérables, ils peuvent obtenir des certificats ensuite exploitables pour continuer la compromission. L’évaluation ESC8 de Microsoft Defender for Identity resserre encore la condition en visant les endpoints IIS qui acceptent l’authentification NTLM sans HTTPS forcé ou sans Extended Protection for Authentication (EPA).

Cela fait d’ESC8 un problème d’endpoint et de protocole autant qu’un problème PKI. La revue doit donc inclure :

si CA Web Enrollment ou des enrollment web services associés sont installés
s’ils restent accessibles en HTTP
si EPA est effectivement imposé
si NTLM reste accepté là où Microsoft recommande de le désactiver ou de le restreindre

Ce chemin doit aussi être lu à côté du durcissement plus large contre le relais, comme les attaques NTLM relay et SMB signing désactivé, parce que l’endpoint certificat n’est souvent qu’une étape de la chaîne.

Où se situe weak certificate mapping

Weak certificate mapping compte, mais ce n’est pas le même problème que ESC1, ESC4, ESC6 ou ESC8.

Le cœur des chemins AD CS ci-dessus porte sur la manière dont un certificat est émis ou dont le chemin d’émission peut être rouvert. KB5014754 traite une autre couche : la façon dont les domain controllers évaluent les mappings d’authentification par certificat et migrent vers des liaisons plus fortes. C’est pour cela que weak mapping doit être traité comme un contrôle adjacent et relié au post dédié Weak Certificate Mapping in AD CS: Why Strong Binding Matters, et non fusionné ici comme s’il était déjà couvert par les quatre vuln tags ADCS de l’article.

En pratique, une revue AD CS solide doit distinguer deux questions :

un attaquant peut-il obtenir un certificat dangereux ?
si un certificat dangereux existe, comment les domain controllers vont-ils le rattacher à un compte ?

Les deux sujets sont liés, mais ce ne sont pas les mêmes chemins d’attaque.

Détection

La détection doit corréler émission, changements du plan de contrôle et télémétrie d’authentification. Aucun événement seul ne prouve un abus AD CS.

Télémétrie d’émission et de configuration de la CA

La guidance Microsoft sur l’advanced audit policy et sur le monitoring PKI place l’audit de la CA au centre. Au minimum, l’équipe sécurité doit savoir si la CA produit une télémétrie de demande et d’émission comme :

4886 pour les demandes de certificat
4887 pour l’émission de certificat
4882 pour les changements de permissions de sécurité Certificate Services
4890, 4891 ou 4892 pour des changements de gestion et de configuration dans Certificate Services

Ces événements sont utiles parce qu’ils montrent qu’une demande, une émission ou un changement de configuration a eu lieu. Ils ne prouvent pas à eux seuls qu’une demande était malveillante. Il faut encore corréler le demandeur, le template, le sujet visé et le flux métier attendu.

Télémétrie des changements d’objets Active Directory

Les templates sont des objets AD, donc 5136 compte quand l’audit est configuré et que les SACL pertinentes existent. Microsoft documente 5136 comme l’événement généré lorsqu’un objet Active Directory est modifié. Dans une revue AD CS, cela compte pour les changements d’ACL de template, les changements de publication de template, et d’autres modifications d’objet qui transforment un template normal en chemin d’attaque.

Télémétrie d’authentification

Côté domain controller, 4768 enregistre les demandes de TGT. Cela le rend utile pour corréler l’émission de certificats avec des patterns d’authentification ultérieurs, notamment pour des comptes ou des machines qui n’utilisent pas habituellement l’authentification par certificat. Mais 4768 n’est pas un détecteur AD CS. C’est une source de corrélation parmi d’autres, beaucoup plus utile lorsqu’elle est associée aux événements d’émission de la CA et à une baseline du comportement normal d’authentification par certificat.

Preuves d’exposition et de configuration

Toute la détection utile n’est pas pilotée par des événements. Certaines constatations AD CS essentielles sont des constats d’état :

un template d’authentification publié reste enrollable par des utilisateurs peu privilégiés
une ACL de template accorde encore des droits d’écriture dangereux
EDITF_ATTRIBUTESUBJECTALTNAME2 est toujours activé
un endpoint d’enrollment accepte encore des conditions relayables en HTTP ou sans EPA

C’est l’une des raisons pour lesquelles la supervision sécurité AD et les événements clés doit être couplée à une revue de configuration répétable, et pas traitée comme la réponse complète.

Remediation : priorités de correction

Le bon ordre de remédiation consiste à casser d’abord les chemins d’émission actifs, puis à durcir le plan de contrôle, puis à fermer les gaps d’endpoint, puis à valider séparément la posture de mapping.

1. Casser les chemins d’émission actifs

Commencez par dépublier ou restreindre les templates qui créent actuellement le chemin. Microsoft Defender for Identity recommande explicitement de retirer de la publication un template dangereux lorsqu’il ne devrait pas être demandable. Si un template doit rester disponible, réduisez d’abord son périmètre d’enrollment avant tout nettoyage cosmétique.

Ensuite, retirez ou limitez les comportements de sujet et de SAN fournis par le demandeur lorsqu’ils ne sont pas strictement requis. Pour les templates qui doivent continuer à supporter des usages spéciaux, appliquez des contrôles d’émission plus forts, comme approval ou authorized signatures, au lieu de laisser un enrollment large à faible privilège.

2. Supprimer les conditions d’abus du plan de contrôle

Pour ESC4, durcissez les ACL des templates pour que des groupes non privilégiés ne puissent plus modifier les permissions ou les paramètres. Pour ESC6, retirez EDITF_ATTRIBUTESUBJECTALTNAME2 sauf dépendance opérationnelle justifiée et revue.

Revoyez aussi qui peut gérer les réglages de la CA, publier des templates ou déléguer l’administration PKI. Une correction sur le template n’est pas durable si un autre opérateur ou groupe délégué peut rétablir silencieusement l’état dangereux plus tard.

3. Fermer les surfaces d’enrollment relayables

Pour ESC8, appliquez les mitigations Microsoft de KB5005413 :

désactiver les rôles web d’enrollment inutiles quand c’est possible
imposer HTTPS
activer EPA
réduire ou désactiver l’exposition NTLM sur les endpoints IIS d’enrollment là où Microsoft le recommande

Si le web enrollment n’est pas requis en production, le supprimer est souvent une meilleure réduction de risque que tenter de le conserver avec des contrôles partiels.

4. Traiter weak certificate mapping comme un durcissement adjacent

Ne confondez pas le durcissement des templates avec le durcissement du mapping. Si l’environnement dépend encore de mappings faibles, traitez KB5014754 comme un chantier distinct et validez explicitement ces changements côté domain controller.

Validation après remédiation

Ne signez pas une remédiation AD CS tant que vous ne pouvez pas montrer que le chemin d’attaque est réellement cassé depuis la même perspective que celle utilisée pour la revue de sécurité.

La validation doit inclure :

la preuve que les templates vulnérables ne sont plus publiés ou ne sont plus enrollables par des identités peu privilégiées
la preuve que les entrées ACL dangereuses ont disparu
la preuve que la CA n’expose plus EDITF_ATTRIBUTESUBJECTALTNAME2
la preuve que les endpoints d’enrollment ne restent plus exposés en HTTP ou sans EPA lorsque le chemin dépendait de ces conditions
la preuve que l’audit de la CA capture bien les demandes et les émissions de certificats
la preuve que la supervision côté AD voit les changements d’objets template là où c’est nécessaire
la preuve que les certificats déjà émis via des chemins risqués ont été revus et révoqués si nécessaire

C’est là qu’un workflow plus large comme l’audit de sécurité Active Directory devient utile. La validation AD CS ne porte pas sur un seul flag : elle doit prouver que le chemin d’émission, le plan de contrôle et le chemin de supervision ont tous changé en production.

Comment EtcSec cartographie les chemins d’attaque ADCS

EtcSec doit rester étroit ici : l’outil mesure les conditions qui créent le chemin.

Pour les chemins centraux, cela revient à cartographier des findings comme :

ESC1_VULNERABLE_TEMPLATE
ESC4_VULNERABLE_TEMPLATE_ACL
ESC6_EDITF_FLAG
ESC8_HTTP_ENROLLMENT

La même revue peut aussi faire ressortir des findings adjacents qui expliquent pourquoi le chemin existe ou comment il se chaîne plus loin :

ADCS_WEAK_PERMISSIONS
PATH_CERTIFICATE_ESC

Le point important n’est pas de promettre une détection magique. La valeur est dans la mesure répétée du scope des templates, des ACL, des flags de CA et de l’exposition des endpoints d’enrollment afin que la dérive PKI soit visible avant de redevenir une chaîne d’escalade.

Chemins attaque ADCS : comment des erreurs de certificats deviennent des chemins d’escalade Active Directory