ESC9

No Security Extension on Certificate Template

Description

"ESC9 vulnerabilities arise when a certificate template is explicitly configured not to include the szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) security extension in the certificates it issues. This extension, which contains the requester's SID, was introduced by Microsoft as part of the May 2022 "Certifried" updates (CVE-2022-26923 and KB5014754) to enable "strong certificate mapping". Strong mapping allows DCs to reliably and securely map a presented client certificate to a specific user or computer account in Active Directory using its SID.

A template can be configured to omit this extension by setting the CT_FLAG_NO_SECURITY_EXTENSION flag (value 0x80000) in its msPKI-Enrollment-Flag attribute within Active Directory. If a certificate is issued from such a template:

• It will lack the primary SID security extension (szOID_NTDS_CA_SECURITY_EXT).

• This forces the KDC during Kerberos PKINIT authentication, or Schannel during TLS authentication, to rely on weaker, legacy mapping methods if the domain is not yet in "Full Enforcement" mode for strong certificate binding. These weaker methods might include mapping based on the UPN or DNS name found in the certificate's SAN.

The vulnerability of ESC9 becomes exploitable under these conditions:

• Domain Controller Certificate Binding Mode: The StrongCertificateBindingEnforcement registry key on Domain Controllers (under HKLM\SYSTEM\CurrentControlSet\Services\Kdc) is set to 1 (Compatibility Mode) or 0 (Disabled).

  • In Compatibility Mode (which was the default after the May 2022 patches until February 2025), DCs attempt strong mapping first (using the SID extension). If the SID extension is absent, they fall back to weaker mapping methods based on SAN UPNs or DNS names.

  • If set to 0 (Disabled), strong mapping is not enforced, and weak mappings are allowed.

• Client Authentication EKU: The ESC9 template must allow for client authentication (e.g., include "Client Authentication" EKU).

• Enrollment Rights: An attacker-controlled account must have enrollment rights for this template.

ESC9 can be exploited in a couple of primary ways:

1. With UPN Manipulation (in Compatibility Mode or Disabled Mode): If an attacker has control over an account's userPrincipalName attribute (e.g., through GenericWrite permission) and that account can enroll in the ESC9 template, the attacker can:

   • Temporarily change this "victim" account's UPN to match the sAMAccountName (or desired UPN) of a target privileged account (e.g., an administrator).

   • Request a certificate as the victim account. The issued certificate will contain the manipulated UPN but will lack the SID security extension (due to ESC9).

   • Revert the UPN change on the victim account.

   • Use the obtained certificate to authenticate. The KDC, finding no SID extension and operating in compatibility mode, will use the UPN from the certificate's SAN. Since this UPN now matches the target privileged account, the attacker impersonates that account.

2. Combined with ESC6 (CA allows SAN specification): This is a more powerful combination. If the CA is also vulnerable to ESC6 (meaning the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set on the CA, allowing requesters to specify arbitrary SANs via request attributes), an attacker can:

   • Request a certificate from the ESC9 template (ensuring no SID security extension is present).

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

   • The issued certificate will lack the SID security extension (due to ESC9) but will contain the attacker-supplied SAN SID URL (due to ESC6).

   • In this case, the KDC (even in "Full Enforcement" mode, StrongCertificateBindingEnforcement=2) will use the SID from the SAN URL for authentication, leading to impersonation." — Oliver Lyak

Configuration

For this demonstration we will use standalone ESC9, since chained with ESC6 hasn't been shown yet on HTB and it would be a nice privesc chain. We are basically setting this up like on the Certified box, made by me!

For this configuration we firstly have to create a template where we can enroll in (I'll duplicate "User" and name it ESC9). When that's done, enable it on the CA and we should be done of configuring Certificate Templates.

Open regedit and browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc . There, create a new DWORD key named StrongCertificateBindingEnforcement set to 0 or 1. This will set the enforcement security for the certificate to disabled (0) or compatibility mode (1).

Now browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL and add a new DWORD key named CertificateMappingMethods with value 0x4

Note that we're saying 0x4 and not 4, which is not the same. It should look like this on the Registry Editor.

Add the CT_FLAG_NO_SECURITY_EXTENSION to the template:

certutil -dstemplate "ESC9" msPKI-Enrollment-Flag +0x00080000

Restart the services.

Restart-Service Kdc
Restart-Service CertSvc

Once that's done, we need to grant GenericAll or GenericWrite over an account, since this attack requires writing the controlled account's userPrincipalName.

Written by ruycr4ft