Hardening AD CS Web Enrollment: Blue Team Defense Guide
Overview & Defensive Context#
In this morning's architectural deep-dive, we deconstructed the attack mechanics of AD CS ESC8, one of the most pervasive privilege escalation vectors in enterprise Active Directory environments. By exploiting the Certification Authority Web Enrollment role (/certsrv/) running on Internet Information Services (IIS) without Extended Protection for Authentication (EPA) or Channel Binding Tokens (CBT), unauthenticated adversaries can relay coerced machine account credentials directly to the enrollment web interface over HTTP.
When chained with remote procedure call coercion primitives such as PetitPotam (MS-EFSRPC) or SpoolSample (MS-RPRN), an attacker forces a Domain Controller's computer account (DC01$) to authenticate back via NTLM over SMB. The attacker intercepts and relays this authentication across protocols to /certsrv/certfnsh.asp, prompts the Certificate Authority (CA) to issue an X.509 machine authentication certificate for the Domain Controller, authenticates via Kerberos PKINIT (RFC 4556), and executes DCSync to dump the entire forest's credential database.
Securing Active Directory PKI against ESC8 exposes severe structural blind spots in traditional enterprise defense architectures:
- The SMB Signing Illusion: A widespread operational misconception is that enforcing SMB Signing on Domain Controllers eliminates NTLM relaying. SMB signing cryptographically binds SMB transport frames between client and server. However, when an adversary strips the NTLM authentication token from SMB and relays it into an HTTP POST request, the receiving web server evaluates the NTLM token independently of the original SMB transport layer. Cross-protocol NTLM relaying is completely immune to SMB signing.
- The Impossibility of Endpoint-Only Coercion Defense: Attackers continuously discover new RPC and DCOM methods (MS-EFSRPC, MS-RPRN, MS-DFSNM, MS-FSRVP) that compel Windows systems to authenticate to remote UNC paths. Attempting to defend against ESC8 by playing an endless game of whack-a-mole with coercion endpoints fails to address the root vulnerability: the unhardened HTTP authentication receiver.
- Default Insecurity of Web Enrollment: When the AD CS Web Enrollment role is deployed, IIS is automatically configured with Windows Authentication enabled, NTLM negotiation permitted, Extended Protection disabled, and unencrypted HTTP (port 80) bindings active.
- Audit Blindness in Standard Web Logs: Standard IIS W3C logging records successful HTTP 200 responses for
/certsrv/certfnsh.asp. Without explicit correlation linking the machine account identity (DC01$) to Web Enrollment and subsequent Kerberos PKINIT TGT requests (Event ID 4768 with pre-authentication type 16), Security Operations Centers (SOC) fail to distinguish between legitimate user enrollments and weaponized machine account relays.
[!WARNING] Enforcing SMB signing does not mitigate ESC8. If AD CS Web Enrollment accepts NTLM without Extended Protection for Authentication, your entire Active Directory forest remains vulnerable to unauthenticated takeover via cross-protocol relaying.
Architecture Hardening#
Neutralizing ESC8 requires a multi-layered defense-in-depth architecture across four defensive rings: Enforcing Extended Protection for Authentication (EPA), Eliminating NTLM on IIS (Kerberos-Only), Decommissioning Legacy Web Enrollment Roles, and Hardening Domain Controller RPC Coercion Surface.
Defense Architecture Flowchart#
flowchart TD
classDef client fill:#1e293b,stroke:#ef4444,stroke-width:2px,color:#f8fafc
classDef gate fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
classDef ca fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
classDef dc fill:#4c1d95,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
classDef drop fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
classDef pass fill:#065f46,stroke:#34d399,stroke-width:2px,color:#a7f3d0
CoercionTrigger[Attacker Invokes RPC Coercion PetitPotam]:::client --> DCOutbound{Ring 1: DC Outbound NTLM Policy}:::dc
DCOutbound -- Outbound NTLM Blocked via Group Policy --> Drop1[Action: DROP Outbound NetNTLM Traffic]:::drop
DCOutbound -- NTLM Permitted: DC Connects to Attacker --> AttackerRelay[Attacker Relays NTLM over HTTP]:::client
AttackerRelay --> IISWebGate{Ring 2: IIS HTTPS & Protocol Inspection}:::gate
IISWebGate -- Cleartext HTTP Port 80 Request --> Drop2[Action: Deny / Require TLS 1.3]:::drop
IISWebGate -- Encrypted HTTPS Port 443 Session --> EPACheck{Ring 3: Extended Protection Evaluation}:::gate
EPACheck -- Channel Binding Token Missing or Relayed Mismatch --> Drop3[Action: HTTP 401 Unauthorized EPA Mismatch]:::drop
EPACheck -- Legitimate Direct Client Handshake --> AuthProvider{Ring 4: Authentication Provider Gate}:::ca
AuthProvider -- Protocol is NTLMSSP --> Drop4[Action: Deny by Kerberos-Only Policy]:::drop
AuthProvider -- Protocol is Negotiate:Kerberos --> CertificateEngine[AD CS Engine: Process CSR]:::pass
CertificateEngine -.-> AuditPipeline[Ring 5: Event ID 4886/4887 & 4768 Audit]:::ca
AuditPipeline --> SIEMAlert[SIEM Telemetry: Clean Machine Enrollment]:::passLayer 1: Enforcing Extended Protection for Authentication (EPA) & HTTPS#
Microsoft Security Advisory KB5005413 mandates the enforcement of Extended Protection for Authentication (EPA) and HTTPS across all AD CS web enrollment interfaces.
EPA utilizes Channel Binding Tokens (CBT). When a client authenticates over TLS, it computes a hash of the server's TLS certificate and embeds it inside the NTLM authentication payload. If an adversary relays this NTLM response over an independent TLS connection established between the relay tool and the CA, the server's certificate hash does not match the channel binding token embedded in the client's payload. The web server immediately terminates the connection with HTTP 401 Unauthorized.
Execute the following PowerShell commands on all servers hosting AD CS Web Enrollment (/certsrv/), Certificate Enrollment Service (CES), or Network Device Enrollment Service (NDES):
# Import IIS Administration Module
Import-Module WebAdministration
# 1. Require SSL across the certsrv virtual directory
Set-WebConfigurationProperty -Filter "system.webServer/security/access" `
-Location "Default Web Site/certsrv" `
-Name "sslFlags" -Value "Ssl, SslRequireCert"
# 2. Enable Windows Authentication
Set-WebConfigurationProperty -Filter "system.webServer/security/authentication/windowsAuthentication" `
-Location "Default Web Site/certsrv" `
-Name "enabled" -Value $True
# 3. Configure Extended Protection for Authentication to Required
Set-WebConfigurationProperty -Filter "system.webServer/security/authentication/windowsAuthentication/extendedProtection" `
-Location "Default Web Site/certsrv" `
-Name "tokenChecking" -Value "Require"
Set-WebConfigurationProperty -Filter "system.webServer/security/authentication/windowsAuthentication/extendedProtection" `
-Location "Default Web Site/certsrv" `
-Name "flags" -Value "None"
# Restart IIS to apply the configuration
iisreset /noforce
[!IMPORTANT] Setting
tokenCheckingtoRequireguarantees that unauthenticated relays cannot forge NTLM authentication over HTTP. If legacy clients lack channel binding support,Allowcan be used as a temporary transitional setting, butRequireis mandatory to permanently eradicate ESC8.
Layer 2: Eliminating NTLM Authentication on IIS (Kerberos-Only)#
The most definitive protocol-level defense against all forms of NTLM relaying is to disable NTLM entirely on the web enrollment virtual directories, forcing clients to authenticate exclusively via Kerberos.
Kerberos tickets are cryptographically bound to the target server's Service Principal Name (SPN, e.g., HTTP/ca.corp.local). A Kerberos ticket requested for an attacker's machine cannot be accepted by the CA.
# Remove NTLM from the allowed authentication providers list in IIS
Clear-WebConfiguration -Filter "system.webServer/security/authentication/windowsAuthentication/providers" `
-Location "Default Web Site/certsrv"
# Add Negotiate (Kerberos) as the sole authentication provider
Add-WebConfiguration -Filter "system.webServer/security/authentication/windowsAuthentication/providers" `
-Location "Default Web Site/certsrv" `
-Value "Negotiate"
Once configured, any client attempting an NTLM handshake (NTLMSSP_NEGOTIATE) is rejected immediately.
Layer 3: Decommissioning the Legacy Web Enrollment Role#
In modern enterprise architectures, the Certification Authority Web Enrollment role (/certsrv/) is an obsolete legacy component.
Windows workstations, servers, and Domain Controllers do not utilize /certsrv/ for automated certificate enrollment. Native Windows certificate auto-enrollment operates over RPC/DCOM (MS-ICPR) via the Distributed Component Object Model interface (certcli.dll), which is inherently protected from cross-protocol relaying when configured with packet privacy.
If your enterprise does not support specialized third-party web portals that explicitly require /certsrv/, uninstall the role entirely:
# Permanently uninstall the AD CS Web Enrollment role
Remove-WindowsFeature Adcs-Web-Enrollment -Restart
Removing the role completely eliminates the attack surface, guaranteeing zero exposure to ESC8.
Layer 4: Hardening Domain Controller RPC Coercion Endpoints#
To stop attackers from forcing Domain Controllers into initiating outbound authentication, blue teams must harden coercion endpoints across all Domain Controllers:
- Disable the Print Spooler on Domain Controllers:
Domain Controllers do not print documents. The Print Spooler service (
spoolsv.exe) exposes theMS-RPRNRPC interface, which attackers abuse viaSpoolSample/PrinterBugto coerce machine authentication:
# Stop and permanently disable the Print Spooler on all Domain Controllers
Stop-Service Spooler -Force
Set-Service Spooler -StartupType Disabled
- Deploy Windows Filtering Platform (WFP) RPC Filters for PetitPotam:
Block unauthenticated remote procedure calls to the Encrypting File System Remote Protocol (MS-EFSRPC, UUID
c681d007-d8ee-4565-a564-21a5b77bb292):
# Apply netsh RPC filter to block unauthenticated MS-EFSRPC coercion
netsh rpc filter add rule layer=um actiontype=block
netsh rpc filter add condition field=if_uuid matchtype=equal data=c681d007-d8ee-4565-a564-21a5b77bb292
- Restrict Outbound NTLM Egress via Group Policy:
Configure a Group Policy Object targeting all Domain Controllers to block outbound NTLM authentication to untrusted remote hosts:
- Policy Path:
Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options - Setting:
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers - Value:
Audit all(initial baseline) ->Deny all(production enforcement).
- Policy Path:
Production Detection Queries#
Blue teams must deploy multi-layered detection across IIS web server telemetry, Certificate Services audit event logs, and Kerberos authentication telemetry.
1. Production Sigma Rule: AD CS ESC8 NTLM Relay Web Enrollment Attempt#
The following Sigma rule detects unauthorized machine account authentication targeting the /certsrv/ enrollment interface in IIS W3C access logs:
title: AD CS ESC8 NTLM Relay Web Enrollment Attempt
id: 3c8e1a92-7f4b-4d18-9a2c-6b3e1a09d502
status: production
description: |
Detects potential AD CS ESC8 NTLM relay attacks by identifying HTTP POST requests
to Web Enrollment endpoints (/certsrv/) where authentication is performed using NTLM
and the authenticated user identity is a machine account (ending with '$').
references:
- https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b1f0-32a1-4131-4077-0f15776d7478
- https://posts.specterops.io/certified-pre-owned-d95910965cd2
tags:
- attack.credential_access
- attack.t1557.001
- attack.privilege_escalation
- attack.t1649
logsource:
category: webserver
product: iis
detection:
selection_endpoint:
cs-method: 'POST'
cs-uri-stem|startswith:
- '/certsrv/'
- '/certsrv/certfnsh.asp'
selection_auth:
cs-username|endswith: '$'
condition: selection_endpoint and selection_auth
fields:
- c-ip
- cs-username
- cs-method
- cs-uri-stem
- sc-status
falsepositives:
- Rare third-party automation tools legitimately using machine accounts for web enrollment.
level: critical
2. PowerShell Audit Script: Auditing AD CS Web Enrollment Posture#
Run this PowerShell script across your Active Directory PKI infrastructure to identify vulnerable IIS Web Enrollment installations:
# Audit-ADCSWebEnrollment.ps1
# Audits IIS Web Enrollment virtual directories for ESC8 vulnerabilities
Import-Module WebAdministration -ErrorAction SilentlyContinue
$Sites = Get-ChildItem "IIS:\Sites"
$Vulnerable = $false
foreach ($Site in $Sites) {
$Certsrv = Get-WebConfigurationProperty -Filter "system.webServer/security/authentication/windowsAuthentication" `
-Location "$($Site.Name)/certsrv" -Name "enabled" -ErrorAction SilentlyContinue
if ($Certsrv.Value -eq $true) {
$Providers = Get-WebConfigurationProperty -Filter "system.webServer/security/authentication/windowsAuthentication/providers" `
-Location "$($Site.Name)/certsrv" -Name "Collection" -ErrorAction SilentlyContinue
$EPA = Get-WebConfigurationProperty -Filter "system.webServer/security/authentication/windowsAuthentication/extendedProtection" `
-Location "$($Site.Name)/certsrv" -Name "tokenChecking" -ErrorAction SilentlyContinue
$SSL = Get-WebConfigurationProperty -Filter "system.webServer/security/access" `
-Location "$($Site.Name)/certsrv" -Name "sslFlags" -ErrorAction SilentlyContinue
Write-Host "[!] Found Active Web Enrollment on Site: $($Site.Name)/certsrv" -ForegroundColor Yellow
Write-Host " - Windows Auth Enabled : $($Certsrv.Value)"
Write-Host " - Allowed Providers : $($Providers.Value -join ', ')"
Write-Host " - Extended Protection : $($EPA.Value)"
Write-Host " - SSL Flags : $($SSL.Value)"
if ($EPA.Value -ne "Require" -or ($Providers.Value -contains "NTLM")) {
Write-Warning "[CRITICAL VULNERABILITY]: $($Site.Name)/certsrv is VULNERABLE to AD CS ESC8 NTLM Relay!"
$Vulnerable = $true
}
}
}
if (-not $Vulnerable) {
Write-Host "[+] All AD CS Web Enrollment endpoints are hardened with EPA or NTLM is disabled." -ForegroundColor Green
}
3. Suricata / Snort Signature: Intercepting Machine NTLM Relay to /certsrv/#
Deploy this NIDS signature on network sensors monitoring web traffic to Certificate Authority servers:
# Suricata Rule: Detect Relayed Machine NTLM Auth to AD CS Web Enrollment
alert http any any -> $ADCS_SERVERS 80 ( msg:"FAST_CYBER_DEFENSE - AD CS ESC8 NTLM Relay Attempt over Cleartext HTTP"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/certsrv/certfnsh.asp"; http.header; content:"Authorization|3a| NTLM"; nocase; reference:url,support.microsoft.com/en-us/topic/kb5005413; classtype:attempted-admin; sid:10008801; rev:1; )
Enterprise Mitigation Matrix#
When prioritizing defensive mitigations against AD CS ESC8, security leadership must balance rapid containment against PKI legacy application dependencies:
| Remediation Strategy | Implementation Effort | Blast Radius & Operational Risk | Detection & Prevention Efficacy | Performance Overhead | Architectural Longevity |
|---|---|---|---|---|---|
| Workaround: Enforce EPA (Require) & Strict HTTPS on IIS | 30 - 60 Minutes (Apply KB5005413 configuration to set tokenChecking=Require and SSL flags) |
Low Only impacts legacy clients lacking Channel Binding Token support. |
High (95%) Blocks cross-protocol relays by validating outer TLS certificate hashes. |
Zero Native IIS kernel-mode HTTP filter. |
Interim Standard Secures existing /certsrv/ installations while in production. |
| Operational Fix: Disable NTLM on /certsrv/ (Kerberos Only) | 1 - 2 Hours (Strip NTLM from Windows Auth providers list in IIS) |
Low Domain-joined clients automatically negotiate Kerberos via SPNs. |
Absolute for Relaying (100%) Eliminates NTLMSSP tokens; Kerberos cannot be relayed across hosts. |
Zero Standard SPNEGO Kerberos ticket processing. |
Permanent Hygiene Eradicates NTLM authentication across the PKI web tier. |
| Architecture Fix: Decommission Web Enrollment & Block Coercion | 1 - 3 Days (Uninstall Adcs-Web-Enrollment, disable Print Spooler, apply RPC filters) |
Low Windows auto-enrollment uses native RPC/DCOM, unaffected by web role removal. |
Comprehensive (100%) Completely eliminates attack surface and blocks remote coercion primitives. |
Zero Reduces server background footprint. |
Permanent State Modernized zero-trust PKI architecture immune to relay attacks. |
[!CAUTION] If your environment relies on Linux/macOS clients that enroll certificates via SCEP or NDES (Network Device Enrollment Service), verify that NDES endpoints are configured with dedicated service accounts and isolated from Domain Controller certificate templates.
Incident Response & Verification Playbook#
If a suspected ESC8 relay attack or unauthorized machine certificate issuance is detected, execute the following four-phase incident response playbook immediately:
flowchart TD
classDef alert fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
classDef check fill:#1e293b,stroke:#f59e0b,stroke-width:2px,color:#fef3c7
classDef triage fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
classDef clean fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
Triage[Phase 1: CA Database Triage & Serial Number Identification]:::triage --> CorrelateLog[Correlate IIS W3C Logs with Event ID 4887]:::check
CorrelateLog --> ConfirmRelay{Was a Machine Certificate Issued via Web?}:::check
ConfirmRelay -- Yes --> RevokeCert[Phase 2: Immediate Certificate Revocation]:::alert
ConfirmRelay -- No --> CloseIncident[Close Incident as False Positive]:::clean
RevokeCert --> PublishCRL[Publish Emergency Certificate Revocation List CRL]:::alert
PublishCRL --> PurgeKerberos[Phase 3: Invalidate KDC Sessions & Reset Machine Password]:::alert
PurgeKerberos --> CheckDCSync{Was krbtgt Key Compromised via DCSync?}:::check
CheckDCSync -- Yes --> DoubleKrbtgt[Execute Emergency krbtgt Double-Rotation Protocol]:::alert
CheckDCSync -- No --> Phase4[Phase 4: Post-Remediation Verification & Hardening]:::clean
DoubleKrbtgt --> Phase4Phase 1: Live Triage & Forensic Certificate Database Audit#
- Query Active Directory Certificate Services Database:
Examine the CA database for all certificates issued to computer accounts (
*$) within the intrusion window:
# Query CA database for certificates issued to computer accounts
certutil -view -restrict "RequesterName=*$,Disposition=20" -out "RequestID,RequesterName,CommonName,CertificateTemplate,NotBefore,NotAfter,SerialNumber"
Identify any machine certificate requested where the template is DomainController or Machine and the requester is a Domain Controller machine account (DC01$).
- Correlate with Certificate Services and IIS Audit Events:
- Security Event ID 4886: Certificate request submitted.
- Security Event ID 4887: Certificate issued by CA. Check
RequesterandCertificate Template. - IIS W3C Access Logs: Look for a corresponding
POST /certsrv/certfnsh.aspentry at the exact same timestamp withcs-usernamematchingDC01$.
Phase 2: Immediate Containment & Certificate Revocation#
- Revoke the Fraudulent Certificate:
Immediately revoke the serial number extracted from the CA database using
certutil:
# Revoke the fraudulent certificate (Reason 6: Cessation of Operation)
certutil -revoke "310000004a8b9c1d2e3f4a5b6c" 6
- Publish an Emergency Certificate Revocation List (CRL): Force immediate publication and replication of the CRL across all LDAP and HTTP Distribution Points:
# Publish a new base and delta CRL immediately
certutil -CRL
Phase 3: Kerberos Session Invalidation & Password Reset#
- Purge Compromised Kerberos Sessions: Because the attacker obtained a Kerberos TGT using PKINIT, purge active ticket caches on the KDC:
# Invalidate local Kerberos ticket cache on Domain Controller
klist -li 0x3e7 purge
- Reset the Compromised Machine Account Password: Reset the password of the coerced Domain Controller machine account to invalidate existing service tickets:
# Reset machine account password
Reset-ComputerMachinePassword
- Execute
krbtgtDouble-Rotation Protocol (If DCSync Occurred): If the attacker utilized the compromised TGT to execute DCSync, the masterkrbtgtaccount must be rotated twice following the standard 10-hour Kerberos ticket lifetime replication hold to permanently invalidate all forged Golden Tickets.
Phase 4: Post-Remediation Verification & Hardening Checklist#
Before closing the incident:
- Verify that
Audit-ADCSWebEnrollment.ps1returns a clean, hardened status across all CAs. - Confirm that
tokenChecking=Requireis active on all/certsrv/virtual directories in IIS. - Verify that the Print Spooler service is stopped and disabled across all Domain Controllers.
- Test that an NTLM relay attempt against
/certsrv/fails immediately withHTTP 401 Unauthorized. - Confirm that the ESC8 Sigma detection rule is active and alerting in your enterprise SIEM.
Authoritative References#
- Microsoft Security Advisory KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS) — Microsoft Support
- SpecterOps Research: Certified Pre-Owned: Abusing Active Directory Certificate Services — SpecterOps Whitepaper
- Cybersecurity and Infrastructure Security Agency (CISA): Defending Active Directory Certificate Services Against Exploitation — CISA Advisory
- Microsoft Open Specifications: [MS-WCCE]: Windows Client Certificate Enrollment Protocol — Microsoft Learn
Comments
Post a Comment