AD CS ESC11: NTLM relay to the CA's RPC interface
A certificate authority accepts unencrypted certificate requests over RPC, so a relayed domain controller logon can get a certificate for the domain controller.
- Category
- Attack Path
- Severity
- At least High.
- Typical owner
- PKI / AD CS administrators
- Data needed
- The CA's InterfaceFlags registry value, which only the built-in collector* reads, in its Full collection. Without it, the report shows ESC11 as not checked.
On this page
In plain language
Clients normally ask an Enterprise CA for certificates over RPC. A flag on the CA, IF_ENFORCEENCRYPTICERTREQUEST, makes it insist that those requests are encrypted. When the flag is off, the CA also accepts requests over a plain NTLM connection, and that connection can be relayed.
An attacker on the network can make a domain controller authenticate to them, pass that logon on to the CA, and receive a certificate for the domain controller from any template that allows logon. With it they can take over the domain, starting with no privileges at all. Pathwarden treats it as exposed to everyone and lists the templates that make it work. This is ESC11, the RPC twin of PW-019. Current Windows Server versions set the flag at install, so a CA without it usually had it removed on purpose.
What Pathwarden flags
Clients normally request certificates from an Enterprise CA over RPC (the ICPR interface that autoenrollment and certreq use). The CA's InterfaceFlags registry value decides whether it insists that those requests are encrypted (packet privacy). On this CA the IF_ENFORCEENCRYPTICERTREQUEST flag (0x200) is off, so it also accepts requests over an unencrypted connection authenticated with NTLM, and such a connection can be relayed.
The finding lists the templates that make it exploitable: published by this CA, usable for authentication, and issued without manager approval or extra signatures.
How attackers use it
This is ESC11, the RPC twin of ESC8. 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 over RPC with tools such as ntlmrelayx or Certipy, and receives a certificate for the domain controller's computer account from one of the listed templates. 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 InterfaceFlags registry value, which only the built-in collector* reads, in its Full collection. Without it, the report shows ESC11 as not checked.
In the web UI or the HTML report, open the Findings tab and expand PW-036: 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:
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-036
# the step-by-step guide on this page, offline
pathwarden guide PW-036
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-036Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.
Before you change anything
- Current Windows Server versions set the flag when the CA is installed, so a CA without it has usually had it removed on purpose, often for old clients. Ask the PKI team why, and check the CA's history (change records,
certutil -getreg CA\InterfaceFlagson a backup). - Clients that can't encrypt their requests (Windows XP and Server 2003 era systems, some appliances and non-Windows enrollment tools) will no longer be able to enroll over RPC. Look in the CA's issued certificates for requesters that look like that, and plan for them first.
- Autoenrollment, certreq and the Certificates console on supported Windows versions already encrypt their requests and are unaffected.
How to fix it
Option A: Require encrypted requests (recommended)
- On the CA server (or remotely with
-config), set the flag with the certutil command below. - Restart Certificate Services; the change takes effect at the restart.
- Test enrollment from a client (for example
certreq -enroll -machineor the Certificates console).
Option B: 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, and ESC8 with it.
PowerShell / certutil
# Option A: require encrypted requests on the RPC interface
certutil -config "<CAHost>\<CAName>" -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
# then, on the CA server
net stop certsvc
net start certsvcVerify the fix
certutil -config "<CAHost>\<CAName>" -getreg CA\InterfaceFlagslistsIF_ENFORCEENCRYPTICERTREQUEST.- Collect again with the built-in collector's Full collection (it reads the flag from the CA's registry as an ordinary domain user) and confirm the finding ID is gone. Pathwarden takes the flag from that collection, or from the CA's Tier Zero settings file (
scripts\Get-PathwardenTierZeroSettings.ps1run on the CA). Without either, with SharpHound or RustHound-CE data, the report's AD CS data section shows ESC11 as not checked for the CA.
Roll back
certutil -config "<CAHost>\<CAName>" -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST, then restart Certificate Services.
References
- Compass Security, Relaying to AD Certificate Services over RPC (ESC11)blog.compass-security.com
- Microsoft KB5005413, mitigating NTLM relay attacks on AD CSsupport.microsoft.com
- 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.