Notes from the Field • 10 MIN READ

Security Abuse of Misconfigured Active Directory Certificate Services Continue

by Nikhil Kurkure, Eleanor Barlow • Jan 2025

Active Directory Certificate Services (ADCS) is a role in Microsoft Windows Server that provides the infrastructure for public key infrastructure (PKI). It is used to create, manage, distribute, and revoke digital certificates. These certificates are used to secure communications, authenticate users or devices, and enforce security policies in an organization.

However, when misconfigured, ADCS can open doors for attackers to exploit weaknesses, leading to unauthorized access and privilege escalation.

How Can ADCS Become Vulnerable?

Unlike traditional threats, ADCS exploitation often begins with misconfigured certificate templates or weak HTTP-based enrollment methods. Once these are exploited, attackers can move laterally across the network, compromising critical systems and sensitive data.


Initially, the process begins with the client (user or computer) generating a public/private key pair. The client then sends a Certificate Signing Request (CSR) to the Certificate Authority (CA) server, which includes the public key and requested certificate details. The CA validates the request by checking if the certificate template settings permit the request, whether the certificate already exists, and if the client has the necessary permissions to enroll.

Figure 1: ADCS Client to Server Workflow, SecurityHQ

Figure 1: ADCS Client-to-Server Workflow, SecurityHQ

Upon successful validation, the CA uses its private key to sign and issue the certificate. The client stores the issued certificate in its Windows Certificate Store, enabling it to perform actions such as authentication, code signing, or secure communication as allowed by the certificate’s intended purpose.

Exploiting ESC8 – NTLM Relay Attack via AD CS Web Enrollment

Before exploring the exploitation of ESC8 (NTLM Relay Attack through AD CS Web Enrollment), it is important to understand how NTLM relay attacks work. NTLM relaying is a common attack used by threat actors to steal identities.

It works in two steps. First, it forces a victim to authenticate to a targeted endpoint. Second, it relays the authentication against a vulnerable target. By relaying the victim’s login details, attackers can log in and act as the victim. This helps them gain access to systems and potentially take over the network.

Figure 2: NTLM Relay Attack Flow, SecurityHQ

Figure 2: NTLM Relay Attack Flow, SecurityHQ

Active Directory Certificate Services (ADCS) provide an HTTP-based method for users and machines to enroll for certificates. When HTTP web enrollment is enabled, these methods are vulnerable and are often exploited through NTLM relay attacks. In such attacks, attackers impersonate authenticated users by relaying legitimate authentication requests to request certificates. This vulnerability can lead to full domain compromise.

The widespread use of HTTP-based enrollment further increases the risk of exploitation. Security researchers refer to this specific vulnerability or misconfiguration in ADCS as ADCS ESC8.

How Can ADCS ESC8 be Exploited in 6 Steps?

In this instance, the attacker first needs to enumerate the ADCS(HTTP) endpoint in the network which can be enumerated by tools such as certipy (python-based tool). Note that the attacker would need access to the domain, but the credential of a simple low-level authenticated user is all that is needed to perform the attack.

Figure 3: ESC8 NTLM Relay Attack via ADCS Web Enrollment, SecurityHQ

Figure 3: ESC8 (NTLM Relay Attack via ADCS Web Enrollment), SecurityHQ

  1. Once the vulnerable endpoint (ADS01) is identified, actors use an NTLM coercion method to initiate NTLM authentication from a domain controller. Event Detection Point: Look for Windows Event ID 4776 where you will be able to see the login event performed for the domain controller account (i.e. DC01$) where $ indicates the authentication is initiated for the system account of DC from the victim’s machine.
  2. The domain controller responds with the NTLM authentication which is relayed by the attacker from the victim’s machine to the vulnerable AD CS machine. This is achieved by setting up a relay on the attacker machine through tools such as ntlmrelayx.
  3. The URL “http://<Vulnerable_CA_Server>/certsrv/certfnsh.asp” is Microsoft’s Certificate Services web interface, which is used for certificate enrollment. The “certfnsh.asp” page is responsible for completing the certificate request process and delivering the issued certificate to the requestor. Event Detection Point: Look for network traffic on port 80 directed toward the ADCS server. Specifically, you will observe a GET method here.
  4. The attacker requests a certificate for a domain controller, as it was a relayed request impersonating a legitimate source, ADCS issues a certificate for the requested domain controller (i.e. DC01.pfx). This obtained certificate will be stored in the Windows stores. Event Detection Point: Look for Windows Event ID 4886, which is generated when certificates are requested, and Windows Event ID 4887, which indicates that Certificate Services has approved a certificate request and issued a certificate to the requester.
  5. Using the generated certificate attackers can impersonate the domain controller machine account and request a Kerberos TGT to authenticate the Domain controller. Event Detection Point: Windows Event ID 4768 will show the Kerberos authentication login event for the domain controller account (e.g., DC01$) &. Look for network traffic on port 80 directed toward the ADCS server. Specifically, you will observe the POST method here.
  6. Once these TGTs are received the attackers now can authenticate as the domain controller anywhere in the domain as they have NT Hash for the Domain controller machine account, further performing a DC Sync attack to retrieve all the domain hashes. Event Detection Point: Look for Windows Event ID 4662 for an indication of a DC Sync Attack.

Detect ADCS Abuse

To detect ADCS abuse, Windows Events ID needs to be monitored. These include:

  • Event ID 4776: The domain controller attempted to validate the credentials for an account. This event can be a valuable indicator for detecting Pass-the-Hash, as it is logged whenever a domain controller (DC) attempts to validate the credentials of an account using NTLM over Kerberos.
  • Event ID 4886: Certificate Services received a certificate request. Monitor this event ID for certificate issues for the domain controller.
  • Event ID 4887: Certificate Services approved a certificate request and issued a certificate. Monitor this event ID for ADCS issuing a certificate to the requestor.
  • Event ID 4768: A Kerberos authentication ticket (TGT) was requested. Monitor this event for a user or computer account that is attempting to authenticate to the domain and obtain access to resources.
  • Event ID 4662: An operation was performed on an object. Monitor this event ID for DC Sync Attack which allows attackers to steal credentials by using DSGetNC Changes requests.

Mitigations and Next Steps

  1. Disable NTLM Authentication on your Windows domain controller and on any AD CS Servers in your domain.
  2. Disable HTTP on AD CS servers. (AD CS Web Enrollment)
  3. Enable Extended Protection for Authentication (EPA)
  4. Enable detailed logging of certificate requests and enrolments on the CA Server.

For more information about this vulnerability, how it works, and how to protect against it, contact an expert, here.