Abus AD CS (ESC1/ESC8) & Forgerie Admin — Akuity SOC

Dans l'écosystème Active Directory (AD), les services de certificats Active Directory Certificate Services (AD CS) constituent l'infrastructure à clé publique (PKI) critique de l'entreprise. Pourtant, ils représentent également l'un des vecteurs d'élévation de privilèges les plus dévastateurs répertoriés par le framework MITRE ATT&CK sous la technique T1649. À travers les vulnérabilités structurelles ESC1 et ESC8 popularisées par SpecterOps, un attaquant disposant d'un compte utilisateur standard non privilégié peut forger un certificat d'authentification client et obtenir instantanément les droits de Domain Admin.

Anatomie des vecteurs ESC1 et ESC8

L'exploitation de ces faiblesses repose sur des mécanismes distincts mais convergeant vers le même résultat : l'obtention d'un Ticket Granting Ticket (TGT) Kerberos pour un compte privilégié via l'extension PKINIT (Public Key Cryptography for Initial Authentication).

• ESC1 (Modèles mal configurés) : Cette vulnérabilité survient lorsqu'un modèle de certificat (Certificate Template) combine des droits d'enrôlement ouverts aux utilisateurs authentifiés, le drapeau CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (permettant au demandeur de spécifier un Subject Alternative Name arbitraire), et un usage de clé autorisant l'authentification client (EKU Client Authentication ou Smart Card Logon). L'attaquant sollicite un certificat en usurpant le SAN du compte Administrator ou d'un membre des Domain Admins.
• ESC8 (Relais NTLM HTTP vers AD CS Web Enrollment) : Le composant web d'enrôlement AD CS (généralement exposé sous http://<CA_SERVER>/certsrv/) ne requiert souvent ni signature SMB/HTTP ni protection de liaison de canal (EPA - Extended Protection for Authentication). Un attaquant contraint un contrôleur de domaine ou un serveur critique à s'authentifier contre une machine contrôlée (via MS-RPRN PetitPotam ou DFSCoerce), puis relaie ce flux NTLM vers l'interface HTTP de l'AD CS pour générer un certificat machine à privilèges élevés.

L'angle mort de la détection native

Une fois le certificat X.509 délivré, l'attaquant initie une requête Kerberos AS-REQ contenant l'enveloppe chiffrée PKINIT. Pour un Active Directory traditionnel, cette authentification apparaît comme strictement légitime : un code d'événement d'ouverture de session 4624 ou Kerberos 4768 sans corrélation directe avec le processus d'enrôlement qui a précédé. Sans surveillance continue de la télémétrie fournie par Defender for Identity et sans corrélation fine avec les attributs du certificat, ces usurpations passent inaperçues au milieu du trafic PKINIT légitime (postes PAW, cartes à puce).

Détection KQL dans Microsoft Defender Advanced Hunting

Pour traquer l'utilisation de certificats frauduleux par des comptes sensibles ou des comptes machines anormaux n'émanant pas de postes d'administration dédiés (PAW), déployez la requête Advanced Hunting (KQL) suivante :

IdentityLogonEvents
| where Protocol == "Kerberos" and ActionType == "LogonSuccess"
| extend ExtFields = todynamic(AdditionalFields)
| where tobool(ExtFields.IsCertBasedAuth) == true
| extend CertThumbprint = tostring(ExtFields.CertThumbprint),
         CertIssuer = tostring(ExtFields.CertIssuer),
         SubjectName = tostring(ExtFields.CertSubjectName)
| where AccountName in~ ("Administrator", "krbtgt") 
     or AccountName endswith "$"
| lookup kind=leftouter (IdentityInfo | summarize AdminGroups = make_set(GroupMembership) by AccountName = AccountUpn) on AccountName
| where AdminGroups has_any ("Domain Admins", "Enterprise Admins") or AccountName endswith "$"
| where not(IPAddress in ("127.0.0.1", "::1") or DeviceName endswith ".paw.domain.local")
| project Timestamp, AccountName, DeviceName, IPAddress, CertThumbprint, CertIssuer, SubjectName, AdminGroups

Remédiation SOAR orchestrée par Akuity SOC

L'intervention sur une compromission d'identité basée sur certificat exige une précision chirurgicale pour stopper l'hémorragie sans interrompre l'ensemble des services d'infrastructure :

• Résolution de l'opacité X.509 : L'assistant IA in-app d'Akuity SOC décode les attributs du certificat et les extensions PKINIT en moins de 2 secondes directement dans le ticket d'incident, évitant tout copier-coller vers des décodeurs web tiers (zéro fuite sur CyberChef).
• Riposte SOAR 1-clic : Déclenchement instantané des commandes confirmUserCompromised() et revokeSessions() sous Microsoft Entra ID et Active Directory pour expulser l'attaquant du domaine, combiné à isolateDevice() via Defender for Endpoint sur la machine source du relais NTLM depuis l'inventaire des preuves.
• Gouvernance Zero-Trust : Chaque action de confinement SOAR requiert une validation forte MFA AAL2 et consigne une entrée immuable dans le journal d'audit certifié conforme aux exigences NIS 2 et SOC 2 Type II.

FAQ Technique

Quelle est la différence fondamentale entre ESC1 et ESC8 ?

ESC1 est une vulnérabilité liée à une mauvaise configuration d'un modèle de certificat autorisant les utilisateurs ordinaires à spécifier un SAN arbitraire. ESC8 est une attaque par relais NTLM ciblant l'interface d'enrôlement HTTP d'AD CS non protégée par EPA, permettant de relayer le compte d'un contrôleur de domaine pour forger son identité sans exploiter de modèle mal configuré.

Comment remédier immédiatement au risque ESC8 sur l'infrastructure ?

Désactivez complètement le service d'enrôlement web AD CS (rôle IIS certsrv) s'il n'est pas indispensable. Si son utilisation est requise, activez impérativement la protection de liaison de canal (EPA - Extended Protection for Authentication) et le flag Negotiate:SecuritySupportProvider sur IIS, tout en supprimant l'authentification NTLM au profit de Kerberos exclusivement.