| name | exploiting-active-directory-certificate-services-esc1 |
| description | Exploit misconfigured Active Directory Certificate Services (AD CS) ESC1 vulnerability to request certificates as high-privileged users and escalate domain privileges during authorized red team assessments. |
| domain | cybersecurity |
| subdomain | red-teaming |
| tags | ["red-team","active-directory","ad-cs","esc1","certificate-abuse","privilege-escalation","domain-escalation"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| d3fend_techniques | ["File Metadata Consistency Validation","Certificate Analysis","Content Format Conversion","File Content Analysis","Platform Hardening"] |
| nist_csf | ["ID.RA-01","GV.OV-02","DE.AE-07"] |
Exploiting Active Directory Certificate Services ESC1
Overview
ESC1 (Escalation Scenario 1) is a critical misconfiguration in Active Directory Certificate Services where a certificate template allows a low-privileged user to request a certificate on behalf of any other user, including Domain Admins. The vulnerability exists when a template has the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag enabled (also called "Supply in Request"), combined with an Extended Key Usage (EKU) that permits client authentication (Client Authentication, PKINIT Client Authentication, Smart Card Logon, or Any Purpose). This allows an attacker to specify an arbitrary Subject Alternative Name (SAN) in the certificate request, effectively impersonating any domain user. ESC1 was documented by SpecterOps researchers Will Schroeder and Lee Christensen in their "Certified Pre-Owned" whitepaper (2021) and remains one of the most common AD CS attack paths. The MITRE ATT&CK framework tracks this as T1649 (Steal or Forge Authentication Certificates).
When to Use
- When performing authorized security testing that involves exploiting active directory certificate services esc1
- When analyzing malware samples or attack artifacts in a controlled environment
- When conducting red team exercises or penetration testing engagements
- When building detection capabilities based on offensive technique understanding
Most Often Missed & How to Confirm
- Confirming only ENROLLEE_SUPPLIES_SUBJECT. ESC1 needs all conditions together: enrollee-supplies-subject, an authentication EKU (Client Auth / PKINIT / Smart Card Logon / Any Purpose), no manager approval, and enroll rights for a low-priv group. Verify each with
certipy find -vulnerable.
- Wrong CA/template name syntax. The
-ca value is the CA common name, not the host; a mismatch makes the request fail with a confusing error.
- PFX without the password / wrong crypto provider when converting with OpenSSL, breaking Rubeus import.
- Forgetting the SAN/UPN flag. You must supply the target's UPN (
-upn administrator@domain.local / /altname:administrator) or you just enroll as yourself.
- DC not supporting PKINIT (no DC auth cert) — auth silently fails even with a valid cert.
- How to confirm a hit: the CA issues a cert and
certipy auth -pfx administrator.pfx returns the target's NT hash (Linux) or Rubeus asktgt /ptt loads a TGT shown in klist. The definitive success signal is using that material — runs a DCSync, or succeeds as the impersonated DA. Don't conclude the template is safe until you've confirmed the requester SAN can differ from the enrollee (Event 4886/4887 show the mismatch) and that PKINIT auth actually completes.
