ADCS Exploitation: How Hackers Hijack Networks Using Fake Digital Certificates

To grasp how ADCS is exploited, it is essential to understand its primary components and how it interacts with Active Directory for authentication.

Enterprise Certificate Authorities and Templates

An ADCS environment typically consists of one or more servers acting as a Certificate Authority (CA). In an enterprise setup, the CA is deeply integrated with Active Directory. When a user or a computer requires a digital certificate (e.g., to authenticate to the corporate Wi-Fi), they submit a Certificate Signing Request (CSR) to the CA.

The CA does not randomly generate certificates; it relies on Certificate Templates. These templates act as blueprints, defining the exact parameters of the certificate to be issued: who is allowed to request it, how long the certificate is valid, and crucially, the Extended Key Usage (EKU), which dictates what the certificate is authorized to do. If a template has an EKU of "Client Authentication," the resulting certificate can be used to log into the domain.

Kerberos Authentication via Certificates (PKINIT)

The real danger of ADCS arises from its integration with Kerberos authentication via the PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) protocol. PKINIT allows a user to authenticate to a Domain Controller and obtain a Ticket Granting Ticket (TGT) by presenting a valid digital certificate instead of a traditional password.

When a certificate is presented, the Domain Controller validates the cryptographic signature of the CA. Crucially, it then maps the certificate to a specific user account in Active Directory. This mapping is primarily determined by the Subject Alternative Name (SAN) extension embedded within the certificate. If an attacker can manipulate the SAN during the certificate request process, they can trick the Domain Controller into believing they are a completely different, highly privileged user.

In 2021, security researchers Will Schroeder and Lee Christensen published a seminal paper detailing numerous techniques for abusing ADCS, famously categorized from ESC1 to ESC14. These techniques expose how specific, common misconfigurations in Certificate Templates allow for immediate, devastating compromise.

ESC1: The Golden Template Vulnerability

ESC1 is arguably the most common and critical ADCS vulnerability found in enterprise environments. It occurs when a Certificate Template suffers from a specific, toxic combination of three misconfigurations:

1. Enrollment Rights: The template allows low-privileged users (e.g., "Domain Users" or "Authenticated Users") to request a certificate.
2. Client Authentication EKU: The template specifies an EKU that permits Client Authentication, meaning the resulting certificate can be used to log into Active Directory via PKINIT.
3. ENROLLEE_SUPPLIES_SUBJECT (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT): This is the fatal flaw. This flag allows the user requesting the certificate to manually specify the Subject Alternative Name (SAN) inside the request.

The Attack Execution: An attacker controlling a standard employee workstation queries Active Directory for vulnerable templates. Finding an ESC1 template, the attacker generates a certificate request. However, because the ENROLLEE_SUPPLIES_SUBJECT flag is enabled, the attacker forcefully injects the username of a Domain Administrator (e.g., [email protected]) into the SAN field of the request. The CA, blindly following the misconfigured template, issues the certificate. The attacker then presents this forged certificate to the Domain Controller via PKINIT. The DC sees a cryptographically valid certificate mapping to the Domain Administrator, accepts it, and grants the attacker a TGT with total Domain Admin privileges. The entire domain is compromised in seconds.

ESC8: NTLM Relay to ADCS Web Enrollment

ADCS supports several HTTP-based enrollment interfaces, primarily the Certificate Authority Web Enrollment (CAWE) and the Certificate Enrollment Web Service (CEWS). These web endpoints are often deployed with critical security flaws, specifically lacking protection against NTLM Relay attacks.

The Attack Execution: An attacker positions themselves on the network and waits for, or actively coerces, a highly privileged machine (such as a Domain Controller) to authenticate to them over the network using NTLM. When the target machine attempts to authenticate to the attacker, the attacker intercepts the NTLM authentication traffic and seamlessly relays it to the ADCS Web Enrollment HTTP endpoint.

Because the web endpoint does not enforce modern protections like HTTPS or EPA (Extended Protection for Authentication), it accepts the relayed authentication as legitimate. The attacker then requests a Client Authentication certificate on behalf of the relayed machine. The CA issues the certificate, effectively handing the attacker the cryptographic identity of the Domain Controller. The attacker uses this certificate via PKINIT to assume control of the DC, achieving immediate domain dominance.

Persistence: Forging the Forger (DPAPI and CA Keys)

Beyond privilege escalation, ADCS offers unparalleled persistence mechanisms. If an attacker manages to compromise the Certificate Authority server itself, they can extract the CA’s private cryptographic key. With the CA's private key in hand, the attacker can forge their own certificates offline, entirely bypassing ADCS auditing and logging. They can generate certificates for any user, valid for decades, granting them permanent, invisible access to the domain that persists even if the original CA server is rebuilt.

Remediating ADCS vulnerabilities requires meticulous auditing, structural hardening, and a fundamental understanding of PKI mechanics. Security teams must actively hunt for misconfigurations before adversaries exploit them.

Auditing and Remediating Certificate Templates (Fixing ESC1)

Organizations must continuously audit all Active Directory Certificate Templates using specialized tools like Certify or BloodHound (which now includes ADCS attack path mapping). Security teams must rigorously hunt for the toxic ESC1 combination. If a template allows the requester to supply the Subject Name (ENROLLEE_SUPPLIES_SUBJECT), it must absolutely not be configured for Client Authentication, and it must never allow enrollment by standard "Domain Users."

Administrators should forcefully remove the ENROLLEE_SUPPLIES_SUBJECT flag wherever possible. If a specific business process truly requires it (which is rare for authentication certificates), enrollment must be strictly limited to a highly secure, dedicated service account, and the CA must be configured to hold these requests for manual approval by a PKI administrator before issuance.

Hardening ADCS Web Interfaces (Fixing ESC8)

To defend against NTLM Relay attacks targeting ADCS web endpoints, organizations must aggressively secure or disable these legacy interfaces.

If CAWE or CEWS is not strictly required for business operations, the most secure action is to uninstall the roles entirely. If they must remain active, administrators must enforce HTTPS (enabling SSL/TLS) on the IIS web servers hosting the enrollment pages. Crucially, they must enable Extended Protection for Authentication (EPA) and mandate Require SSL in the IIS settings. By enforcing EPA, the web server binds the NTLM authentication to the specific TLS channel, rendering relay attacks completely ineffective.

Implement Tiered Security and Monitoring

The Certificate Authority server must be treated with the exact same level of security and reverence as a Domain Controller. ADCS servers must be placed in Tier 0 of the Microsoft Tiered Administration Model. Standard administrators must never be allowed to log into a CA server, and rigorous network segmentation must isolate the PKI infrastructure from the broader corporate network.

Furthermore, traditional SIEM monitoring is often blind to ADCS abuse. Organizations must implement specialized Identity Threat Detection and Response (ITDR) solutions capable of parsing ADCS event logs. Security operations centers should generate high-priority alerts whenever a certificate is requested using a template with the ENROLLEE_SUPPLIES_SUBJECT flag, or whenever anomalous PKINIT authentication requests are observed on the Domain Controllers.