Active Directory Certificate Services

Overview
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.

Background
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.

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.

Lastly, the certificate template had to be enabled on the 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.

Enumeration
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.

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.

Attack
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.

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

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

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

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 certificate has to be exported so it can be used in further steps. Again, the wizard makes it easy.

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

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!