Detecting Active Directory Certificate Services Abuse with Cortex XDR™

Executive Summary

Active Directory Certificate Services (AD CS) is a Microsoft server role which implements a public key infrastructure (PKI). It is used to manage and establish trust between different directory objects using digital certificates and digital signatures.

In June 2021, Will Schroeder and Lee Christensen released a white paper named Certified Pre-Owned about research conducted on AD CS. The paper demonstrates how an adversary can utilize and abuse the AD CS environment to elevate privileges, get a strong foothold and persistence within a network.

In this blog post, we’ll cover some concepts from the AD CS terminology, go over an abuse scenario and explain how customers can detect the attack using Cortex XDR.

AD CS Concepts and Overview

To better understand the abuse scenario and attacker goals, we will cover some AD CS concepts and an overview of the authentication process.

CA (Certificate Authority) - The PKI server is used for management and certificate issuing. A CA server can either be a standalone or an Enterprise CA that integrates with Active Directory.

Certificate - A X.509-formatted digitally signed document used for encryption, message signing, and/or authentication.

pfx - a certificate in PKCS#12 format.

Certificate Subject - The owner of the certificate.

SAN (Subject Alternative Name) - One or more alternate names that the Subject may go by.

Certificate Template - A collection of enrollment policies and certificate settings.

EKU (Extended/Enhanced Key Usage) — Object identifiers (OIDs) that describe how the certificate will be used.

CSR (Certificate Signing Request) — a message sent from an applicant to a CA requesting a signed certificate.

Certificate Enrollment - The process of obtaining a certificate based on a requested certificate template and security policies (done with the CSR).

Certificates can be used for encryption, message signing and authentication (as mentioned above). In order for a user to use a certificate, they first need to obtain an appropriate certificate for the needed usage and enroll for it.

The enrollment process involves a user requesting a certificate with a CSR based on a certificate template for the specific certificate usage. The CSR will be sent to the CA. If the template exists, and the user is allowed to enroll for a certificate and the template, based on the ACEs (Access Control Entries), the CA will issue a certificate.

In order for a user to use a certificate for authentication purposes, the certificate template will need to have one of the EKUs enabling authentication with the certificate.

The certificate enrollment process. (source: https://posts.specterops.io/certified-pre-owned-d95910965cd2)

Once the user has a signed certificate, they can authenticate to Active Directory using PKINIT or Schannel. Schannel is a security support provider that implements TLS\SSL; Windows uses it to perform security-related functions including authentication which can be integrated with LDAPS.

With several settings and misconfigurations, an attacker can abuse the AD CS components in order to obtain a certificate that enables authentication, and even authenticate as privileged users.

Misconfiguration Abuse Scenarios

AD CS misconfigurations can be leveraged by attackers in several ways.

One example is that an attacker can gain persistence to the network with an active user account by taking said account’s certificate. With an account’s certificate that allows authentication, the attacker can authenticate as the compromised user even when the user switches their password. The reason for this is that the certificate is used as an authentication mechanism, so the password is irrelevant for that type of authentication. (In the condition that the certificate has not expired).

In the same fashion, the persistence can be acquired using a machine account. Machine accounts also have certificates that can be used for authentication. With this said, an attacker will be able to extract a machine account certificate and use it to authenticate as the machine account. The abuser will have persistence for as long as the certificate is valid, even after the system changes its account’s password or a system wipe.

Furthermore, if the abuser is able to renew the certificate validation date, they can authenticate with the certificate for as long as it’s valid.

Another attack method is to obtain a user's NTLM hash via a TGT request when authenticating with PKINIT. Due to a “failsafe'' in authentication with PKINIT, the host can obtain an NTLM hash to support legacy authentication. This involves decrypting a PAC_CREDENTIAL_DATA structure.

Although persistence of regular users is nice, a prized goal for an attacker would be to gain higher privileges within the network. Several certificate template settings and scenarios will make this possible.

When unprivileged users are allowed to enroll in a template that enables them to become enrollment agents, privilege escalation is likely possible. An enrollment agent is essentially used to request a certificate “on behalf” of another entity, thus allowing the unprivileged agent to enroll for a certificate of a high privilege user.

Another method for enrolling as a different user is with SANs, which we will cover in the abuse scenario flow later.

There are several enrollment interfaces such as the Certification Authority (CA) Web Enrollment role service. The web enrollment service uses HTTP and NTLM authentication. Meaning, if the abuser can coerce an NTLM authentication to themselves, they can relay the authentication to the web enrollment (NTLM relay). The relay will allow them to enroll for the certificate and use it for authentication as the coerced NTLM hash user.

Other abuse possibilities can include downgrading other enrollment services such as CES\CEP to NTLM, and then employing NTLM relay for authentication. Modifying AD CS objects or security settings to enable EKUs, enrollment rights, etc.

We will now follow a scenario abusing AD CS for privilege escalation.

Abuse Scenario Flow

An abuse case for AD CS would be an attacker trying to achieve privilege escalation using SANs (with the correct EKU or other method mentioned below) in a certificate and authenticate as a privileged user (such as a Domain Administrator).

The scenario can be split into three stages:

Stage 1: Looking for misconfigurations in an AD CS environment

As a first stage, the attacker will perform AD CS reconnaissance. The recon will start with checking for available CA servers using Certify, a tool for enumerating and abusing misconfigurations in Active Directory Certificate Services.

Looking for available CAs and access rights with Certify

The next thing the attacker will want to find out is whether they can find a published certificate template that can be used for authentication.

In some cases, the attacker would prefer using PowerShell to do the reconnaissance commands instead of a new tool, since it might be blacklisted or alerted as malware by some vendors.

With PowerShell or Certify, the abuser can use LDAP to query Active Directory for misconfigured certificate templates with authentication and hopefully the Subject Alternative Name extension.

“The Subject Alternative Name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate.”

*(SAN’s are commonly used for web servers hosting multiple domains, thus only needing one certificate for the web server).

Essentially this extension can enable a user to request a certificate with an alternative name, and that name can also be one of a highly privileged target user.

Using PowerShell to LDAP query certificate templates with Client Authentication

Not all templates featuring authentication have the extension, but there is another way an attacker can request a certificate as a privileged user.

The other AD CS configuration that can enable a user to enroll for a certificate as a privileged user is the EDITF_ATTRIBUTESUBJECTALTNAME2 CA policy edit flag. Essentially, if this flag is set in the CA registry an abuser can request any Subject Alternative Name (SAN) as a certificate attribute.

The attacker can check this misconfiguration using certutil:

Checking the EDITF_ATTRIBUTESUBJECTALTNAME2 CA policy edit flag value with certutil

EDITF_ATTRIBUTESUBJECTALTNAME2 is set if the flag check for 0x00040000 is true.

Stage 2: Obtaining a certificate allowing to authenticate as a privileged user

Once the attacker has a certificate template allowing them to authenticate and specify a SAN, they will move to the second stage.

In this stage the attacker will request a certificate from the CA server based on the available published certificate template and add a SAN to the CSR.

The certificate will not only enable authentication, but list a SAN of a privileged user as well. Listing a privileged user in the SAN will allow the attacker to authenticate as the privileged user. With such an authentication, the attacker can gain persistence and privileged access within the network.

Certify is a very convenient way to request a certificate as it has multiple options including adding a SAN to a certificate.

Enrolling for a certificate with client authentication with a SAN of the Administrator

Stage 3: Authenticating as a privileged user with the obtained certificate

After the attacker has obtained a certificate with an option of adding a SAN of a highly privileged user, they will move to the final stage.

In the final stage, the attacker can use Rubeus to request a TGT from the Domain Controller using the aforementioned certificate with the SAN of a highly privileged user. With the TGT, the attacker can authenticate as the highly privileged user with “Pass the Ticket” (which is done with Rubeus).

Asking for the Administrator TGT and performing PTT with Rubeus

* The password is the certificate password we set up when taking the raw base64 output of Certify and saving it as a pfx certificate

Once “Pass the Ticket” is achieved successfully, the attacker has escalated privileges.

Successful PTT with Rubeus. Access to Domain Controller C$ before and after PTT

Cortex XDR Alerts and Insights

Looking at Cortex XDR we can see several alerts of this abuse flow.

For Stage 1 (Looking for misconfigurations in an AD CS environment) we will see the following alerts in the incident:

‘Discovery of misconfigured certificate templates using LDAP’ triggered by PowerShell LDAP query for misconfigured certificate templates

‘The CA Policy EditFlags was queried’ triggered by querying the EditFlags

Looking at the insights of said phase in the incident the following insights are presented:

‘LDAP Traffic from Non-Standard Process’ (PowerShell + Certify) triggered by querying the AD CS for templates

‘A suspicious process queried AD CS objects via LDAP’ (PowerShell + Certify) triggered by querying the AD CS for templates

‘Certutil execution’ triggered by querying the EditFlags

For Stage 2 (Obtaining a certificate allowing to authenticate as a privileged user) we will see the following alert in the incident:

‘An Unsigned suspicious process enrolled for a certificate’ triggered by Certify enrolling for a certificate

We can view the causality chain of the triggered alert:

Causality chain for both ‘An Unsigned suspicious process enrolled for a certificate’ and

‘The CA Policy EditFlags was queried’ (Action of remote query was done using certutil.exe)

For Stage 3 (Authenticating as a privileged user with the obtained certificate) we will see the following alerts in the incident:

Stage 3 alerts

Several alerts were triggered when Rubeus was executed.

WildFire marked it as Malware. XDR BIOC detected the tool execution. The XDR Agent detected behaviors of: Rubeus tool used for raw Kerberos interaction, Injecting Kerberos ticket, Activity similar to rubeus hacktool.

We can view the causality chain of the ticket injection:

Rubeus ticket injection - causality chain view

Looking at the insights of the third stage of the incident we see the following:

Stage 3 insights

The insights include the Identity Analytics module detecting rare process executions, for both the user and the organization. The processes that were rare are openssl and Ruberus. Openssl was used to create a pfx file from Certify’s base64 output certificate blob.

XDR Analytics BIOCs detected Rubeus accessing the certificate used for the TGT request - “Suspicious process accessed certificate files” and “LDAP Traffic from Non-Standard Process” also related to Rubeus’ activity.

Full flow incident alerts:

Full flow incident insights:

Additional Cortex XDR AD CS related Alerts and Insights

In addition to the alerts and insights from the presented abuse flow, Cortex XDR has other alerts and insights that will aid with AD CS abuse triage.

Conclusion

While the AD CS framework is used for managing trust in an organization, with permissive settings it can lead to privilege escalation and domain persistence.

We suggest looking for AD CS misconfigurations and running the latest agent and content version. Cortex XDR also detects and blocks this attack, leveraging behavioral analytics at different stages of the attack chain.

Want to learn more about Cortex XDR? Visit the Cortex XDR webpage or read the Essential Guide to XDR.