ESC16

Security Extension Disabled on CA (Globally)

Description

"ESC16 describes a misconfiguration where the CA itself is globally configured to disable the inclusion of the szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) security extension in all certificates it issues. This SID extension, introduced with the May 2022 security updates (KB5014754), is vital for "strong certificate mapping", enabling DCs to reliably map a certificate to a user or computer account's SID for authentication.

When a CA has the OID 1.3.6.1.4.1.311.25.2 added to its policy\DisableExtensionList registry setting (under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA-Name>\PolicyModules\<PolicyModuleName>), every certificate issued by this CA will lack this SID security extension. This effectively makes all templates published by this CA behave as if they were individually configured with the CT_FLAG_NO_SECURITY_EXTENSION flag (as seen in ESC9).

The primary impact is that if Domain Controllers are not operating in "Full Enforcement" mode for strong certificate binding (StrongCertificateBindingEnforcement registry key value is not 2), they will fall back to weaker, legacy certificate mapping methods (e.g., based on UPN or DNS name found in the certificate's SAN). This reopens attack vectors similar to those exploited by the "Certifried" vulnerability (CVE-2022-26923) before the widespread adoption of strong mapping. Such a CA-level misconfiguration might occur if administrators, attempting to resolve compatibility issues after the May 2022 patches, opted to globally disable the new SID extension as a broad workaround instead of addressing issues on specific templates or client systems.

Alternative Cause for ESC16-like Behavior: An important note is that if a CA server itself has not been patched with the May 2022 security updates (KB5014754) or subsequent cumulative updates that include it, it will not be capable of issuing the szOID_NTDS_CA_SECURITY_EXT at all. In such a scenario, the CA behaves as if ESC16 were configured, because no certificates it issues will contain this extension. Given the current date, CAs should be well beyond this patch level, but unpatched legacy systems could still exhibit this behavior.

Exploitability of ESC16, similar to ESC9, depends on the DC's StrongCertificateBindingEnforcement setting:

1. With UPN Manipulation (in Compatibility Mode - StrongCertificateBindingEnforcement = 1 or 0): If an attacker has control over an account's UPN (e.g., via GenericWrite) and that account can enroll for any client authentication certificate from the ESC16-vulnerable CA, they can:

   • Change the victim account's UPN to match a target privileged account's sAMAccountName.

   • Request a certificate (which will automatically lack the SID security extension due to the CA's ESC16 configuration).

   • Revert the UPN change.

   • Use the certificate to impersonate the target.

2. Combined with ESC6 (CA also allows SAN specification via request attributes): This method is effective even if DCs are in "Full Enforcement" mode (StrongCertificateBindingEnforcement = 2). The attacker:

   • Requests any client authentication certificate from the ESC16-vulnerable CA (ensuring no SID security extension is added by the CA).

   • Simultaneously uses an ESC6 vulnerability on the same CA to inject the target's UPN and SID (formatted as a special SAN URL: URL=tag:microsoft.com,2022-09-14:sid:<VALUE>) into the certificate request.

   • The KDC, finding no SID security extension (due to ESC16) but seeing the SAN SID URL (due to ESC6), will use the SAN SID for authentication." — Oliver Lyak

Configuration

Similar to ESC9 and ESC10, ESC16 is about the security extension being disabled globally on the CA. We only need that and to be able to enroll in any template. Same as we did with ESC9, this attacks requires the attacker controlling an account (being able to change its UPN).

First disable the security extension and restart the services.

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.25.2
restart-service certsvc
restart-service kdc

Certipy should now show the CA being vulnerable to ESC16.

Written by ruycr4ft