ADCS-005: ESC3 - Enrollment Agent Template Abuse Condition 2
- Platform
- Active Directory
- Category
- AD Certificate Services
- Severity
- High
- Zero Trust pillar
- Identity (weight 3)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
For every published certificate template (objects of class pKICertificateTemplate under CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=tld) the check evaluates two conditions in conjunction: 1. The template requires an authorized signature with the Certificate Request Agent application policy. This is detected by reading msPKI-RA-Signature (integer >= 1 means the template requires at least one signature on the request) and msPKI-RA-Application-Policies containing the OID 1.3.6.1.4.1.311.20.2.1. 2. The template issues a certificate that can be used for AD authentication. This is detected by parsing pKIExtendedKeyUsage (and the equivalent msPKI-Certificate-Application-Policy) for any of: - 1.3.6.1.5.5.7.3.2 Client Authentication - 1.3.6.1.5.2.3.4 PKINIT Client Authentication - 1.3.6.1.4.1.311.20.2.2 Smart Card Logon - 2.5.29.37.0 Any Purpose, or absent EKU (treated as Any Purpose) The check also reads msPKI-Enrollment-Flag, msPKI-Certificate-Name-Flag (looking for CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT which compounds the impact), and the templates DACL to determine which principals can enroll. Templates matching both conditions are returned with the publishing CA(s) from pKIEnrollmentService.certificateTemplates, the EKU list, and the set of low-privileged principals with Enroll or AutoEnroll rights so the reviewer can score blast radius without a second query.
Why it matters
ESC3 collapses Enrollment Agent capability into Domain Admin in a single chained step. Condition 1 templates (the Enrollment Agent template itself, by default published with low-privileged Enroll rights in many environments) hand the attacker a Certificate Request Agent certificate. Condition 2 templates accept that certificate as a signature on a CMC request whose subject is any user in the forest. The CA, by default, has no Enrollment Agent restrictions configured, which means it will trust any holder of a Certificate Request Agent cert to enroll on behalf of any principal. The resulting certificate is a valid PKINIT client cert for the target, so the attacker uses Rubeus or certipy to perform a Kerberos AS-REQ with PKINIT, retrieve a TGT for the target principal, and immediately use it for DCSync, ticket forging, or interactive logon. Because no password change or interactive logon by the victim is required, this path is silent, persists across credential rotations, and survives MFA on the target account. It is the documented initial-access-to-Tier-0 primitive that drove Microsoft to ship CVE-2022-26923 strong mapping and the StrongCertificateBindingEnforcement registry hardening.
Attack path
1. Reconnaissance: the attacker runs certipy find -u user@domain -p pass -dc-ip x.x.x.x -vulnerable, or Certify.exe find /vulnerable, which marks templates as ESC3 when both conditions hold. BloodHound CE imports the same data via the Collected -CollectionMethod CertServices path. 2. Obtain an Enrollment Agent certificate (ESC3 Condition 1, see ADCS-004). The default Enrollment Agent template often allows Domain Users to Enroll. The attacker requests it: certipy req -u user@domain -p pass -ca CORP-CA -template EnrollmentAgent. 3. Identify a Condition 2 template that low-privileged users can enroll for. Default candidates include any modified copy of User, SmartcardUser, or custom templates created for smart-card rollout that retained Domain Users Enroll rights and the Enrollment Agent signature requirement. 4. Forge the on-behalf-of request: certipy req -u user@domain -p pass -ca CORP-CA -template SmartcardUser -on-behalf-of CORP\Administrator -pfx user_enrollmentagent.pfx. Certipy builds a CMC request, signs it with the Enrollment Agent cert, and submits it with the Administrator as the subject. The CA, lacking Enrollment Agent restrictions, issues the certificate. 5. Authenticate as the target: certipy auth -pfx administrator.pfx. The tool performs PKINIT, retrieves a TGT for Administrator, and returns the NT hash via the U2U + Kerberos-PA-PK-AS-REP encrypted key extraction path. 6. Privilege escalation and persistence: with the Administrator TGT (or NT hash) the attacker runs DCSync (secretsdump, mimikatz lsadump::dcsync) to pull the krbtgt hash, forges Golden Tickets, and is now persistent across password resets. Because the captured cert is valid for its full lifetime (default 1 year on most user templates), the attacker can re-authenticate without re-exploiting until the certificate expires or is revoked.
How Guerrilla assesses it
Guerrilla queries the Configuration partition over LDAP for objectClass=pKICertificateTemplate. For each template returned it reads msPKI-RA-Signature, msPKI-RA-Application-Policies, pKIExtendedKeyUsage, msPKI-Certificate-Application-Policy, msPKI-Enrollment-Flag, msPKI-Certificate-Name-Flag, and the nTSecurityDescriptor. It correlates each vulnerable template against the pKIEnrollmentService objects (CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration) to confirm the template is currently published on a live CA, since an unpublished template is not exploitable. Enroll and AutoEnroll DACL entries are resolved through Translate(NTAccount) and compared against a high-privilege baseline (Domain Admins, Enterprise Admins, Cert Publishers, BUILTIN\Administrators, SYSTEM); any principal outside that baseline holding Enroll on a vulnerable template is flagged. The check does not require local RSAT or the CA to be online: everything is read from the AD Configuration NC, which any authenticated user can read by default. Where the optional CA-side audit is enabled, Guerrilla also calls certutil -getreg CA\EnrollmentAgentRights on each CA host to confirm whether Enrollment Agent restrictions are configured (empty or wildcard equals unrestricted).
Recommended value
Templates requiring enrollment agent signatures restricted to specific target users via enrollment agent restrictions on the CA
Remediation
Identify templates that require an authorized signature with the Certificate Request Agent application policy and have Client Authentication or Smart Card Logon EKU. Configure Enrollment Agent restrictions on the CA to limit which templates these enrollment agents can enroll for and which users they can enroll on behalf of. This is configured in the CA properties under Enrollment Agents restrictions.
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
- AC-6, IA-5(2), CM-6
- ANSSI
- vuln_adcs_esc3
- MITRE ATT&CK
- T1649