Key takeaways
- Windows falls back to LLMNR and NBT-NS when DNS cannot resolve a name, and neither protocol checks who answers.
- An attacker on the LAN answers the broadcast, captures a NetNTLMv2 response, and can relay it live to another host instead of cracking it.
- The relay only succeeds where SMB signing is not enforced, so the whole chain rests on two fixable defaults.
- Disabling LLMNR and NBT-NS and enforcing SMB signing close the path, and a rogue responder is a low-noise thing to alert on.
Why a Windows host answers a question nobody asked
Domain Name System is the first place a Windows computer looks up a name. When DNS has no answer, Windows does not stop. It falls back to two older protocols, Link-Local Multicast Name Resolution and NetBIOS Name Service, and asks the whole local network instead: does anyone here answer to this name? Both were built for small trusted networks, and neither checks who replies.
That fallback fires constantly. A mistyped share name, a stale mapping to a server that was renamed, a printer that has moved, a Web Proxy Auto-Discovery lookup: each one can miss in DNS and spill onto the local segment as a broadcast. On a quiet corporate network these questions arrive every few seconds. An attacker who is already on the wire, through a network port in a meeting room or a foothold on one host, only has to listen and then answer. This is a staple of an internal infrastructure penetration test, and it usually works on the first day. MITRE ATT&CK catalogues it as LLMNR/NBT-NS poisoning and SMB relay.
The chain, from a broadcast to a relayed login
Follow it end to end. A workstation broadcasts a name that DNS could not resolve. The attacker's tool answers first, claiming that name belongs to it. The workstation believes the reply and tries to authenticate, because reaching a file share or a proxy endpoint means proving who you are. What it sends is a NetNTLMv2 message: the account name and a challenge-response, never the password itself.
The attacker now holds authentication material that was meant for someone else. The naive move is to crack it offline. The stronger move needs no cracking at all. Because the response is a live negotiation, it can be forwarded, in the moment, to a different server. If that server does not require SMB signing, it accepts the relayed session as though the original user had logged in. The password is never known and never needed. Weakness identifiers CWE-290 and CWE-294 describe the two halves: authentication bypass by spoofing, and by capture then replay.
- Windows client → Attacker
Broadcasts a name DNS could not answer
A typo or a stale mapping, sent to the LAN
- Attacker → Windows client
Vulnerability
Answers and claims the name
LLMNR and NBT-NS trust any reply
- Windows client → Attacker
Sends a NetNTLMv2 response
Account and challenge-response, not a password
- Attacker → File server
Vulnerability
Relays the response to a server
SMB signing not enforced, so it is accepted
- File server → Attacker
Objective reached
Grants a session as the client
Code execution or a secrets dump, no cracking
Capture the response, then choose: crack or relay
Tooling for this is mature and public. A tester starts a responder on the internal interface to answer broadcast lookups: `responder -I eth0`. Anything that authenticates to it is logged as a NetNTLMv2 response in the form `user::DOMAIN:<challenge>:<response>`. That artefact has two uses.
The first is offline cracking. A weak password falls quickly to a wordlist, and the attacker then owns a real credential. The second skips the password entirely. The captured negotiation is relayed live to hosts that do not sign SMB: `ntlmrelayx.py -tf targets.txt -smb2support -c whoami`. On a match, the tool runs a command or dumps the local secrets database as the relayed user. Relaying is the branch that matters, because it defeats a strong password as easily as a weak one. MITRE tracks the relayed-token step as pass the hash via NTLM relay. A red team exercise uses this to move from an unauthenticated position to code execution without a single phishing email.
Where the chain breaks
The chain reads as a long story, but it stands on exactly two defaults. The first is broadcast name resolution that trusts any answer. The second is a server that does not insist its SMB conversations be signed. Remove either and the chain stops, so a network only needs one of the two fixes to be safe from the basic attack, and both to be safe from its variations.
Turning off LLMNR and NBT-NS means the poisoned reply is never solicited. Enforcing SMB signing means a relayed session is rejected even when a broadcast is answered. Monitoring is the third leg: a host that suddenly answers many name lookups it never answered before is a rogue responder, and that is a clean, low-noise detection. Rehearsing all three under real conditions is what a purple teaming engagement is for, pairing the attack with the rule that should fire.
Break the poison
Disable LLMNR
Group Policy, multicast name resolution off
Disable NBT-NS
DHCP option or per-adapter setting
Break the relay
Enforce SMB signing
Require it on servers and clients
Restrict admin
No local admin reused across hosts
See it happen
Alert on responders
Rogue answers to name broadcasts
Seed canaries
Lookups for names that should never resolve
The controls, and what each one removes
Prioritise by what each control removes and what it costs to run, not by how advanced it sounds. Disabling the two legacy protocols and enforcing SMB signing are both configuration changes with no licence attached, and between them they close the path. The harder, longer work is the administrative model underneath: if the account a relay captures is a local administrator reused across many hosts, one relayed login becomes many. Tiered administration and unique local credentials turn a domain-wide event back into a single-host one.
Test the file and print paths before enforcing signing everywhere, since a few legacy devices still stumble on it, but treat that as a compatibility exercise rather than a reason to leave it off. Standards say the same in plainer language: NIST SP 800-115 frames this as internal network testing a defender should be able to detect and withstand, and its guidance is at NIST SP 800-115. Validating the fixes, rather than assuming a Group Policy took effect, is the point of an assumed breach test that starts an operator on the inside.
| Control | Step it removes | Effort |
|---|---|---|
| Disable LLMNR and NBT-NS | The poisoned reply is never sent | Low, Group Policy and DHCP |
| Enforce SMB signing | The relayed session is rejected | Low to medium, test file and print sharing |
| Tiered admin, no credential reuse | A relayed login gains little | Medium, an administrative model |
| Network segmentation | Fewer hosts hear the broadcast | Medium to high, VLAN design |
| Alert on rogue name answers | The attempt is seen early | Low, one detection rule |
What this means for internal networks in the UAE
This attack needs no internet exposure and no malware, only a foothold on the internal network, which makes it a direct test of the segmentation and hardening that UAE regulators already expect. In Dubai, government entities and their suppliers work to the Dubai Electronic Security Centre's information security regulation, which treats internal network controls and monitoring as in scope, not just the perimeter. In Abu Dhabi, ADHICS sets a comparable baseline for the healthcare sector, and the UAE Information Assurance framework applies federally across critical sectors. A bank in either emirate answers to the Central Bank of the UAE. None of these regimes cares whether an attacker came through the firewall or a meeting-room network port; they ask whether you would have seen the movement and contained it.
For an organisation with offices in both Abu Dhabi and Dubai, the practical risk is a flat network that spans sites, where one poisoned lookup reaches far more hosts than it should. Scoping an infrastructure penetration test to include the internal segments, not only the external estate, is what surfaces this before an attacker does, and a broader penetration testing programme keeps the fix verified as the network changes.
Frequently asked questions
What is LLMNR poisoning?
LLMNR poisoning is an attack where a machine on the local network answers Link-Local Multicast Name Resolution and NetBIOS Name Service broadcasts that Windows sends when DNS cannot resolve a name. Because neither protocol verifies who replies, the attacker claims to be the requested host. The victim then tries to authenticate to the attacker, handing over a NetNTLMv2 response.
How does an SMB relay attack differ from pass-the-hash?
Pass-the-hash reuses a stolen NTLM hash to authenticate as a user, so you first need to obtain that hash. An SMB relay never needs the hash at rest: it forwards a live authentication to a second server in real time, and that server accepts it if SMB signing is not enforced. Relaying defeats a strong password because nothing is ever cracked.
Do I need to crack the captured hash to use it?
No. Offline cracking is one option and works against weak passwords, but relaying the captured NetNTLMv2 response to another host bypasses the password entirely. That is why a long, complex password does not protect against the relay branch of this chain.
Does disabling LLMNR and NBT-NS break anything?
In most modern networks that rely on properly configured DNS, disabling them has no user-visible effect, because the fallback only fires when DNS already failed. Test in a pilot group first, since a handful of legacy applications or appliances still depend on NetBIOS name resolution. Where they do, fix the DNS gap rather than leaving the protocol on.
Is SMB signing enough on its own?
Enforcing SMB signing stops the relay to that server, which breaks the most damaging branch of the chain. It does not stop the poisoning itself, so an attacker can still capture responses for offline cracking. Combining SMB signing with disabling LLMNR and NBT-NS closes both routes.
Can this attack work from outside the network?
No. It depends on hearing and answering broadcast name lookups on a local segment, which requires a position on the internal network. That position can come from a physical port, a compromised host, or a rogue device, which is why internal testing and network segmentation matter alongside the perimeter.
How do we detect LLMNR poisoning?
Watch for a host that begins answering name resolution broadcasts it never answered before, which is the signature of a rogue responder. Injected canary lookups for names that should never resolve will also draw a poisoned reply. Both are low-noise signals suited to a detection rule and to rehearsal in a purple team session.
