ESC1 and ADCS Attack Paths: What to Fix First

ESC1 is a misconfiguration in an Active Directory Certificate Services (AD CS (often written ADCS)) template that lets an ordinary domain user request a certificate in someone else’s name, including a domain admin’s, and then authenticate as that person. It’s one of the most common and most damaging AD CS attack paths, and in most environments it’s fixable with a few template changes.

I wrote about what PKI is and mentioned that AD CS is usually set up once and never revisited. This post is about why that matters, starting with ESC1 and covering the other common ESCs briefly. It’s written for defenders. There are no exploit steps here, and you don’t need them to fix the problem.

What is Microsoft ADCS?

Active Directory Certificate Services is Microsoft’s PKI role for Windows Server. It runs certificate authorities that integrate with Active Directory, publishes certificate templates, and handles autoenrollment so domain-joined machines and users get certificates without anyone filing a ticket.

That integration is the point, and it’s also the risk. AD CS certificates are commonly used for:

• Wi-Fi and VPN authentication (802.1X)
• Smart card and certificate-based Windows sign-in
• TLS for internal servers
• Code signing, EFS and S/MIME

When a certificate with a client authentication EKU is issued by an enterprise CA that AD trusts, it can be used to authenticate to the domain through Kerberos PKINIT. In other words, a certificate can be a credential, and often a long-lived one. A password reset doesn’t revoke it.

So the security question for AD CS is the same one I keep coming back to with PKI: who is allowed to get a certificate that says they’re someone, and does the CA check that they really are?

Where did the ESC names come from?

In 2021, Will Schroeder and Lee Christensen at SpecterOps published a whitepaper called Certified Pre-Owned. It documented a set of AD CS misconfigurations that could lead to domain escalation and labeled them ESC1 through ESC8. Most of these weren’t software bugs. They were default or common configurations that nobody had looked at through an attacker’s eyes.

The paper landed hard because AD CS was everywhere and almost nobody was auditing it. Since then, other researchers have added more numbered ESCs, and the list has grown well past the original eight. The naming has become the shared vocabulary, which is useful: when an assessment report says “ESC1 on three templates,” everyone knows what that means.

If you want the primary source, it’s on SpecterOps’ site. It’s long, but the defensive sections are worth reading even if you skip the rest.

What is ESC1, in plain terms?

A certificate template is vulnerable to ESC1 when all of these are true at once:

Condition	What it means
The enrollee supplies the subject	The template is set to “Supply in the request,” so the requester decides whose name (subject or subject alternative name) goes in the certificate
The certificate allows client authentication	The template includes an EKU that can be used to log on, such as Client Authentication, Smart Card Logon or Any Purpose
Low-privileged users can enroll	Enrollment rights are granted to a broad group like Domain Users, Authenticated Users or Domain Computers
No manager approval	The CA issues the certificate automatically, with no CA certificate manager reviewing the request
No authorized signatures required	The request doesn’t need to be co-signed by an enrollment agent

Put together, the template says: anyone can ask for a logon certificate in any name they like, and we’ll sign it without looking. An attacker with any domain account requests a certificate naming a domain admin, the CA issues it, and the attacker authenticates as that admin.

What makes ESC1 nasty in practice:

• It’s quiet. Certificate requests are routine. Without CA auditing turned on, there may be no useful record at all.
• It survives password resets. The certificate stays valid until it expires or is revoked, often a year or more.
• It’s usually an accident. Someone duplicated a web server template, where enrollee-supplied subjects are normal, then added client authentication for some application and opened enrollment to everyone to make a project work.

What this usually looks like: Say a team needed certificates for an internal application that authenticated clients by certificate. Someone duplicated the Web Server template, kept “Supply in the request” because it was already set, added Client Authentication, and granted Enroll to Authenticated Users because the app’s service accounts kept failing. It worked, the ticket closed, and the template stayed published long after the application was retired. If you find one, check what that template has already issued before you change anything, in case someone found it first.

What are the other common ESCs?

You don’t need to memorize the whole list to defend against it. These are the ones I’d check alongside ESC1:

ESC	The short version	The fix in one line
ESC2	Template has the Any Purpose EKU or no EKU at all, so the certificate can be used for nearly anything	Set explicit, minimal EKUs on every template
ESC3	Template issues Certificate Request Agent (enrollment agent) certificates to broad groups, letting holders request certificates on behalf of other users	Restrict enrollment agent templates tightly and configure enrollment agent restrictions on the CA
ESC4	Low-privileged users have write permissions on a template object, so they can change it into an ESC1	Review template ACLs; only PKI admins should be able to modify templates
ESC6	The CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag set, letting requesters add a SAN to any request, on any template	Remove the flag unless you have a documented need, and keep CAs patched
ESC8	Web enrollment endpoints accept NTLM authentication over HTTP, so an attacker can relay a machine’s authentication to them and get a certificate as that machine	Remove web enrollment if unused; otherwise require HTTPS with Extended Protection for Authentication and disable NTLM where you can

ESC5 and ESC7 cover permissions on the wider PKI: AD objects, the CA server itself, and CA-level rights like ManageCA. The theme is the same throughout. If a low-privileged identity can influence what the CA issues, the CA can be turned against you.

How do you secure ADCS? What to fix first

Here’s the order I’d work in. Most of it is configuration and permissions, not new tooling.

1. Inventory your CAs and templates

You can’t fix what you haven’t listed. Find every enterprise CA in the forest, every published template, who can enroll, and what each template is for. In most environments there are templates published that nobody can explain. Unpublish the ones with no owner and no recent issuance.

2. Remove enrollee-supplied subjects where they aren’t needed

Most client authentication templates should build the subject from Active Directory, not from the request. If a template genuinely needs requester-supplied names (some web server and device scenarios do), it shouldn’t also allow client authentication and broad enrollment.

3. Require manager approval on sensitive templates

For any template that has to allow enrollee-supplied subjects plus an authentication EKU, turn on CA certificate manager approval. It adds friction, which is the point. Someone looks at the request before the CA signs it.

4. Restrict enrollment rights

Replace Domain Users and Authenticated Users with specific groups tied to the use case. Review template and CA permissions for write access too, which covers ESC4 and ESC7.

5. Check CA-level settings

Confirm EDITF_ATTRIBUTESUBJECTALTNAME2 isn’t set on your CAs (ESC6). Review web enrollment endpoints and NTLM exposure (ESC8). Make sure CAs are patched; Microsoft has shipped changes over the past few years that tighten how certificates map to accounts, and you want those in place and enforced.

6. Turn on auditing and watch issuance

Enable CA auditing and the Audit Certification Services policy so you get events for requests, issuance and template changes (event IDs 4886, 4887, 4899 and 4900 are the ones to start with). Then alert on what matters: certificates issued where the requester and the subject don’t match, issuance from templates that rarely issue, and any change to template security. This is identity detection, and it belongs in your ITDR coverage alongside Kerberos and IdP events.

7. Treat CA servers as Tier 0

An enterprise CA that AD trusts can mint credentials for any account. That puts it in the same tier as your domain controllers. Restrict who can log on to it, manage it from privileged access workstations, broker admin access through your PAM platform, and protect CA keys with an HSM. If your CA is administered by the same accounts that manage file servers, it isn’t Tier 0 yet.

Where it tends to go wrong: The pushback is usually some version of “it’s just a certificate server.” The PKI admins have logged on directly for years, the CA hosts other roles, and PAM sounds like friction for a box that rarely changes. My approach is to show what ESC1 or a stolen CA key makes possible, then start small: vault the CA admin accounts, require sessions through PAM, and move the other roles off the server. The Tier 0 label tends to follow once people see the attack path.

Tools that help

You don’t have to audit templates by hand. Several free, open-source tools check AD CS configurations against the known ESCs and explain what they find; Locksmith and PSPKIAudit are two that defenders commonly use, and several broader AD assessment tools include AD CS checks too. Run one in a read-only, reporting mode first, review the findings with whoever owns the PKI, and fix in order of exposure.

The short answer

ESC1 is a template that lets anyone request a logon certificate in anyone’s name, and the CA signs it without question. It comes from four settings lining up: enrollee-supplied subject, client authentication EKU, broad enrollment rights and no approval. Break any one of them and the path closes.

Where to start: inventory your templates, fix every ESC1 you find, check for ESC2, 3, 4, 6 and 8 while you’re there, turn on CA auditing, and treat your CAs as Tier 0. It’s unglamorous work. It’s also some of the highest-value identity hardening you can do in an AD environment. More on the PKI side at /topics/pki/.