ESC9 vs. ESC16: same flaw, different blast radius

ESC9 and ESC16 are two of the numbered escalation techniques (ESC) cataloged for Active Directory Certificate Services (AD CS), and they're the same vulnerability at different scopes. Both strip the security identifier (SID) security extension from issued certificates, which lets an attacker impersonate another account through weak certificate mapping. ESC9 does it on a single certificate template. ESC16 does it across every certificate a certificate authority (CA) issues.

If you remediated ESC9 a couple of years ago, that tells you nothing about ESC16.

What is ESC9?

ESC9 is a template setting. When CT_FLAG_NO_SECURITY_EXTENSION is set in a template's msPKI-Enrollment-Flag attribute, certificates issued from that template don't carry the SID extension (szOID_NTDS_CA_SECURITY_EXT). That extension is what lets a domain controller (DC) tie a certificate to one specific account. Without it, the DC falls back to mapping on the user principal name (UPN).

The attack needs three things: an attacker with write access to a victim account's UPN (GenericWrite is enough), enrollment rights on a client-authentication template with the flag set, and a DC that isn't enforcing strong certificate mapping. The attacker changes the victim's UPN to match a privileged account, enrolls, puts the UPN back, and authenticates with the certificate as the privileged user.

Oliver Lyak documented ESC9 in August 2022, and many scanners can find it, including Netwrix PingCastle.

What is ESC16?

ESC16 gets to the same place without touching a template. If the OID 1.3.6.1.4.1.311.25.2, which is the szOID_NTDS_CA_SECURITY_EXT SID security extension, is listed in the CA's DisableExtensionList policy module registry value, the CA stops adding the SID extension to everything it issues. Every template behind that CA now behaves as if ESC9's flag were set, including templates nobody has reviewed in years.

An environment can end up with this setting for several reasons: a compatibility fix for a third-party tool, a migration, or a legacy application that doesn't handle the extension. It's a single registry entry and easily overlooked, and it quietly cancels the protection you built template by template.

The setting isn't a template attribute. It's CA configuration, and many certificate hygiene reviews never open the CA's own policy module settings. An organization can be clean on every template, have the report to prove it, and still be exposed through the CA. If you scanned for ESC9 years ago and haven't looked at your CAs since, an attacker may still be able to carry out the same impersonation attack through ESC16.

Does strong certificate mapping protect you?

Partly. Both techniques depend on the DC accepting weak mappings, and DCs enforcing strong certificate binding blunt both of them. Since the September 2025 Windows updates, patched DCs run in full enforcement and the compatibility-mode setting is no longer supported, so a fully patched domain stops bare ESC9 and ESC16. That still leaves two gaps: any DC that missed those updates, and chains where the attacker can supply their own SID in the certificate request, such as ESC16 combined with ESC6 or ESC15. Check enforcement on every DC, and check the CA anyway.

How do you check for and fix both?

You need two checks, because ESC9 lives on templates and ESC16 lives on the CA.

Check for ESC9 (certificate templates)

1. Run a PingCastle scan.
2. Open the report and search for CT_FLAG_NO_SECURITY_EXTENSION (the risk is A-CertTempNoSecurity). Look for the text "At least one certificate template has the flag CT_FLAG_NO_SECURITY_EXTENSION set."
3. If that text isn't there, none of the scanned templates carry the flag. If it is there, remove the flag from the affected templates.

Check for ESC16 (the CA)

On each CA, run:

      certutil -getreg policy\DisableExtensionList
      

If the OID 1.3.6.1.4.1.311.25.2 appears in the output, that CA is stripping the SID extension from everything it issues. Remove it from the list unless you have a documented reason for it.

To fix it, remove the OID and restart Certificate Services so the change takes effect:

      certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2
net stop certsvc
net start certsvc
      

Run certutil -getreg policy\DisableExtensionList again afterward to confirm the OID is gone. Certificates already issued without the extension stay that way, so review them if you suspect the setting was abused. If an application needed the setting, test it before rolling this out widely.

Then confirm enforcement: check that your DCs are enforcing strong certificate mapping, since that blunts both techniques. On a DC with current updates, that's the default. For the rest of your CA's exposure, including ESC8 on web enrollment, review the risky AD CS settings that often show up alongside these two.

How do you catch the next change?

For ESC9 going forward: the template flag lives in Active Directory, which means a change to it is a change to an AD object. Netwrix Threat Prevention monitors AD changes in real time and can block them, so someone setting CT_FLAG_NO_SECURITY_EXTENSION on a template can be stopped before it takes effect, not found at the next assessment.

For ESC16 going forward: the setting sits in the registry on the CA server, not in AD, so it needs its own coverage: registry auditing on the CA hosts feeding your SIEM, plus the periodic check above. Netwrix also correlates certificate-based logons with issuance and flags missing SID extension scenarios, so abuse of the setting shows up even if the registry change itself slips past.