Skip to main content
ESC3 is a misconfiguration in Active Directory Certificate Services (AD CS), which stems from a dangerous Extended Key Usage (EKU). Specifically, if a certificate template has been configured with the Certificate Request Agent (1.3.6.1.4.1.311.20.2.1) EKU, the certificate can be used to sign certificate requests “on-behalf-of” other users.
The abuse scenario is a two-step process:
  1. Request and obtain a Certificate Request Agent (Enrollment Agent) certificate.
  2. Use the Enrollment Agent certificate to request certificates on behalf of other users.

​
The ‘Enrollment Agent’ Certificate

The following criteria comprise an ESC3 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 the Certificate Request Agent (1.3.6.1.4.1.311.20.2.1) Extended Key Usage (EKU).
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
Once we have identified a vulnerable ESC3 certificate template that our attacker-controlled user has enrollment rights for, we can request a certificate based on the template. This can be done using the request command from Certify. 
Certify.exe request --ca ca01.corp.local\CORP-CA01-CA --template CustomEnrollmentAgent
When the certificate has been issued, it is printed to the console in a base64-encoded format. This will be used in the next step.

​
The ‘On-Behalf-Of’ Certificate

The following criteria comprise an “on-behalf-of” enrollable template:
  • The enterprise CA does not implement enrollment agent restrictions.
    • Otherwise, the attacker-controlled user most likely cannot act as an enrollment agent.
  • 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 certificate template adheres to one of the following conditions depending on its schema version.
    • It has schema version 1 (which has no concept of issuance requirements / authorized signatures).
    • It has schema version 2 (or above) and a Required Application Policy matching the EKU of the enrollment agent.
  • 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)
We can search for certificate templates with these conditions using the enum-templates --filter-request-agent command from Certify. For more information about the command and its parameters, please refer to the Command Overview page.
According to this blogpost, if the enrollment agent certificate has both the Certificate Request Agent and the Any Purpose EKUs, it can only act as an enrollment agent (i.e. enroll “on-behalf-of” other users) for certificate templates that have schema version 1.
Certify.exe enum-templates --filter-enabled --filter-request-agent --hide-admins
Once we have identified a suitable certificate template that our attacker-controlled user has enrollment rights for, we can use the enrollment agent certificate to sign our certificate request and enroll “on-behalf-of” another user (e.g. Administrator). This can be done using the request-agent command from Certify. 
Certify.exe request-agent --ca ca01.corp.local\CORP-CA01-CA --template User --target Administrator --agent-pfx MIACAQMwgAYJKoZIhvcNAQcBoIAkgASCA+gwgDCABgkqh...
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](/GhostPack/Rubeus-mdx/commands/ticket-requests/asktgt#authentication-methods) command by setting the /certificate: parameter to the output certificate.
When requesting a TGT with a certificate, ensure to add the /enctype:aes256 to match the highest standard encryption.
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}