Active Directory Certificate Services

In this blog post, we show the steps necessary to recreate attacks on AD CS in a test environment. We also show how defenders can identify potential vulnerabilities in their environment.

A week before this blog post was published, a new whitepaper from Will Schroeder (@harmj0y) and Lee Christensen (@tifkin_) sent waves through the cyber security circles. In it, they dived into the security of Active Directory Certificate Services (AD CS), showing eight security weaknesses often found in enterprise environments. Intrigued by this new target, we at avantguard cyber security started getting to know AD CS in our testing environment. As a result, we successfully (mis)configured and attacked the certificate services, allowing complete domain take-over in a rather unknown and therefore stealthy fashion, even persisting across password changes of the impersonated user.

In this blog post, we show the necessary steps to recreate this attack in a testing environment. Additionally, we show how defenders can identify possible weaknesses in their environment. Since Microsoft knows and warns about these misconfigurations (more about that later) and an attacker would need GUI access to a machine, we feel showing these steps is justifiable. The authors of the whitepaper will present their research at the Black Hat 2021 and release two offensive tools, which would allow attackers to perform this attack in a command & control (C2) scenario. Preemptive IOCs and Yara rules are already published.

AD CS are complicated and are therefore often reduced to being able to provide trusted certificates in a domain, which can be used for TLS encryption. By creating a trusted root certificate authority (CA) and issuing certificates signed by this CA, internal communications in the domain can be encrypted and the users computers can be made to trust this CA, so no certificate warnings will appear. However, besides this, a public key infrastructure (PKI) like AD CS can be used for a plethora of other use cases including message signing and also authentication.

We will not go into detail how authentication works in a PKI, as there are already well-written and understandable ressources to this topic. From an attacker's point of view, only a few steps are important anyways. The client requests a certificate from the CA and tells the CA, who the certificate should be issued to. This is also called enrolling. Usually, the user will only request a certificate for himself and the CA checks its certificate template to see if the request can be completed or not. The user - or any identity - the certificate is issued to is called the subject. If the request is allowed, the CA generates and issues a certificate for the subject.

Now, because AD CS can be used for so many different things, some functionalities can become severe security weaknesses. The functionality that led to the discovery of these attacks is related to certificates that can be used for multiple hostnames. If, for example, an organisation has multiple systems it wants to issue TLS certificates to (such as test1.domain.local and test2.domain.local), it can issue one certificate to test1.domain.local but with a subject alternative name (SAN) of test2.domain.local. The resulting certificate has two subjects, allowing it to be used on both systems. This is very convenient, but paired with a certificate's ability to authenticate a user it can lead to severe misconfigurations. As will be shown, an attacker can request a certificate for himself as the subject and another user as the SAN, giving him a certificate that can authenticate him as another user. With the help of other popular tools like Rubeus or Kekeo, this certificate can be used to request a Kerberos ticket-granting ticket as the other user.

Preparing the testing environment
The required environment for this attack consists only of a domain controller (DC) with AD CS and one client, as well as two users, one with low and one with high privileges. We installed and configured the Active Directory Certificate Services with default settings on the domain controller and had to restart the client for the CA to be recognised and trusted by the client. Then some additional steps had to be done on the domain controller. First, the default User certificate template had to be duplicated as User(opensubject). On this new template, the "Domain Users" group was given enrollment rights and the subject name was changed from "Build from this Active Directory information" to "Supply in the request". This change led to a warning message, informing about the potential dangers of this change.

Configuration for the default User certificate template

Warning message when setting the subject to be supplied in the request

To allow another attack from the whitepaper, the EDITF_ATTRIBUTESUBJECTALTNAME2 flag had to be set on the CA. This flag should not be set in a production environment if the consequences are not clear and dealt with! To check if this flag is set on your CA, the following command can be used.

certutil can be used to check which flags are set on the CA

Lastly, the certificate template had to be enabled on the CA.

In certsrv, templates can be enabled for a CA

With this, the misconfiguration has successfully been completed. These configurations might not seem overly realistic, but for someone who has to set up a PKI in his organisation, encountering all kinds of problems, these configurations are convenient and even recommended on some forums.

For attackers and defenders alike, finding these misconfigured templates and certificate authorities is desirable. PSPKIAudit was created for this task and is very easy to use. After importing the module into Powershell, the Invoke-PKIAudit function can be called. Without additional parameters, the function automatically finds the CAs in the domain and the certificate templates offered by them. By checking different permissions, like if a user can supplement an SAN, the CA and templates are marked as misconfigured, together with the attack ID. The two screenshots below show the results for our environment.

Our CA is vulnerable to the ESC6 attack because of the EDITF_ATTRIBUTESUBJECTALTNAME2 flag

The User(opensubject) template allows all domain users to enroll and supply a SAN

We want to re-emphasise our advice to defenders and administrators to check your environment for any potential issues. With this, we will now show how to exploit the misconfigurations that Invoke-PKIAudit has identified.

In this scenario, the attacker has GUI access to a system with the credentials of a low privileged user that is only part of the "Domain Users" group.
- Low privileged user: Agaid1973
- High privileged user: Administrator  
The attacker knows that there is a misconfigured certificate template, allowing every member of "Domain Users" to enroll and supply alternative names for the subject. He can then use certmgr.msc to request new certificates for the user Agaid1973. As a side note: if there was a template allowing enrollment for "Domain Computers", an attacker would need local administrator privileges and would have to use certlm.msc to manage certificates for the local machine instead of the user.

Personal > Right-click on Certificates > All Tasks > Request New Certificate...

By using the Certificate Enrollment wizard, getting a new certificate is simple.

We can only choose the current Active Directory Enrollment Policy

The wizard even shows that more information is required to enroll for this template

When clicking on the message to configure the additional settings, another dialog opens. Here, four steps have to be done.

Set a name for the requested certificate

Enter the low privileged user's CN as the Subject and the high privileged user's user principal name (UPN) as the alternative name

Make the private key of the certificate exportable (set by default)

Check that the correct CA is used for the certificate

With this, the certificate request can be sent and if everything is correct, a new certificate will be issued.

The certificate was successfully requested

A first indicator if the subject was indeed read from the request is the text in the column "Issued to" in the overview below. If the text is the CN of the user we entered, the subject was most likely read from our request. If it is the full name of the user, the CA built the subject from Active Directory information instead.

The first certificate can be used for our attack, the second and third will not work

The certificate has to be exported so it can be used in further steps. Again, the wizard makes it easy.

We want to export the private key for our certificate

Default choices are sufficient

Protect your certificate with a password

Choose a save location for the certificate

Finish the wizard

Now, this certificate can be used with Rubeus to request a Kerberos TGT for the user defined in the SAN.

Initially, the user Agaid1973 has a TGT for himself

Using Rubeus, the certificate is used to request a TGT for Administrator

Before the new TGT can be imported, the current TGT has to be purged

The import was successful

With the Administrator's TGT, it is possible to enter a Powershell session on the domain controller

That's it! Our certificate is valid for a year, in other environments a certificate might even be valid for five years. A password change for the Administrator user will not stop this attack, the certificate would have to be revoked on the CA. However, in the overview, the certificate is issued to the low privileged user and the alternative names are not shown, so finding these certificates could prove to be difficult without additional measures.

We hope this blog post has helped in understanding the issue and recreating it in a testing environment. We are looking forward to the release of the two offensive tools that will remove the need for a GUI and will be testing further attacks in our lab.  

Stay tuned for further blog posts about red teaming, security research and penetration testing!


Similar posts