Skip to main content
ESC9 is a misconfiguration in Active Directory Certificate Services (AD CS), which stems from insecure management of security features. Specifically, if the Enrollment Flag attribute for a certificate template includes the NO_SECURITY_EXTENSION flag, the certificate authority will not include a SID security extension in certificates issued from this template.
The misconfiguration was initially disclosed by Oliver Lyak in this blogpost.

​
Vulnerability Criteria

The following criteria comprise an ESC9 vulnerability:
  • The enterprise CA grants enrollment rights to the attacker-controlled user.
    • Otherwise, the user would be unable to request any certificates from the CA.
  • The certificate template grants enrollment rights to the attacker-controlled user.
    • Otherwise, the user would be unable to request certificates based on the specific template.
  • The “manager approval” feature is disabled for the certificate template.
    • Otherwise, a “CA Manager” would have to manually review and approve the certificate request.
  • The “authorized signature” feature is disabled for the certificate template.
    • Otherwise, an enrollment agent would need to sign the certificate request on behalf of the requester.
  • The certificate template defines an Extended Key Usage (EKU) that enables client authentication.
    • Client Authentication (1.3.6.1.5.5.7.3.2)
    • PKINIT Client Authentication (1.3.6.1.5.2.3.4)
    • Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
    • Any Purpose (2.5.29.37.0)
    • Subordinate CA (No EKUs)
  • The certificate template has been configured to not include the SID security extension.
    • Otherwise, the user can only request certificates that are strongly mapped to itself, and cannot impersonate others.

​
Exploitation Methods

There are currently two documented methods for exploiting this misconfiguration:
If ESC6 is enabled, we can supply an arbitrary Subject Alternative Name (SAN) for the vulnerable certificate. Since this uses the URL-based SAN format which contains the SID of the target user, this attack method will work even if Strong Certificate Mapping is enabled. For more information about this scenario, please refer to the attack described in ESC6.
If Strong Certificate Mapping is disabled or in compatibility mode and we have GenericWrite rights on a principal that we can access and which has enrollment rights on the certificate template, we can abuse certificate mapping weaknesses to impersonate a target principal. For this attack to be possible, the certificate template must define a UPN-mappable or DNS-mappable flag in its Certificate Name Flag attribute:
  • SUBJECT_ALT_REQUIRE_UPN
  • SUBJECT_ALT_REQUIRE_SPN - This flag relies on the userPrincipalName attribute, despite the name hinting at SPN.
  • SUBJECT_ALT_REQUIRE_DNS - This does not work if the target is a user (as they do not have the dNSHostName attribute)

​
Weak Certificate Mapping Attack Steps

The second method consists of the following steps:
  1. Temporarily modify a mapping attribute of the principal to match that of the target principal that we want to impersonate.
    • If the template has the SUBJECT_ALT_REQUIRE_UPN flag or the SUBJECT_ALT_REQUIRE_SPN flag, the userPrincipalName attribute of the attacker-controlled principal must match the userPrincipalName or sAMAccountName attribute of the target principal.
    • If the template has the SUBJECT_ALT_REQUIRE_DNS flag, the dNSHostName attribute of the attacker-controlled principal must match the dNSHostName attribute of the target principal.
  2. Request a certificate from the vulnerable template. The issued certificate will contain a Subject Alternative Name (SAN) based on the mapping attribute of our requesting user (which is identical to that of our target principal).
  3. Revert the temporary mapping attribute modification. The target principal is now the only user in the domain with an attribute that matches the one in our issued certificate.
  4. Authenticate as the impersonated user. This is possible because there is no SID security extension in the certificate (due to ESC9) and the mapping attribute of the certificate matches only our target principal (after we reverted our own changes).

​
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-enabled --filter-vulnerable --hide-admins

​
Exploitation Example

Once we have identified a vulnerable ESC9 certificate template that our attacker-controlled user has enrollment rights for, we can perform the weak certificate mapping attack. Since the certificate template contains the SUBJECT_ALT_REQUIRE_UPN flag, we must modify the userPrincipalName of our attacker-controlled user to match a target user that we want to impersonate (e.g. Administrator). 
Set-ADUser -Identity impersonator -UserPrincipalName 'Administrator'
Get-ADUser -Identity impersonator
We can then request a certificate based on the vulnerable template as the attacker-controlled user and obtain a certificate with a Subject Alternative Name (SAN) that contains the mapping attribute that will link to the target principal (e.g. Administrator). This can be done using the request command from Certify. 
Certify.exe request --ca ca01.corp.local\CORP-CA01-CA --template CustomNoExtension
Once we have obtained the certificate, we can revert our mapping attribute modifications. 
Set-ADUser -Identity impersonator -Clear UserPrincipalName
Get-ADUser -Identity impersonator
Now that only the target principal has a mapping attribute that matches the one in the issued certificate, we can authenticate as the target principal by presenting the issued certificate. This can be done using Rubeus with the asktgt command. 
Rubeus.exe asktgt /user:Administrator /certificate:MIACAQMwgAYJKoZIhvcNAQcBoIAkgASCA+gwgDCABgkqh... /ptt
Since the /ptt parameter was supplied to Rubeus when requesting the TGT, the ticket has been injected into the Kerberos ticket list, and we should be able to authenticate as the target user and access systems that the target user has access to. 
Invoke-Command -ComputerName DC01 -ScriptBlock { whoami }