ADCS-015: ESC15 - Application Policies in Schema v1 Templates
- Platform
- Active Directory
- Category
- AD Certificate Services
- Severity
- Medium
- Zero Trust pillar
- Identity (weight 3)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
This check enumerates all certificate templates published on Enterprise CAs in the forest and flags any template where msPKI-Template-Schema-Version equals 1. For each Schema v1 template, the check evaluates: (1) whether the template is published on at least one Enterprise CA (pKIEnrollmentService certificateTemplates attribute), (2) whether the msPKI-Certificate-Name-Flag attribute has the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bit (0x1) set, and (3) whether enrollment permissions on the template ACL grant the Enroll extended right (CertificateEnrollment, 0e10c968-78fb-11d2-90d4-00c04f79dc55) to non-administrative principals such as Domain Users, Authenticated Users, or Domain Computers. A finding is raised when a Schema v1 template combines these three properties because the CA cannot enforce EKU restrictions against an Application Policies extension supplied by the requester.
Why it matters
Microsoft application policies (OID 1.3.6.1.4.1.311.21.10) override Extended Key Usage when both are present in a certificate. Schema v1 templates predate the modern enforcement model and do not propagate template-defined Application Policies into the issued certificate, so the CA accepts whatever application policy extension the requester places in the CSR. An attacker with enrollment rights on a vulnerable v1 template (the default WebServer template is a common example) can request a certificate that asserts Client Authentication, Smart Card Logon, or Certificate Request Agent without those EKUs ever being listed on the template. Combined with enrollee-supplied subject, this produces a certificate usable for LDAP Schannel authentication as any chosen principal, or for issuing further on-behalf-of certificates via an ESC3 chain. Blast radius is domain compromise when the resulting certificate authenticates a Tier 0 account.
Attack path
Step 1: Enumerate vulnerable templates. The attacker runs Certipy find -vulnerable or Certify.exe enum-templates --filter-vulnerable and looks for templates flagged ESC15 (Schema Version 1 with enrollee-supplied subject and broad enrollment rights). Step 2: Request a certificate with an injected application policy. Using Certipy req with the -application-policies flag set to Client Authentication (1.3.6.1.5.5.7.3.2) or Certificate Request Agent (1.3.6.1.4.1.311.20.2.1), the attacker submits a CSR against a v1 template such as WebServer and specifies an arbitrary subject (UPN or SID of a target account). Step 3: The CA issues the certificate without removing or overriding the Application Policies extension because Schema v1 logic does not enforce template application policies. Step 4: Authenticate. Kerberos PKINIT rejects the certificate because Application Policies is a Microsoft extension not consulted during KDC validation, but LDAP Schannel does evaluate Application Policies. The attacker performs LDAPS bind using PassTheCert or Certipy auth-ldap-shell against a Domain Controller and acts as the target principal. Step 5: For a Certificate Request Agent OID injection, the attacker chains into ESC3 by requesting an Enrollment Agent style on-behalf-of certificate for a Domain Admin and authenticating via PKINIT with the second certificate.
How Guerrilla assesses it
Guerrilla queries the Configuration naming context under CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=forest for every pKICertificateTemplate object. It filters where msPKI-Template-Schema-Version=1, then cross-references CN=Enrollment Services to determine which templates are published on an Enterprise CA. For each published v1 template, the check reads msPKI-Certificate-Name-Flag for the ENROLLEE_SUPPLIES_SUBJECT bit and walks the nTSecurityDescriptor DACL to identify principals granted the Certificate-Enrollment or Certificate-AutoEnrollment extended rights. The finding fires when a published v1 template grants enrollment to a non-Tier-0 principal. The check does not require a writable connection; standard read access to the Configuration partition is sufficient.
Recommended value
No Schema v1 templates published that allow low-privileged enrollment; migrate all required templates to Schema v2 or later
Remediation
Identify all Schema v1 templates (msPKI-Template-Schema-Version = 1) that are published on Enterprise CAs. Migrate Schema v1 templates to Schema v2 or later by creating new templates based on the v1 template with explicit EKU enforcement. Restrict enrollment on any remaining v1 templates to administrative accounts only. Unpublish v1 templates that are no longer required.
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | FAIL |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- CM-6, IA-5(2)
- MITRE ATT&CK
- T1649