ADCS ESC9, ESC10, ESC11: Certificate Escalation Paths Beyond ESC1-ESC8

What Is ADCS ESC9, ESC10, ESC11 Certificate Escalation

ADCS ESC9, ESC10, ESC11 certificate escalation is the set of Active Directory Certificate Services (AD CS) privilege escalation techniques published after the original "Certified Pre-Owned" research that introduced ESC1 through ESC8. Where the first eight paths center on template misconfigurations, dangerous CA settings, and HTTP web enrollment, ESC9, ESC10, and ESC11 target the layer that decides whether a certificate actually maps to the right account: the security extension embedded in the certificate, the domain controller's certificate-mapping configuration, and the encryption enforcement on the CA's RPC enrollment interface.

All three techniques exist because of the same underlying change: Microsoft's May 2022 update (KB5014754) introduced the szOID_NTDS_CA_SECURITY_EXT security extension, which embeds the requesting principal's SID into an issued certificate so the KDC can strongly bind that certificate to one account. ESC9, ESC10, and ESC11 are three different ways that binding can fail to protect an environment — one at the template level, one at the domain controller/Schannel level, and one at the RPC transport level.

How It Works

ESC9 — No Security Extension

ESC9 exists when a certificate template's msPKI-Enrollment-Flag includes the CT_FLAG_NO_SECURITY_EXTENSION bit (0x80000). SpecterOps' Certify documentation describes this as suppressing the szOID_NTDS_CA_SECURITY_EXT extension on any certificate issued from that template. The effect is that the certificate mapping process behaves as if StrongCertificateBindingEnforcement were set to 0, regardless of its actual registry value on the domain controller, because there is no SID in the certificate to check against.

On its own, that flag is not exploitable. It becomes ESC9 when combined with a second condition attackers already look for on ESC1-ESC8-adjacent templates: a low-privileged principal holding GenericWrite (or equivalent) over another account. An attacker with GenericWrite on a victim account can change that account's userPrincipalName to match a privileged target (for example, an administrator's sAMAccountName), enroll a certificate from the ESC9-flagged template as the victim account, and authenticate as the impersonated target — because the resulting certificate carries no SID extension to contradict the spoofed UPN.

ESC10 — Weak Certificate Mapping (domain-wide)

ESC10 produces the same practical outcome as ESC9 — authentication that resolves to the wrong account — but the misconfiguration lives on the domain controller or in Schannel, not on a single certificate template. SpecterOps and community research (including the Certify wiki and independent ADCS write-ups) describe two variants:

• Case A — Schannel's CertificateMappingMethods registry value on the domain controller includes UPN mapping. An attacker who can write to a victim account's userPrincipalName (again via GenericWrite or similar) sets it to match a target principal, then authenticates over Schannel (client TLS auth) with any certificate whose subject or SAN reflects the spoofed UPN.
• Case B — StrongCertificateBindingEnforcement on the domain controller is explicitly set to 0 (Compatibility mode) rather than the enforced default, so a missing or non-matching SID extension is accepted rather than rejected, for every template and every principal — not just one flagged template as in ESC9.

The key operational difference from ESC9: ESC10 is not limited to a single certificate template, so it typically expands the pool of exploitable accounts to the entire domain.

ESC11 — Relaying NTLM to the CA's RPC interface

ESC11 is the RPC-transport sibling of ESC8 (NTLM relay to HTTP web enrollment). Certificate Authorities expose the ICertPassage (MS-ICPR) RPC interface for certificate requests. According to SpecterOps' Certify documentation and independent research from Compass Security, whether that interface enforces packet-level encryption is controlled by the IF_ENFORCEENCRYPTICERTREQUEST interface flag on the CA. That flag is enabled by default but is frequently disabled for compatibility with older clients that cannot negotiate RPC_C_AUTHN_LEVEL_PKT_PRIVACY.

When the flag is off, an attacker who coerces a victim (for example a domain controller machine account) into authenticating over NTLM can relay that authentication to the CA's RPC interface — bypassing the same web-enrollment protections ESC8 covers, but over RPC instead of HTTP, and independent of whether web enrollment is even installed.

The Attack Chain

🚨 Danger: All three techniques can end in the same outcome as ESC1-ESC8 — a certificate usable for Kerberos PKINIT authentication as a Domain Admin or a domain controller. Escalation via GenericWrite chains directly into ACL Abuse and DCSync: The Silent Paths to Domain Admin. ESC11's relay step uses the same coercion/relay primitives covered in NTLM Relay Attacks: Hijacking Authentication in AD.

Detection

Remediation

1. Remove CT_FLAG_NO_SECURITY_EXTENSION from templates (ESC9). Audit every certificate template's msPKI-Enrollment-Flag. Any authentication-capable template with this flag set should have it cleared unless there is a documented, reviewed reason — and that reason should not include unprivileged enrollment rights.
2. Move domain controllers to Full Enforcement (ESC10 Case B). Confirm StrongCertificateBindingEnforcement is not pinned to 0. Per Microsoft's KB5014754 timeline, domain controllers without an explicit registry value moved to Full Enforcement mode as of the February 2025 update, and the registry key itself stopped being honored after the September 2025 update — so an explicit 0 left in place is a deliberate downgrade that should be found and justified.
3. Disable weak Schannel mapping methods (ESC10 Case A). Review CertificateMappingMethods on every domain controller and any server terminating client-certificate TLS. Weak methods (Subject/Issuer, Issuer only, UPN) should stay disabled; only strong methods (S4U2Self, S4U2Self explicit) should be permitted unless a specific, documented legacy application requires otherwise.
4. Enforce RPC encryption on every CA (ESC11). Run certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST on each CA, then restart the Certificate Services service (net stop certsvc && net start certsvc). Validate afterward with certutil -config "<CA>" -getreg CA\InterfaceFlags and confirm 0x200 is present.
5. Close the underlying GenericWrite exposure. Both ESC9 and ESC10 Case A require an attacker to already hold write access to a victim account's userPrincipalName. Review ACLs for over-broad GenericWrite, GenericAll, WriteProperty, or Validated-SPN-equivalent grants on user objects, especially from helpdesk or provisioning groups, as part of the same remediation pass.
6. Re-test after every change. Certificate mapping and RPC encryption changes can break legacy clients (older Windows versions, non-Windows RPC clients, older smart card middleware). Stage changes through a representative pilot group before enforcing domain-wide, and keep the KDC/Schannel event review from the detection section running through the rollout to confirm no legitimate authentication starts failing.

✅ Quick win: If time only allows one action today, run the certutil -config "<CA>" -getreg CA\InterfaceFlags check on every CA. ESC11 requires no directory privileges to exploit — only network access and a coercion primitive — which makes it the lowest-bar path of the three.

How EtcSec Detects This

EtcSec's AD audit checks map directly to each technique: ESC9_NO_SECURITY_EXTENSION flags certificate templates carrying CT_FLAG_NO_SECURITY_EXTENSION on an authentication-capable template, ESC10_WEAK_CERTIFICATE_MAPPING reviews domain controller and Schannel certificate-mapping configuration for compatibility-mode settings, and ESC11_ICERT_REQUEST_ENFORCEMENT verifies RPC encryption enforcement on every discovered CA. Because ESC9 and ESC10 Case A both depend on a GenericWrite-style prerequisite, EtcSec also correlates these findings against the broader ACL exposure surface so a template flag or a registry setting is prioritized by whether an attacker actually has a path to abuse it — not flagged in isolation.

If you are building a complete AD CS review rather than checking one technique at a time, pair this article with Audit Active Directory Security: What to Review First and How to Prove Remediation for the full Tier 0 checklist these paths fit into.

Primary References

• SpecterOps / Certify — ESC9: No Security Extension
• SpecterOps / Certify — ESC10: Weak Certificate Mapping
• SpecterOps / Certify — ESC11: NTLM Relay to AD CS RPC Interfaces
• Microsoft Support: KB5014754 — Certificate-based authentication changes on Windows domain controllers
• Microsoft Defender for Identity: Enforce encryption for RPC certificate enrollment interface (ESC11)
• Compass Security: Relaying to AD Certificate Services over RPC