Active Directory Certificate Services (AD CS): Attacks Beyond the Classics (ESC9 Through ESC16)

Most overviews of Active Directory Certificate Services (AD CS) stop at ESC8. That is understandable, because ESC1 through ESC8 come from the original „Certified Pre-Owned" paper by SpecterOps and cover the most obvious misconfigurations: exploitable Subject Alternative Names, dangerous enrollment EKUs, weak template ACLs, the EDITF CA setting and the NTLM relay against the web enrollment interface. In real internal pentests, though, the path to Domain Admin often runs through the techniques that were described later and are missing from many hardening checklists precisely for that reason.

These gaps are not exotic. Several of them are direct side effects of Microsoft's hardening against certificate spoofing from the May 2022 update (KB5014754). That update introduced the SID security extension in certificates to end weak certificate-to-account mapping. Wherever the associated switches are set only halfway or were deliberately rolled back, a new attack surface opens up instead. Rather than numbering eight techniques mechanically, this article follows their shared mechanism, because that is also where the defence falls out fastest.

Weak Certificate Mapping: ESC9, ESC10 and ESC16

It all comes down to one question here: how does a domain controller link a presented certificate to an account? Since KB5014754, a certificate carries the szOID_NTDS_CA_SECURITY_EXT extension (OID 1.3.6.1.4.1.311.25.2) for this, which pins the account's SID. How strictly the DC checks that binding depends on the StrongCertificateBindingEnforcement switch: 0 turns the check off, 1 is compatibility mode, and only 2 enforces it fully. The next three techniques all rely on this binding crumbling somewhere.

With ESC9 (No Security Extension), that happens at the template level. If a template carries the CT_FLAG_NO_SECURITY_EXTENSION flag (0x80000 in msPKI-Enrollment-Flag), the SID extension is absent from every certificate it issues. Anyone holding enrollment rights on such a template who can also write to a victim's userPrincipalName attribute changes the UPN to that of a privileged account, requests the certificate and logs on as that account, as long as the DCs are not running in mode 2. Only doing both helps here: take the flag off the template and enforce strong binding.

ESC10 (Weak Certificate Mappings) reaches the same goal without any template flag by going straight for the DC configuration. Sometimes StrongCertificateBindingEnforcement is simply set to 0, so a missing or non-matching SID extension bothers no one. Sometimes the registry value CertificateMappingMethods under the Schannel key contains the 0x4 bit, which re-enables the weak, purely UPN-based mapping. Both paths lead to the same trick with the manipulated userPrincipalName, and you close both by raising the binding to 2 and removing the 0x4 bit.

Where ESC9 affects a single template, ESC16 breaks the protection for the entire CA at once. If the OID 1.3.6.1.4.1.311.25.2 sits in the policy module's DisableExtensionList, no certificate leaves the CA with the SID extension anymore, no matter which template it came from. Suddenly any template with a client authentication EKU works as an escalation path as soon as the weak binding applies. The entry has to disappear from the list, and once again StrongCertificateBindingEnforcement = 2 is the second half of the answer.

Relay and Host Compromise: ESC11 and ESC12

ESC11 is the RPC sibling of ESC8. The NTLM relay runs not over the HTTP web enrollment page but over the ICertPassage RPC interface (ICPR). The way in is a missing IF_ENFORCEENCRYPTICERTREQUEST flag on the CA, because then it accepts unencrypted RPC requests. An attacker coerces a machine account into authenticating, relays that to the RPC endpoint and has a certificate issued on its behalf. Enabling enforced encryption and turning on Extended Protection for Authentication takes the ground out from under the attack.

ESC12 sits slightly apart, because it is not a classic configuration error but describes access to the CA's private key through an already compromised CA host. If the key lives on a YubiHSM, its authentication key ends up in the registry. Anyone with a sufficiently privileged shell on the CA server reads it out, uses it to reach the CA key and issues arbitrary „golden" certificates. In practice this is the continuation of ESC5, and above all a reminder that a CA server deserves the same protection as a domain controller: as few administrators as possible, consistent Tier-0 isolation and an eye on every backup.

Privileges From Certificate Metadata: ESC13 and ESC14

ESC13 turns a perfectly legitimate AD feature against its owner. An issuance policy can be coupled to an AD security group through the msDS-OIDToGroupLink attribute. If a template carries such a policy, everyone who authenticates with the certificate issued from it is credited with the privileges of the linked group at logon, without ever having been a member. When the link points to a privileged group, a bare enrollment right on the template is enough for escalation. An audit therefore pays to look specifically at every msDS-OIDToGroupLink link and at who is even allowed to enroll on the affected templates.

ESC14 uses the altSecurityIdentities attribute, which maps a certificate explicitly to an account, for instance via issuer and serial number. If an attacker can write that attribute on a victim, they place a mapping there to a certificate they hold themselves and then authenticate as the victim. The weaker the mapping format, the easier the forgery: a mapping by subject alone is far more attackable than a strong one via issuer and serial number or the key identifier. Write access to altSecurityIdentities should be tightly scoped accordingly, and only strong mapping types should be accepted at all.

EKUwu: ESC15 and CVE-2024-49019

ESC15 is the most recent of the techniques covered here and better known under the name EKUwu, officially tracked as CVE-2024-49019. It affects certificate templates of schema version 1, which have an awkward property: they do not validate the application policies supplied in the Certificate Signing Request. Because application policies take precedence over the template's EKUs during authentication, an attacker with enrollment rights can simply write an arbitrary policy into the request, such as Client Authentication or Certificate Request Agent, and force a purpose onto the certificate that the template never intended. If the template also allows the subject to be supplied freely, identity takeover is only one step away.

Two details matter for context. By default all v1 templates are vulnerable, but the attacker needs an enrollment right, and the moment someone clones a v1 template, Windows automatically raises it to version 2, at which point the gap disappears. Microsoft fixed the underlying problem with the updates of 12 November 2024. To be safe, apply that patch, replace any remaining v1 templates with v2 equivalents and review who is allowed to enroll on the old ones.

Detection and Hardening in Practice

As different as the eight techniques are in detail, their common denominator is small: a binding between certificate and account that is too weak, and enrollment and write rights handed out too generously. Three levers take the air out of most of the attacks. StrongCertificateBindingEnforcement belongs on 2 once all certificates carry the SID extension. The weak 0x4 bit in CertificateMappingMethods should be gone. And both RPC and HTTP enrollment can be secured through enforced encryption and EPA.

The concrete misconfigurations become visible with the same tools attackers use. Certipy finds what can be exploited on the offensive side; on the defensive side, PSPKIAudit or Locksmith do the same. They reveal which templates carry the CT_FLAG_NO_SECURITY_EXTENSION flag, which msDS-OIDToGroupLink links exist, which templates are still on schema version 1 and where the CA flags hold dangerous values. The important part is not to tick this audit off as a one-time job, because every new template and every freshly delegated permission can shift the picture again.

Conclusion

ESC9 through ESC16 make it clear that AD CS remains a rich attack surface well beyond the familiar ESC1–ESC8 classics, precisely because some of these techniques grow out of hardening that was only half implemented. Anyone who takes their certificate infrastructure seriously therefore looks not only at the template ACLs but equally at the binding switches on the DCs, the CA flags, the OID group links and the leftover v1 templates. As part of an internal penetration test, we at turingpoint examine the entire AD CS chain including these newer techniques and deliver a risk-prioritized hardening recommendation that combines offensive findings with concrete defender measures.