AD CS Beyond ESC1: ESC2 Through ESC8 Explained

ESC1 became the best-known AD CS issue, but stopping there leaves a large part of the certificate attack surface untested.

Active Directory Certificate Services contains several layers of trust.

Templates.

Certificate Authorities.

Enrollment Agents.

Web Enrollment.

ACLs.

Subject Alternative Names.

Certificate mapping.

The ESC names describe configurations and trust relationships that can turn certificates into privilege paths.

The examples below assume a lab or an authorized penetration test.

ESC2 changes what the certificate can do

ESC2 appears when a low-privileged principal can enroll in a template containing the Any Purpose EKU or no restrictive EKU.

A certificate with Any Purpose may be accepted for several uses.

That opens paths depending on the rest of the PKI and on how certificates are consumed.

Do not treat “Any Purpose” as automatic compromise.

You still need to identify where that certificate will be accepted.

In some environments it contributes to authentication.

In others it may enable certificate-signing or different application flows.

The template creates broad capability.

The environment determines the final impact.

ESC3 involves Enrollment Agents

Certificate Request Agent lets an identity request a certificate on behalf of somebody else.

There are legitimate reasons for this.

Help desk staff may provision smart cards.

A process may issue certificates for users.

Risk appears when a regular account can obtain an Enrollment Agent certificate and another template accepts that agent for issuance on behalf of other identities.

The path looks like this:

regular user
     |
     v
Enrollment Agent certificate
     |
     v
request on behalf of
     |
     v
certificate for another identity

The analysis needs both templates.

One grants agent capability.

The other accepts it.

ESC4 is ACL abuse against a certificate template

A certificate template is an Active Directory object.

That means it has an ACL.

If a low-privileged account can modify the template, it may be able to turn a safe template into a vulnerable one.

Example.

The template requires manager approval.

The attacking account can modify template properties.

It removes approval.

It enables a dangerous setting.

It enrolls.

Then it may try to restore the original state.

The central weakness is the ACL.

Even if the current configuration looks safe, a principal with write access can change the rules.

ESC5 expands analysis to PKI objects

AD CS infrastructure depends on objects beyond certificate templates.

CA objects.

Enrollment services.

NTAuthCertificates.

PKI containers.

If an untrusted principal can modify critical PKI objects in Active Directory, the trust model may be changed.

This class requires careful analysis.

The exact object and permission determine what becomes possible.

I avoid reducing ESC5 to one command.

It describes control over PKI infrastructure objects.

ESC6 lives on the CA

EDITF_ATTRIBUTESUBJECTALTNAME2 allows requesters to supply SAN data in certificate requests processed by the CA.

Historically, that could turn authentication templates into paths similar to ESC1 even when the template did not use Supply in the request.

There is an important 2026 nuance.

Strong Certificate Mapping changed the result in updated environments.

Modern tooling documentation also points out that ESC6 alone is no longer sufficient for privilege escalation on a patched environment.

The test therefore needs two separate questions.

Will the CA accept an arbitrary SAN?

Can the resulting certificate map to the intended privileged identity?

Keeping those questions separate prevents an old attack path from being reported as guaranteed exploitation.

ESC7 is administrative control over the CA

The Certificate Authority itself has an ACL.

Rights such as Manage CA and Manage Certificates carry significant power.

An account with Manage Certificates may be able to approve pending requests and bypass manager approval in some flows.

Manage CA allows changes to CA configuration.

Microsoft specifically documents that this right can be used to enable EDITF_ATTRIBUTESUBJECTALTNAME2, creating a dangerous condition that did not exist before.

ESC7 highlights an important pattern.

The initial weakness may not issue a privileged certificate directly.

It may provide enough control to reconfigure the CA and create the next condition.

ESC8 uses NTLM Relay against HTTP enrollment

AD CS can expose Web Enrollment or Certificate Enrollment Web Service through IIS.

If the endpoint accepts NTLM without the right protections, relay becomes relevant.

The attacker receives NTLM authentication.

It is forwarded to the enrollment endpoint.

A certificate is requested as the relayed identity.

If that identity is highly privileged, the certificate can become a persistent credential.

In 2026, Microsoft Defender for Identity still identifies AD CS enrollment endpoints that accept NTLM without appropriate HTTPS protection or Extended Protection for Authentication as vulnerable to ESC8.

This path combines two attack surfaces.

NTLM Relay supplies the identity.

AD CS turns that identity into a certificate.

Certipy organizes enumeration

A first pass may use:

certipy find \
  -u 'gabriel@lab.local' \
  -p 'Password123!' \
  -dc-ip 10.10.10.10 \
  -vulnerable \
  -stdout

I use the result as an index.

Then I validate template configuration, CA settings, permissions, and enrollment endpoints separately.

The tool saves time.

The analysis still needs to follow trust.

Strong Certificate Mapping changed older material

A lot of AD CS content was written before certificate mapping hardening.

Some flows that once worked by controlling only a UPN or SAN no longer behave the same way on updated Domain Controllers.

This affects simplified conclusions around ESC1 and ESC6 most directly.

The template may still be misconfigured.

The final exploitation path may require another mapping condition or may fail in that environment.

A current article or report should state which Windows behavior and certificate mapping conditions were validated.

A better way to remember the ESCs

I group them by layer instead of memorizing numbers.

Dangerous templates include ESC1, ESC2, and ESC3.

Template control is ESC4.

Broader PKI object control leads into ESC5.

Unsafe CA configuration appears in ESC6.

CA administrative ACLs appear in ESC7.

HTTP enrollment plus relay appears in ESC8.

That structure makes a large PKI much easier to reason about.

Remediation starts with the broken trust relationship

A permissive template needs changes to enrollment, EKUs, subject handling, and issuance requirements.

Template ACL issues require removing principals that should not administer the object.

ESC6 requires review of EDITF_ATTRIBUTESUBJECTALTNAME2.

ESC7 requires restricted administrative ACLs on the CA.

ESC8 requires HTTPS and EPA as appropriate for the endpoint, plus reduced NTLM exposure and relay protections.

Review the PKI as a system.

Fixing only the template that appeared in a scanner can leave an equivalent path open elsewhere.

The part that changes the pentest

AD CS acts as another identity infrastructure tied directly to Active Directory.

Control over certificate issuance, mapping, or trust creates another way to prove identity.

That is why the ESC classes matter so much.

References

SpecterOps, Certified Pre-Owned.

SpecterOps, Certificates and Pwnage and Patches, Oh My!.

Microsoft Defender for Identity, Certificates security posture assessments.

Certipy, Project documentation.