Press "Enter" to skip to content

Active Directory: Exploiting Certificate Templates

Last updated on November 20, 2022

Today I would like to talk about a vulnerability that I have found frequently in the Red Team exercises I have participated in. It is the exploitation of misconfigured Active Directories Certificate Templates.

Context

First of all, let’s put a bit of context to the scenario we find ourselves in. We assume that we have access to an Active Directory because we have compromised the account of the user iyates. During this proof of concept, I will be using Cobalt Strike as the C&C, but it is not required at all and you could use any other C&C, like Mythic.

We can check that our user belongs to the group “Domain Users”.

After enumerating and analysing the system, we also found that there is one user who belongs to the Domain Admins group, the user nglover:

Our goal is to access the Domain Controller. With our user, we can see that we do not have privileges to list the Domain Controller DC-1:

Certificate Templates

Enough context. Let’s see how we can abuse Certificate Templates to gain access to the Domain Controller.

Certify is a tool that allows us to enumerate and exploit configuration errors in the Certificate Services of an Active Directory. Using the cas parameter we can enumerate the root Certificate Autority:

As well as the Enterprise Certificate Authorities (which are integrated with the AD) and the Certificate Templates it offers:

This is a good time to talk about Certificate Templates.

In an AD, Certificate Services are used in order to build a public key infrastructure. A Certificate Template defines the rules and policies that a Certificate Authority (CA) uses when it receives a request for a certificate. There are usually several predefined templates that make it easier to request certificates depending on what they are needed for, and that contain settings such as how long a certificate is valid for, what it is used for, who can request it, etc.

In this image from https://posts.specterops.io/ you can see very well the process of how to request a certificate:

With Certify we can find the certificates that are misconfigured and can be abused, using the find /vulnerable parameter.

Let’s analyse the data of “VulnerableUserTemplate“. It is a template offered by the Certificate Authority CA-1, and the flag “ENROLLEE_SUPPLIES_SUBJET” allows the user requesting a certificate using this template to indicate any SAN (Subject Alternative Name). In other words, the user who uses this template to request a certificate can request it on behalf of another user.

In addition, this certificate also has the “Client Authentication” flag, which allows using the certificate for authentication.

Finally, we can see that the “DEV\Domain Users” group has enrolment rights, so any user of this group can request a certificate using this template.

Attack

With this information, the attack route is clear: we are going to use this template to request a certificate on behalf of the user nglover, who is Domain Admin. With this certificate, we will authenticate as that user and we will be able to access the Domain Controller DC-1.

Certify allows us to request the certificate using the vulnerable template:

We are going to use Rubeus to authenticate using the certificate. To do this, we need to modify it a bit. First, we have to modify it to change the extension from cert.pem to cert.pfx, and then we have to Base64 encode it. We can do this on Linux using openssl:

Now we just need to use the Rubeus tool to request a Ticket Granting Ticket (TGT) with the user nglover using this certificate (which is possible because the template had Client Authentication).

Next, also using Rubeus, we will create a “sacrifice” login session with which we authenticate ourselves as the nglover user in Kerberos using the TGT that we have obtained. Note that it doesn’t matter what password we use because what authenticates us is the TGT, using the “Pass the ticket” technique:

This command would work like “runas /netonly” , and Rubeus shows the Process ID of the process it has created and in which it has injected the access token, which we can “steal” using the steal_token command of Cobalt Strike (this command is in most C&C, for example in Mythic it is in the Apollo agent):

By impersonating iyates, we can now request access to the Domain Controller DC-1, and since we do so from a process that has a valid access token, we will be able to see the content:

And that’s it. It is very common to find this vulnerability in the Active Directories of many clients. It is always very important to configure the certificates properly because a bad configuration can put the whole active directory at risk. 

Note: It is possible to abuse templates and perform this attack if the user you control has the “WriteOwner“, “WriteDacl” or “WriteProperty” property.

I hope you found this useful. I’m trying to specialize in Red Teaming, so it’s very likely that the next posts will include more Active Directory related content.

Lethani.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Mission News Theme by Compete Themes.