The ADCSESC13 edge indicates that the principal has the privileges to perform the ADCS ESC13 abuse against the target AD group. The principal has enrollment rights on a certificate template configured with an issuance policy extension. The issuance policy has an OID group link to an AD group. The principal also has enrollment permission for an enterprise CA with the necessary template published. This enterprise CA is trusted for NT authentication and chains up to a root CA for the forest. This setup allows the principal to enroll a certificate that the principal can use to obtain access to the environment as a member of the group specified in the OID group link.
Abuse Info
An attacker may perform this attack in the following steps:
Step 1: Request enrollment in the affected template
On Windows, use Certify to request enrollment in the affected template, specifying the affected certification authority:
Certify.exe request /ca:rootdomaindc.forestroot.com\forestroot-RootDomainDC-CA /template:"ESC13"
On Linux, use Certipy to request enrollment in the affected template, specifying the affected enterprise CA:
certipy req -u john@corp.local -p Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC13
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: Create PFX format of certificate (Windows only)
Save the certificate as cert.pem and the private key as cert.key.
Convert the emitted certificate to PFX format:
certutil.exe -MergePFX .\cert.pem .\cert.pfx
Step 3: Request a ticket granting ticket (TGT)
On Windows, use Rubeus to request a TGT from the domain, specifying the attacker identity, the PFX-formatted certificate created in Step 2, and the certificate password:
Rubeus asktgt /user:attacker /domain:forestroot.com /certificate:cert.pfx /password:asdf /ptt
On Linux, use Certipy to request a TGT from the domain, specifying the certificate created in Step 1 and the IP of a domain controller:
certipy auth -pfx john.pfx -dc-ip 172.16.126.128
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.
References
This edge is related to the following MITRE ATT&CK technique:
Abuse info references
Updated