Active Directory certificate services - Attacking and defending

Active Directory certificate services

Attacking and defending

Eric Maurer
by Eric Maurer
on March 21, 2024
time to read: 14 minutes


Introduction to AD CS - from a security point of view.

  • AD CS is not installed per default but, from our experience, widely used
  • It is often overlooked when it comes to hardening
  • Since AD CS gets quite complex quickly, certain configurations are done unaware of the consequences
  • It's important to either have adequate countermeasures or Monitoring in place against such attacks

Microsoft Active Directory Public Key Infrastructure (PKI), better known as Active Directory Certificate Services (AD CS), is a Windows Server role for issuing and managing PKI certificates which are used in secure communication and authentication protocols. These certificates can be used to encrypt and sign documents and messages as well as for authentication of computer and/or user accounts. In this post we will take a closer look at the misconfigurations and how we can use it to attack Active Directory environments. The opportunities range from credential theft to machine persistence all the way up to domain escalation. The techniques are based on the Certified Pre-Owned Whitepaper by Will Schroeder and Lee Christensen.

The goal of this post is to provide a brief introduction to this complex, and frankly sometimes rather dry, but very important topic. We’ll cover some basic functionalities, what certificates look like and how they can be (ab)used.


AD CS can either be deployed as a standalone certificate authority (CA) or as a Enterprise CA. Standalone CAs do not have features like Certificate Templates and AutoEnrollment which makes them more likely to be used as Root and Policy CAs and they only issue certificates to other CAs. Enterprise CAs have features like certificate templates and autoenrollment which is, most of the time, crucial for enterprise environments. So, what are these features and how do they work?


As mentioned, a Certificate has various fields with information on how and what the certificate will be used for. Let’s take a closer look at some of those Fields and the expected Values:

The information which is included in the certificate binds an identity – the subject – to the key pair.

Enhanced Key Usage Property

EKUs and OIDs relate to each other, basically an OID is a string of decimal numbers that uniquely identifies an object. For now, the EKUs that permit authentication to AD are interesting and we’re focusing on those:

Client Authentication
Smart Card Logon
Any Purpose

More Information about OIDs in PKI can be found in this PKI Solutions Post.

Certificate Enrollment

After installing the AD CS role as an Enterprise CA, an administrator must first create and define certificate templates that are then published by Enterprise CA and made available to users and computers for enrollment. Without going into too much detail, a client can request a certificate only if it is allowed on the Enterprise CA as well as on the certificate template itself. More technical information about how these permissions are set can be found in the Whitepaper in the Chapter Certificate Enrollment.

If the permissions are granted and a client is allowed to request a certificate it can be done in different ways depending on the AD CS environment:

As an example: A User needs to manually request a new Certificate on his windows machine. The first step is to open the GUI, this can be done by typing certmgr.msc (certlm.msc for computer certificates) into the search pane in Windows. Open the Personal folder, right-click the Certificates folder and choose All Tasks, Request a new Certificate.

Request a new certificate for the current User

Now another wizard opens and all the published certificate templates, which the user is allowed to enroll in, are shown and can be enrolled. By default windows will then request the certificate using MS-WCCE.

Offensive Techniques

The offensive techniques are divided into four different categories, based on the different attack technique identifiers from the whitepaper, Theft, Persistence, Escalation and Domain Persistence. The following table helps understand the differences between the Categories:

Technique Description
Theft Stealing, extracting, and exporting already issued machine or user certificates and private keys. This is done using Window’s Crypto APIs, DPAPI and PKINIT
Persistence Account persistence via authentication certificates for a user and/or computer
Escalation Domain escalation via vulnerable/misconfigured AD CS components. This includes misconfigured Certificate Templates, AD Objects and Certificate Enrollment options
Domain Persistence Possibility to achieve Domain Persistence via certificate forgery from either stolen CA private Keys, malicious Certificates, or misconfigurations

To understand what kind of techniques these categories contain we will have a look at one of the Escalation possibilities if AD CS is misconfigured.

NTLM Relay to a vulnerable AD CS HTTP Endpoint (ESC8)

As mentioned in the Certificate Enrollment Chapter, several HTTP-based certificate enrollment interfaces are available, if they are installed. These HTTP interfaces are generally vulnerable against NTLM relay attacks. An attacker on a compromised machine could manipulate the Net-NTLMv2 authentication and impersonate any inbound-NTLM-authenticating AD Account, to gain access to certificate requests or perform other operations on behalf of the user. This could lead to security issues such as unauthorized access and the issuance of unauthorized certificates.

Let’s walk through a possible Attack where AD CS is vulnerable to ESC8:

  1. An Attacker manages to compromise an End-User-Client and gets a foothold on said client.
  2. After initial reconnaissance of the Active Directory, the ESC8 vulnerability was identified using the tool Certify in the Active Directory Certificate Service.
  3. To start the attack against the AD CS Web interface it is required that a victim authenticates to the attacker-controlled client to set up the NTLM Relay. For the sake of this Walkthrough, we are going to assume that one of the following scenarios has occurred:
    1. The attacker has enough time and can wait for this to occur as part of the daily business on the network.
    2. The attacker manages to coerce an account to authenticate against the attacker-controlled machine. Preferred targets are Domain Controllers and/or High-Privileged Accounts.
  4. After successfully coercing a domain controller, the Net-NTLMv2 Hash of the DC is sent to the attacker-controlled machine and can be relayed to the AD CS HTTP Endpoint.
  5. Since the HTTP Endpoint doesn’t have relay protection, the attacker is able to request certificates in the name of the original sender, in this case the domain controller.
    1. Now a certificate, based on a certificate template with suitable Enhanced Key Usage values like Client Authentication or SmartCard Logon will be issued.
  6. Since the victim machine was a domain controller, which can perform high privileged actions like domain replication, the attacker could use the certificate to compromise the domain. For example, some of the possibilities would be to try and run a DCSync Attack, get the NTHash or a Kerberos Ticket Granting Ticket (TGT) via PKINIT.

Defensive Techniques

Now, if the offensive Techniques are known it is a bit easier to protect against them. Will Schroeder and Lee Christensen already numbered and categorized these defensive techniques into preventative and detective measures. The Tool PSPKIAudit can be used to enumerate any misconfigured templates. After identifying any misconfigurations, it is highly recommended to dive deeper into the Defensive Techniques and follow the Defensive Guidance section to manage them accordingly. We won’t go into the different controls and how they are mapped to the offensive techniques, since thats well written in the whitepaper, but i quickly want to adress the preventative measure against the ESC8 vulnerability.

Harden AD CS HTTP Endpoints (PREVENT8)

The most effective method to prevent the ESC8 vulnerability is to not enable the AD CS HTTP Endpoints in the first place. To enumerate which Endpoints are enabled and remove them, connect to the server, which is running the AD CS Role, open the Server Manager app and use the Remove Roles and Features Wizard.

Remove server role Wizard

If the Endpoints are necessary and it is not possible to remove them, these defensive measures against ESC8 could be considered.


Active Directory Certificate Services can become complex very quickly, it is not the easiest to implement and secure in most environments. All the different possibilities for how it can be configured, extended, and adapted for different Use-Cases make it hard to lock it down from a security point of view. The different certificate abuse techniques allow attackers to go from Credential Theft to domain persistence up to Domain Escalation rather fast. The mentioned tools Certify (AD CS Enumeration) and PSPKIAudit (Auditing AD CS) are great to enumerate any weaknesses in the infrastructure which can then be addressed. If not already happening, it is recommended to continously audit the AD CS environment and the certificate templates. To summarize: Not only the domain controllers need to be protected but also the CA servers, treat them like a Tier 0 System

About the Author

Eric Maurer

Eric Maurer completed his IT training in the financial sector and then gained experience in the roles of administrator, engineer and consultant. He was involved in the development, setup and operation of an Enhanced Security Administrative Environment and the international rollout of Active Directory Services. In addition he is experienced in Azure Active Directory with a focus on security.


You need support in such a project?

Our experts will get in contact with you!

Active Directory certificate services

Active Directory certificate services

Eric Maurer

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here