ER SEGMENTPROTOCOL LAB
LOCAL NETWORK · UDP 5355 / 137

How LLMNR and NetBIOS Name Resolution Work, and Name Poisoning (Animated)

When DNS can’t resolve a name (often just a typo like \\FS1 instead of \\FS01), Windows falls back to asking the entire local network: “Does anyone know FS1?” using LLMNR and NetBIOS Name Service. Nothing verifies who answers, which makes it one of the most common internal-network weaknesses found in penetration tests.

1. Dns fails: a typo nobody can find

The user types \\FS1. The DNS server has no such name and says so.

  1. DNS QUERY (User PC → File server): The PC asks DNS first (here the file server also runs DNS).
  2. NXDOMAIN (File server → User PC): DNS says the name does not exist.

Wireshark filter:

dns.flags.rcode == 3

2. Ask everyone: llmnr multicast to the whole lan

Instead of giving up, Windows multicasts the question to every device on the local network.

  1. LLMNR (User PC → everyone on the LAN): Every machine on the LAN receives the question, including the attacker.

Wireshark filter:

llmnr

3. Name poisoning: attack: “yes, that’s me!”

The attacker’s machine answers every such question with its own address. The PC believes it and connects, and Windows automatically tries to log in with the user’s credentials, handing the attacker a login exchange to abuse.

  1. LLMNR (User PC → everyone on the LAN): The same question.
  2. LLMNR REPLY (Attacker (same LAN) → User PC): A false answer, and nothing checks it.
  3. SMB LOGIN (User PC → Attacker (same LAN)): Windows tries to log in to “FS1”, sending Priya’s authentication to the attacker.

Wireshark filter:

llmnr && ip.src == 192.168.1.66

4. Turn them off: defence: disable the fallbacks

Disable LLMNR and NetBIOS over TCP/IP by Group Policy, fix DNS so names resolve properly, require SMB signing, and have the SOC watch for LLMNR answers coming from unexpected machines.

  1. DNS QUERY (User PC → File server): DNS still says no such name…
  2. NXDOMAIN (File server → User PC): …and the PC simply shows “path not found”. Nobody gets the chance to answer falsely.

Group policy:

Computer Config → Admin Templates → Network → DNS Client → Turn off multicast name resolution = Enabled
Network adapter → NetBIOS over TCP/IP = Disable

Practise this in a real lab

Watch LLMNR traffic on a lab network, see the risk first-hand in an isolated Active Directory lab, then switch it off by Group Policy.

Explore ER Segment training →

FAQ

What are LLMNR and NBT-NS?

Link-Local Multicast Name Resolution (UDP 5355) and NetBIOS Name Service (UDP 137): fallbacks that ask the local network when DNS fails.

Why are they dangerous?

Any device on the network can answer, and Windows will then try to authenticate to whoever answered.

Does disabling them break anything?

Rarely in a network with working DNS. Test first, then disable by Group Policy.

ER SEGMENT · PROTOCOL LAB · CYBERSECURITY IS IN OUR DNA