Skip to main content
ESC15 is a vulnerability disclosed by Justin Bollinger in this blogpost, which details an insecurity in the way Active Directory Certificate Services (AD CS) handles application policy extensions in certificate requests for certificate templates with schema version 1.
According to the MSRC security guidance for CVE-2024-49019 (EKUwu), the vulnerability has been patched in November 2024.

​
Vulnerability Details

In unpatched environments, if a certificate template has schema version 1 and allows the requester to supply arbitrary subject details, it is possible to include a custom application policy extension with the certificate request and have it embedded into the issued certificate. This allows an attacker to inject arbitrary application policies into certificate requests for templates whose Extended Key Usages (EKUs) does not contain a desired value, potentially allowing for the following attacks:
  • Inject the Client Authentication (1.3.6.1.5.5.7.3.2) application policy and carry out an ESC1 attack.
  • Inject the Certificate Request Agent (1.3.6.1.4.1.311.20.2.1) application policy and carry out an ESC3 attack.

​
Detection

We can search for certificate templates with these conditions using the enum-templates --filter-vulnerable command from Certify. For more information about the command and its parameters, please refer to the Command Overview page. 
Certify.exe enum-templates --filter-vulnerable --hide-admins

​
Exploitation

Once we have identified a vulnerable ESC15 certificate template that our attacker-controlled user has enrollment rights for, we can request a certificate based on the template, and include a Subject Alternative Name (SAN) for a target user that we want to impersonate (e.g. Administrator) as well as the application policy we want to inject (e.g. Client Authentication). This can be done using the request command from Certify. The SAN can be in either of the formats UserPrincipalName (--upn), DnsName (--dns), or Rfc822Name (--email). For environments where Strong Certificate Mapping is enabled, the security identifier (SID) of the target user must also be supplied with the --sid parameter. 
Certify.exe request --ca ca01.corp.local\CORP-CA01-CA --template WebServer --upn Administrator --sid S-1-5-21-976219687-1556195986-4104514715-500 --application-policy 1.3.6.1.5.5.7.3.2
Unfortunately, we cannot use the issued certificate to authenticate over Kerberos PKINIT with Rubeus, as the protocol evaluates only the Extended Key Usage extension of an authentication certificate. However, the LDAP Schannel protocol also evaluates the Application Policy extension of an authentication certificate, so we can authenticate to LDAPS using PassTheCert.
First, we write the issued certificate to a file (cert.pfx). 
[IO.File]::WriteAllBytes("cert.pfx", [Convert]::FromBase64String("MIACAQMwgAYJKoZIhvcNAQcBoIAkgASCA+gwgDCABgkqh..."))
Then, we can authenticate over LDAP Schannel with PassTheCert and confirm that we have successfully elevated our privileges by impersonating the Administrator user. 
PassTheCert.exe --server dc01.corp.local --cert-path cert.pfx --whoami