Active Directory attack path · PKI · AD CS · ESC1 · MITRE ATT&CK T1649
Active Directory Certificate Services does more than encrypt and sign data: some certificates become authentication material in their own right, as powerful as a password or a Kerberos ticket.
ESC1 emerges when a certificate template combines several risky decisions: a low-privileged population can enroll, the request itself carries the identity the certificate will represent, and the resulting certificate can be used for authentication without sufficient checks before issuance.
The risk is therefore not a single wrong checkbox. It comes from the interaction between the certificate template, its enrollment rights, the usages it allows and the controls applied by the certificate authority.
The real question
Who can request which certificate, on behalf of which identity, and who validates that identity before issuance?
Active Directory Certificate Services provides the Microsoft building blocks for running a public key infrastructure in a Windows environment. The PKI is not a peripheral service: it produces cryptographic objects that the information system accepts as proof.
A certificate can represent a human, a machine or an application identity, and that representation is honoured by domain authentication mechanisms whenever the certificate carries the matching usages.
Certificates are typically used for
Issues and signs certificates, applying the issuance controls defined by the organisation.
Defines who may request which type of certificate, under which conditions and with which usages.
Becomes proof the system can act on, according to the usages it was granted.
ESC1 is not a complete attack path: it is a technique that fits into a path when the configuration allows it. Every arrow below depends on what the template, the certificate authority and the domain controllers actually permit.
Low-privileged identity
Enrollment rights on a sensitive template
Template lets the requester supply the certificate identity
Certificate usable for authentication
Certificate issued without sufficient compensating control
Possible impersonation of a more privileged identity, depending on certificate mapping
Access to critical resources or privileges
Tier 0 if the represented identity allows it
The final outcome is not universal: it depends on the template, the extensions carried by the certificate, the authentication mechanism in use, the certificate mapping rules and how hardened the domain controllers are.
The ESC1 problem is not that a certificate was issued. It is that an identity was able to choose the identity represented by a credential the domain accepts.
None of these conditions is a vulnerability on its own. It is their combination, on one published and reachable template, that turns a legitimate capability into an escalation path.
The template must be published by a certificate authority the population can actually use; without publication and reachability the configuration remains theoretical.
Template ACLs grant enrollment rights to a population that is too broad for the role of the template, for instance ordinary user populations.
Granting enrollment to Domain Users or Authenticated Users is not wrong in itself: the risk depends on what the template then allows the certificate to represent.
The template uses the behaviour commonly identified as Supply in the request, or Enrollee Supplies Subject, allowing the request to carry identity information that is not necessarily derived from the requester's Active Directory object.
The template carries a usage compatible with authentication. Several documented Enhanced Key Usages can produce that effect, and ESC1 is not limited to Client Authentication alone:
Without compensating controls, the other settings deliver their full effect, in particular when the following are missing:
ESC1 is therefore not simply Enrollee Supplies Subject equals vulnerable. It is a combination of configuration and permissions whose real effect must be assessed in the environment concerned.
The Subject Alternative Name lets a certificate carry alternative identities. That capability is legitimate and necessary in many technical scenarios, from web services to automated enrollment.
The problem therefore does not come from a certificate carrying a SAN, but from three elements meeting on the same template, at which point the PKI may sign identity information it should have validated.
The problematic combination
Microsoft strengthened certificate-based authentication following KB5014754, introducing an extension that strongly binds a certificate to its Active Directory account and phasing domain controllers towards a stricter enforcement mode.
Since February 2025, Windows domain controllers default to full enforcement, and since the Windows updates of 9 September 2025 the temporary mechanism allowing a return to compatibility mode through StrongCertificateBindingEnforcement is no longer supported. Weak mapping behaviours should therefore not be presented as the normal behaviour of a fully updated Windows domain.
This changes how ESC1 must be assessed: replaying a 2021 lab scenario concluding that an identity supplied in the SAN automatically yields administrative access does not reflect an up-to-date domain. ESC1 is still referenced in 2026 by Microsoft Defender for Identity as a dangerous configuration, but its practical exploitability must be evaluated against the current state of templates, the CA, domain controllers and certificate mapping mechanisms.
What makes certificate risk distinctive is that it creates a new means of authentication rather than necessarily uncovering the existing secret of the targeted account. Where other techniques aim to retrieve or crack a secret, an exploitable ESC1 configuration yields a fresh credential signed by an infrastructure the domain already trusts.
That difference has direct governance consequences: an under-governed PKI can bypass the controls built around passwords, such as rotation, complexity or monitoring of secret-based authentication, and turn a technical delegation mistake into durable privileged access for as long as the certificate remains valid and accepted.
Obtain material to attack offline.
Retrieve secrets that already exist.
In an exploitable configuration, obtain a new credential signed by a trusted infrastructure.
The operational cost differs too: revoking a right is not always enough, because an already issued certificate remains valid until it is effectively revoked and that revocation is honoured by the verification mechanisms.
Detecting ESC1 does not rely on a single signature. It combines a posture review, monitoring of issuance and correlation with how the resulting credentials are actually used.
The best ESC1 signal is often visible before any attack: it sits in the template configuration. The inventory should cover:
Certification Services events document requests and issuance, provided logging is configured to produce the expected telemetry. These events do not prove an ESC1 attack: they become useful when the SIEM analyses the requester, the template, the identity information requested, the issuing authority, the frequency and the timing context.
The signal becomes actionable when certificate issuance is correlated with later use of the credential, in particular through the Kerberos context around Event ID 4768 where that correlation is possible.
AD CS serves real business needs. Remediation means removing the combination that creates the path while preserving legitimate PKI usage.
Where the identity can be derived from Active Directory, prefer that approach so the template issues a certificate whose subject reflects the requester's directory object.
Supply in the request can be legitimate in some technical scenarios: never recommend disabling it everywhere without qualification.
Identify precisely which populations must be able to request the certificate, then remove excessively broad rights where they do not match the real role of the template.
A template that does not need to authenticate a user should not carry the corresponding Enhanced Key Usages, since those are what turn a certificate into a credential.
CA certificate manager approval and authorized signatures can act as effective compensating controls on the most sensitive templates.
Manual approval is not a universal answer: it increases operational load and must match the real risk carried by the template.
Once corrected, recompute the attack paths and review legitimate PKI usage to confirm that remediation removes the risk without breaking the business mechanisms that depend on certificate issuance.
An authority able to issue credentials accepted by Active Directory takes direct part in the domain trust chain. Its configuration, its administrators, its templates and their ACLs must be treated as critical components of the identity architecture, on a par with the domain controllers themselves.
It also explains why very different mechanisms can reach the same outcome: a poorly governed replication right and a poorly scoped certificate template look nothing alike technically, yet both can lead to Tier 0 secrets or identities.
A Tier 0 map limited to these two elements is insufficient
An Active Directory security assessment must examine privileged accounts, groups, delegations and ACLs, but also the mechanisms able to create new trusted credentials. In an environment running AD CS, ignoring the PKI means analysing only half of the identity system.
Our approach is not to produce a list of ESC findings, but to qualify what the configuration genuinely permits, taking into account the certificate mapping mechanisms in force and the business usage of the PKI.
The question the assessment must answer
Does this configuration genuinely allow an ordinary identity to reach a critical identity or resource?
In an AD CS environment, that means analysing
The other pages in this collection. They are not mandatory successive steps: each fits into an attack path according to what the environment allows.
Obtain crackable material from a service account.
Abuse replication rights to obtain domain secrets.
Abuse a PKI trust chain to obtain an authentication certificate.
First-tier references used to support this page.
Microsoft Defender for Identity
Certificates security posture assessment — Prevent users to request a certificate valid for arbitrary users (ESC1)Current reference for Supply in the request, authentication EKUs, enrollment permissions, manager approval, authorized signatures and the present qualification of ESC1.
Microsoft Support
KB5014754 — Certificate-based authentication changes on Windows domain controllersStrong certificate mapping, enforcement, SID extension, the 2022-2025 timeline and the situation applicable in 2026.
Microsoft — Advanced Audit Policy Configuration
Event ID 4886 — Certificate Services received a certificate requestMeaning of the event and its dependency on Certification Services audit configuration.
Microsoft — Advanced Audit Policy Configuration
Event ID 4887 — Certificate Services approved a certificate request and issued a certificateCorrelation between the request, the template used and the certificate actually issued.
SpecterOps
Certified Pre-Owned: Abusing Active Directory Certificate ServicesFoundational research defining the ESC family and the historical analysis of ESC1. Its offensive procedures are deliberately not reproduced here.
MITRE ATT&CK
T1649 — Steal or Forge Authentication CertificatesMapping the scenario to Credential Access and to the abuse of authentication certificates.
ANSSI
Active Directory security checkpointsActive Directory hardening checkpoints, useful to frame governance of sensitive objects and delegations.
ANSSI
Security recommendations for Microsoft Windows loggingWindows logging baseline in Active Directory environments, a prerequisite for any event-based detection.
Ariovis content that directly extends this topic.
The parent page: techniques, prioritisation and directory-side remediation.
The AD assessment service: delegations, ACLs, privileged accounts, PKI and attack paths.
The trajectory for bringing Tier 0 under control, from assessment to first remediations.
