An ESC1 attack is a certificate abuse technique in Active Directory Certificate Services that exploits a misconfigured Enterprise CA template. If the template allows an attacker to specify another account in the request and supports usable authentication EKUs, the attacker can obtain a certificate and impersonate that account.
What the attack does
ESC1 is a certificate template abuse path in Active Directory Certificate Services. The attacker abuses a template that lets the requester supply the subject or another user field, then requests a certificate that can be used for authentication. The result is not just certificate issuance, but the ability to present as the chosen account through normal certificate-based trust.
This matters because the attack turns a routine enterprise trust service into an impersonation channel. When an enrollee can influence the identity encoded in the certificate, the certificate becomes an access token for that account rather than proof of the requester’s own identity.
Why misconfigured templates are dangerous
ESC1 becomes viable when template settings combine two properties: user-controlled subject data and authentication-capable EKUs. That combination breaks the intended boundary between who asked for the certificate and who the directory believes the certificate represents. In practice, the danger is privilege escalation through a trusted PKI path, not a password reset or a simple mis-issuance event.
In environments with broad template publication, the blast radius can be large. A single vulnerable Enterprise CA template can expose many downstream services that accept certificate authentication, especially where certificate mapping is permissive or legacy trust decisions remain in place.
How organisations expose and validate the issue
Exposure review starts with the certificate template inventory, the Enterprise CA configuration, and the permissions on who can enrol or modify templates. Teams should check whether low-privilege users can request from a template that allows requester-supplied identity fields and usable authentication EKUs.
The practical validation question is simple: can an unprivileged requester influence the name that will be trusted by the domain? If the answer is yes, the organisation needs to treat the template as an escalation path and review whether directory mapping, issuance policies, and CA permissions are constraining it as intended. The AD CS Security Guide is the most direct starting point for understanding vulnerable template patterns and broader AD CS abuse paths.
Remediation, detection, and identity impact
The core remediation is to remove the misconfiguration that makes the certificate usable as an impersonation credential. That usually means restricting who can request the template, preventing requester-controlled identity fields where they are not required, and tightening certificate mapping so the directory does not accept ambiguous identity assertions.
Detection should focus on unusual certificate enrolment behaviour, unexpected template use, and post-issuance logon with certificates tied to accounts the requester should not control. After suspected exploitation, organisations should review whether certificates, mapped sessions, or related authentication material need to be revoked or rotated, because the compromise can persist beyond the initial request.
For broader guidance on the way certificate abuse fits into AD CS hardening, strong certificate mapping, and ESC path detection, see the AD CS Security Guide. For current exploitation tracking and patch prioritisation, consult the vendor advisory and the CISA cyber threat advisories.
Risk and Threat Considerations
ESC1 is dangerous because it converts certificate enrolment into a reliable impersonation route. If attackers can request a certificate that names a different account and can be accepted for authentication, they may gain access that looks legitimate to directory-integrated systems.
Failure mechanism: The template allows attacker-controlled identity data to flow into a certificate that is trusted for authentication, so the directory accepts the certificate as another principal.
Impact: The attacker can impersonate the targeted account, potentially escalating privilege, accessing protected resources, and creating persistence through trusted certificate-based logon paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | ESC1 abuse hinges on certificate material that authenticates a user. |
| IA-2 — Identification and Authentication (Organizational Users) | The attack impersonates an organisational user through trusted authentication. | |
| AC-6 — Least Privilege | ESC1 often becomes exploitable when enrolment or template rights are broader than needed. | |
| Recommendation — Restrict certificate lifecycle settings so authentication-capable templates cannot be misused for impersonation. Ensure certificate-based user authentication maps only to trusted, verified identities. Limit template enrolment and modification rights to the minimum necessary set of administrators and users. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Template permissions and enrolment rights are the primary exposure point. |
| Recommendation — Review and restrict certificate template access so low-privilege users cannot request impersonation-capable certificates. | ||
| MITRE ATT&CK | T1649 — Steal or Forge Authentication Certificates | ESC1 is a certificate-forgery technique used to obtain authenticating credentials. |
| Recommendation — Detect and hunt for forged or abused certificates used to impersonate domain accounts. | ||
Practitioner Guidance
Why practitioners should care: ESC1 is a governance and configuration problem as much as a technical one, because the vulnerable template often survives in production simply because it was convenient to publish. Ownership of AD CS templates should be explicit, and template review should be part of certificate governance rather than a one-time CA build activity.
What to watch for: Pay close attention to templates that permit enrollee-supplied subject data, broad enrolment rights, or authentication EKUs without a clear business need. Those combinations should trigger a security review before they become an identity escalation path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org