On an internal assessment, one of the fastest paths from "I plugged into the network" to "I have a foothold" does not involve an exploit at all. It abuses the way Windows resolves names it cannot find, and the fact that a great many networks still do not enforce SMB signing. This is LLMNR and NBT-NS poisoning, and its more powerful cousin, NTLM relay. This guide walks through both, from capturing a hash to relaying authentication onto another machine, and finishes with what a defender should do about it.
Why the poisoning works
When a Windows host needs to resolve a name and DNS does not answer, it does not give up. It falls back to two legacy broadcast protocols: Link-Local Multicast Name Resolution (LLMNR, UDP 5355) and NetBIOS Name Service (NBT-NS, UDP 137). The host effectively shouts to the whole local segment, "does anyone know who FILESRV01 is?"
Nothing authenticates the answer. So a mistyped share name, a decommissioned server someone still has mapped, or the WPAD proxy lookup that fires constantly on some networks, all produce broadcasts that anyone on the segment can answer. Responder answers all of them with "yes, that is me," the victim connects to us, and Windows helpfully authenticates with the current user's NTLM credentials while doing so.
Step 1: capture with Responder
Point Responder at your interface and let it listen:
responder -I eth0
[Screenshot: Responder startup banner showing the poisoners LLMNR, NBT-NS, and MDNS enabled and the servers it is listening with]
When a host on the segment does a failed name lookup, Responder poisons the response and captures the resulting authentication. What you get is a NetNTLMv2 hash, the challenge-response, not the NT hash itself:
[SMB] NTLMv2-SSP Hash : jsmith::CORP:1122334455667788:A1B2...:0101000000...
Save it and try to crack it offline with hashcat mode 5600:
hashcat -m 5600 hashes.txt rockyou.txt -r rules/best64.rule
If the account has a weak password, you now have plaintext credentials. Why this matters: you have not touched a single vulnerability. You captured a domain credential from the ambient noise of a normal network.
Step 2: when it will not crack, relay it
Strong passwords do not crack, and that is where relaying earns its place. Instead of capturing the authentication and cracking it later, you pass it, live, to a different machine and authenticate there as the victim.
First, stop Responder from answering SMB and HTTP itself, because ntlmrelayx needs those. In /usr/share/responder/Responder.conf, set:
SMB = Off
HTTP = Off
Now build a list of relay targets. You can only relay to a host that does not require SMB signing, so enumerate the range and let the tooling filter for you:
nxc smb 10.10.10.0/24 --gen-relay-list targets.txt
[Screenshot: NetExec output flagging which hosts have SMB signing not required, written out to targets.txt]
Then run Responder to do the poisoning and ntlmrelayx to do the relaying, side by side:
responder -I eth0
ntlmrelayx.py -tf targets.txt -smb2support
When Responder poisons a lookup and the victim authenticates, ntlmrelayx relays that authentication to a target from your list. By default it dumps the target's local SAM hashes. Add -c to run a command, or -i to open an interactive SMB client against the target:
ntlmrelayx.py -tf targets.txt -smb2support -c "whoami"
Common mistakes to recognize
- Relaying back to the same host. You cannot relay a host's authentication back to itself; that has been mitigated for years. Relay to a different machine that trusts the same account.
- The target enforces SMB signing. If nothing lands, your targets.txt probably contains hosts that require signing. Regenerate it and confirm you are only relaying to hosts where signing is not required.
- Responder still holding SMB or HTTP. If ntlmrelayx complains that a port is in use, Responder did not release SMB or HTTP. Check the config change actually took.
- A quiet segment. No poisoning happens if no one does a failed lookup. WPAD and mapped-drive reconnects are your friends here; give it time, or nudge activity if your rules of engagement allow.
What this looks like from the defensive side
Since the point of these guides is to make you a better tester, know what you are setting off and how it gets shut down. This whole class is catalogued as LLMNR/NBT-NS Poisoning and SMB Relay, T1557.001 in ATT&CK, and the fixes are unglamorous and effective:
- Disable LLMNR and NBT-NS via Group Policy. Almost nothing legitimate needs them in a network with working DNS, and turning them off removes the poisoning surface entirely.
- Enforce SMB signing everywhere. Required signing means a relayed session fails its integrity check, which kills the relay even when poisoning still happens.
- Disable WPAD if it is not deliberately used, because the automatic proxy lookup is one of the most reliable sources of pollutable traffic.
A network that has done those three things makes this attack a dead end, which is exactly why finding one that has not is such a common early win.
Where to practice
Only run this against networks you are authorized to test. To build the reflexes legally, the Active Directory labs on HackTheBox and the relay-focused rooms on TryHackMe are built for it, and the tooling is documented at the Impacket repository (ntlmrelayx) and in the Responder project. Once you have a foothold this way, the natural next steps are pulling more credentials with our Mimikatz walkthrough and going after service accounts with Kerberoasting.
The reason this technique refuses to die is that it depends on defaults, not on anyone making a mistake in the moment. Turn off the legacy protocols, sign your SMB, and the ambient credential theft stops.
HacknPentest