PW-019Attack pathCertificate Services (AD CS)

AD CS ESC8: NTLM relay to web enrollment

A certificate authority's web enrollment accepts relayed NTLM logons, so a domain controller can be tricked into requesting a certificate for an attacker.

Category: Attack Path
Severity: At least High.
Typical owner: PKI / AD CS administrators (web server / IIS administrators)
Data needed: The CA's web enrollment endpoints, which the collector probes: SharpHound, RustHound-CE, or the built-in collector^* with --user --scope all.

MITRE ATT&CKT1649 T1187 T1557

Most useful toDefensive engineers Identity and access engineers Offensive operators

On this page

In plain language

Many CAs still have the old web enrollment pages (/certsrv) installed. Over plain HTTP, or HTTPS without Extended Protection for Authentication, those pages accept NTLM logons that an attacker has relayed from another computer.

An attacker on the network can make a domain controller authenticate to them, pass that authentication on to the web enrollment page, and receive a certificate for the domain controller. With it they can take over the domain, starting with no privileges at all. Pathwarden treats it as exposed to everyone. This is ESC8. Most organizations no longer use these pages, and removing them is the cleanest fix.

What Pathwarden flags

The CA offers web-based enrollment (Certificate Authority Web Enrollment at /certsrv, or the Certificate Enrollment Web Service) over HTTP, or over HTTPS without Extended Protection for Authentication (EPA). Those endpoints accept NTLM authentication, so a relayed NTLM logon from another computer is accepted as if that computer had asked for a certificate.

How attackers use it

This is ESC8 from SpecterOps' "Certified Pre-Owned". An attacker on the network coerces a domain controller into authenticating to a computer they control (for example with PetitPotam or the printer bug), relays that NTLM authentication to the CA's web enrollment page with tools such as ntlmrelayx or Certipy, and receives a certificate for the domain controller's computer account. With it they obtain the DC's credentials and can DCSync the domain. No prior privileges beyond network access are required, which is why this is treated as exposed to every account.

Find it with Pathwarden

Data needed: The CA's web enrollment endpoints, which the collector probes: SharpHound, RustHound-CE, or the built-in collector^* with --user --scope all.

In the web UI or the HTML report, open the Findings tab and expand PW-019: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell

# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-019
# the step-by-step guide on this page, offline
pathwarden guide PW-019
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-019

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

List the endpoints reported in the finding and check who uses them. Most organizations no longer use the /certsrv pages; autoenrollment and certreq talk to the CA over RPC/DCOM and are unaffected by the changes below.
If the Certificate Enrollment Web Service is used (for example by non-domain or cross-forest clients), plan HTTPS with EPA rather than removal.
Check IIS on the CA server: Sites > Default Web Site > CertSrv (and any _CES_ applications), and its bindings.

How to fix it

Option A: Remove web enrollment if it is not used (recommended)

On the CA server, uninstall the role services with the commands below (Web Enrollment, and the Enrollment Web Service if present and unused).
Remove the now-unused IIS site bindings if nothing else on the server needs them.

Option B: Require HTTPS with Extended Protection (when web enrollment is needed)

IIS Manager > Sites > Default Web Site > CertSrv > SSL Settings: tick Require SSL.
CertSrv > Authentication > Windows Authentication > Advanced Settings: set Extended Protection to Required.
Repeat for each Certificate Enrollment Web Service application (named <CAName>_CES_Kerberos or similar).
Remove the HTTP (port 80) binding from the site if nothing else needs it.
Run iisreset and test enrollment from a client.

Option C: Block NTLM to the CA server

Disable NTLM for incoming traffic on the CA server (Group Policy: Network security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts), after auditing with the corresponding audit setting. This also blocks the relay.

PowerShell / certutil

PowerShell

# Option A: remove the Web Enrollment role service (run on the CA server)
Uninstall-AdcsWebEnrollment -Force
Uninstall-WindowsFeature ADCS-Web-Enrollment

# Option A: remove the Certificate Enrollment Web Service if present and unused
Uninstall-AdcsEnrollmentWebService -Force
Uninstall-WindowsFeature ADCS-Enroll-Web-Svc

# Option B: require Extended Protection on CertSrv (verify in IIS Manager afterwards)
& "$env:windir\system32\inetsrv\appcmd.exe" set config "Default Web Site/CertSrv" -section:system.webServer/security/authentication/windowsAuthentication /extendedProtection.tokenChecking:"Require" /commit:apphost

Verify the fix

Browsing to http://<CAHost>/certsrv/ fails (removed, or redirected/blocked), and HTTPS requires EPA (IIS Manager shows Extended Protection: Required).
Collect again (or use Retest on the finding) and confirm the finding ID is gone. Endpoint data comes from the collector probing the CA (SharpHound and RustHound-CE both do this).

Roll back

Reinstall with Install-WindowsFeature ADCS-Web-Enrollment followed by Install-AdcsWebEnrollment, or set Extended Protection back to Off/Accept and re-add the HTTP binding in IIS Manager.

References

Microsoft KB5005413, mitigating NTLM relay attacks on AD CSsupport.microsoft.com
SpecterOps, Certified Pre-Owned (ESC8)specterops.io
SpecterOps: Certified Pre-Owned (blog post)specterops.io
MITRE ATT&CK T1649: Steal or Forge Authentication Certificatesattack.mitre.org
MITRE ATT&CK T1187: Forced Authenticationattack.mitre.org
MITRE ATT&CK T1557: Adversary-in-the-Middleattack.mitre.org

Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.