In the last year of internal pentests, ADCS issues have been the single biggest source of full-domain compromise from a foothold. Not Kerberoasting. Not unconstrained delegation. Certificate Services.

The issues are known. SpecterOps published the original ESC1 through ESC8 catalog in 2021. ESC9, ESC10, ESC13, ESC14 followed. Every modern offensive tooling chain (Certify, Certipy, BloodHound) flags them automatically. And yet, in 2026, ADCS issues are still where most internal engagements end up walking from a regular user account to Domain Admin.

Why the fix does not happen

Three reasons keep showing up in our debriefs:

1. Ownership is split. ADCS lives in PKI. PKI lives in a sub-team that reports to Infrastructure. Infrastructure reports up through Operations. Security reports up through CISO. Findings about certificate-template permissions land in a queue nobody owns. The Operations team does not understand the security impact; the Security team does not have rights to change the templates.

2. The fix looks scary. Touching certificate templates feels like touching production crypto. Engineers worry that revoking a vulnerable template will break legitimate flows. They are sometimes right, which makes the fix slow.

3. The reporting frames it as a finding, not as a path. A scanner report says "Certificate template 'WebServer' has Enrollment Rights for Authenticated Users and allows Subject Alternative Name in the request". An IT person reading that thinks "we will look at it next quarter". A pentest report that says "we used the WebServer template to issue a certificate for the Domain Administrator, then authenticated as Domain Administrator via PKINIT, here is the screenshot" gets fixed within a week.

The four changes that close most of it

These four changes, applied together, close ESC1, ESC2, ESC3, ESC4, ESC6, and ESC9 in most environments. ESC8 and the relay attacks need separate work; ESC11 needs ADCS server hardening.

Change 1: Restrict Subject Alternative Name on every template

The ESC1 attack relies on a certificate template that allows the enrollee to specify a Subject Alternative Name in the request. With that, the enrollee can request a cert in another user's name. Combined with PKINIT, that becomes an authentication primitive against the target user.

The fix: for every certificate template, set the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag to off unless the template specifically requires it (rare). Audit the template list. The default templates that ship with ADCS are not the issue; the issue is custom templates added by your PKI team over the years.

Change 2: Audit Enrollment Rights on every template

ESC2 and ESC3 are about templates that grant Enrollment Rights to Authenticated Users or Domain Users. That means every account in the domain can request a certificate using that template. Combined with a template that has problems (ESC1, EKU misconfiguration), this is the foothold path.

Pull the template list, sort by who has Enrollment Rights. Anything granted to a wide group should be reviewed. Most templates should grant rights only to a specific OU or security group.

Change 3: Disable ESC6 if you have not already

ESC6 (EDITF_ATTRIBUTESUBJECTALTNAME2) is a registry flag on the CA itself that allows any cert request to specify a Subject Alternative Name. Microsoft published the disabling guidance years ago. We still find it enabled in 30% of engagements.

Run certutil -getreg policy\EditFlags on each issuing CA. If EDITF_ATTRIBUTESUBJECTALTNAME2 is set, clear it: certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2. Restart the CA service. Test issuance.

Change 4: Enforce manager approval on high-privilege templates

For templates that produce certificates with Client Authentication EKU (which is what makes PKINIT possible), set the Manager Approval flag on the template. This puts a human between an automated enrollment request and the certificate issuance.

This is the single biggest detection win. Even if an attacker compromises an account that has Enrollment Rights on a sensitive template, the approval step gives your team a chance to notice and reject.

What to monitor

Even after the four changes above, set up detection. ADCS audit logs are not on by default. Turn them on. Alert on:

  • Certificate issuance with a Subject Alternative Name that does not match the enrollee's name
  • Certificate issuance for templates with Client Authentication EKU to a non-standard requester
  • Any modification to a certificate template ACL
  • PKINIT authentication for accounts that do not normally use it (the Domain Administrator account, in particular)

What we still find, post-fix

After the four changes, the path that still shows up most often is ESC8: NTLM relay to the ADCS web enrollment endpoint. The fix is to either disable web enrollment entirely (often possible; most orgs do not use it) or require Extended Protection for Authentication (EPA) and channel binding on the web endpoint.

If you cannot disable it and cannot enable EPA, segment the web enrollment endpoint so that it is not reachable from regular workstations. Coercion attacks (PrinterBug, PetitPotam) need a path from a low-privilege machine to the ADCS web endpoint; remove the path.

"We spent two years on Kerberoasting hardening. We knew ADCS was a risk but it never made the top of the list. After we got popped via ESC1 in a tabletop, the conversation changed in a week." — security architect at a US healthcare client, December 2025

If you only do one thing this quarter

Run Certify.exe find /vulnerable from a regular domain user account, in your production environment, with a logged maintenance window. The output is your prioritized fix list. Most of the catalog from this article will surface in five minutes of running.

Then file the findings as paths, not findings. "Domain user X can become Domain Admin via template Y, here is the screenshot" gets traction. "Certificate template Y is misconfigured" does not.