NetBIOS and LLMNR: The Protocols That Keep Getting Abused

Windows Name Resolution

When a Windows computer needs to resolve a hostname to an IP address, it follows a specific order of operations. First, it checks its local hosts file. Then it queries the configured DNS server. If DNS fails to resolve the name, Windows does not simply give up. It falls back to broadcast-based name resolution protocols: LLMNR and NetBIOS Name Service.

This fallback behavior is the root of the problem. LLMNR and NetBIOS broadcast name queries to the entire local network, and any device can respond. An attacker on the same network segment can answer these queries, pretend to be the requested host, and capture authentication credentials.

This attack vector has been known for over a decade. It still works on default Windows installations in 2026 because both protocols remain enabled by default.

What LLMNR Does

Link-Local Multicast Name Resolution (LLMNR) is defined in RFC 4795. When DNS resolution fails, Windows sends an LLMNR query to the multicast address 224.0.0.252 on UDP port 5355 (IPv4) or ff02::1:3 (IPv6). Every device on the local network segment receives this query.

LLMNR was designed as a peer-to-peer name resolution protocol for small networks without DNS servers. It uses the same packet format as DNS but sends queries via multicast instead of to a specific server. Any device that recognizes the queried name can respond.

The protocol has no authentication mechanism. There is no way for the querying device to verify that the response came from the legitimate owner of the name. Any device on the network can respond to any LLMNR query.

What NetBIOS Name Service Does

NetBIOS Name Service (NBT-NS) operates on UDP port 137. It is even older than LLMNR, dating back to the 1980s. When both DNS and LLMNR fail, Windows falls back to NetBIOS broadcast name resolution.

NetBIOS broadcasts the name query to the entire local subnet (255.255.255.255 or the subnet broadcast address). Like LLMNR, any device on the network can respond, and there is no authentication.

NetBIOS carries additional baggage. It exposes computer names, workgroup/domain membership, logged-in users, and other information through its various services. NBT-NS is just the name resolution component - NetBIOS also includes datagram (UDP 138) and session (TCP 139) services.

The Fallback Chain

graph TD
    subgraph "Windows Name Resolution Order"
        START[Application requests hostname] --> HOSTS[Check hosts file]
        HOSTS -->|Not found| DNS[Query DNS server]
        DNS -->|No response or NXDOMAIN| LLMNR[LLMNR multicast query]
        LLMNR -->|No response| NBT[NetBIOS broadcast query]
        NBT -->|No response| FAIL[Resolution fails]
    end
    subgraph "Attack Window"
        DNS2[DNS fails for typo or nonexistent host] --> LLMNR2[LLMNR query sent to network]
        LLMNR2 --> RESP[Attacker responds with own IP]
        RESP --> AUTH[Victim authenticates to attacker]
        AUTH --> HASH[NTLMv2 hash captured]
    end

When DNS fails, Windows broadcasts name queries - attackers on the network answer them all

The fallback triggers more often than you might expect. DNS failures occur when users mistype server names, when internal DNS is not configured for all resources, when DNS servers are slow to respond, or when applications reference names that only existed on a previous network. Each failed DNS resolution triggers a broadcast that an attacker can exploit.

Responder.py

Responder is a Python tool created by Laurent Gaffie that automates LLMNR/NetBIOS poisoning. When run on a network, it listens for LLMNR and NetBIOS name queries and responds to all of them, claiming to be whatever host the victim is looking for.

Responder also sets up fake services (SMB, HTTP, LDAP, SQL, FTP, and others) to capture authentication attempts. When a victim's machine tries to authenticate to the host it was looking for (now pointing to the attacker's IP), the fake service captures the authentication credentials.

Running Responder requires only a machine on the same network segment as the targets. No special privileges on the network are needed (beyond having a network connection). No exploitation of vulnerabilities is required. The attacker is simply answering questions that Windows is broadcasting to the entire network.

graph TD
    subgraph "Responder Attack Flow"
        V1[Victim types wrong server name] --> V2[DNS returns NXDOMAIN]
        V2 --> V3[LLMNR multicast query sent]
        V3 --> R1[Responder answers with attacker IP]
        R1 --> V4[Victim connects to attacker]
        V4 --> R2[Fake SMB server requests authentication]
        R2 --> V5[Victim sends NTLMv2 response]
        V5 --> R3[Responder captures NTLMv2 hash]
        R3 --> R4[Hash saved to log file]
        R4 --> R5[Crack offline with hashcat]
    end

Responder answers broadcast name queries and captures NTLMv2 hashes from victims who connect

NTLMv2 Hash Capture

When a Windows machine connects to an SMB share (or other NTLM-authenticated service), it sends an NTLMv2 authentication response. This response contains a hash derived from the user's password, a challenge from the server, and other data.

The NTLMv2 hash is not the same as the password, but it is derived from it. An attacker who captures the hash can attempt to crack it offline to recover the plaintext password. The hash can also be used directly in relay attacks (more on that below).

Responder captures these hashes automatically. Every time a victim's machine tries to authenticate to the fake service, the NTLMv2 response is logged. On a busy network, Responder can collect dozens or hundreds of hashes within minutes.

Offline Hash Cracking

Captured NTLMv2 hashes can be cracked offline using tools like hashcat or John the Ripper. The attacker does not need to interact with the network or the victim's machine during the cracking process. They can take the hashes to a machine with powerful GPUs and run through password candidates at billions of attempts per second.

Hashcat supports NTLMv2 cracking natively (mode 5600). With a modern GPU (or a cloud instance with multiple GPUs), a hashcat session can test billions of password candidates per second. Common passwords, dictionary words with substitutions, and shorter passwords fall quickly.

Strong, long passwords (16+ characters, random) are resistant to offline cracking. But in practice, many users choose passwords that are vulnerable. Corporate password policies that require "8 characters with a number and symbol" produce predictable patterns (Password1!, Summer2026#) that wordlist-based attacks find in seconds.

NTLM Relay Attacks

Instead of cracking the hash, an attacker can relay it to another service in real-time. The tool ntlmrelayx (part of the Impacket toolkit) captures the NTLMv2 authentication from a victim and immediately forwards it to a different target server.

If the victim has administrative access to the target server, the relayed authentication grants the attacker administrative access. This can be used to execute commands, access file shares, modify Active Directory objects, or deploy malware - all using the victim's legitimate credentials.

NTLM relay attacks are particularly dangerous because they work even if the password is strong. The attacker does not need to know or crack the password - they just relay the authentication in real-time.

SMB signing prevents relay attacks against SMB services because the relayed session cannot produce valid message signatures. This is why enabling SMB signing on all systems (especially domain controllers) is critical.

How to Disable LLMNR and NetBIOS

Disabling LLMNR and NetBIOS eliminates the attack vector entirely. If Windows does not broadcast name queries, there is nothing for Responder to answer.

Disable LLMNR via Group Policy: Navigate to Computer Configuration > Administrative Templates > Network > DNS Client > Turn Off Multicast Name Resolution. Set it to Enabled (which disables LLMNR - the policy name is confusing).

Disable NetBIOS via DHCP: In your DHCP server configuration, set DHCP option 001 (Microsoft Disable NetBIOS Option) or configure it per scope. Alternatively, on individual machines: Network adapter properties > IPv4 > Advanced > WINS tab > Disable NetBIOS over TCP/IP.

Disable NetBIOS via Group Policy: Use a startup script or PowerShell DSC to configure the NetBIOS setting on each network adapter. There is no single Group Policy setting for NetBIOS across all adapters.

graph TD
    subgraph "Disabling LLMNR and NetBIOS"
        GP[Group Policy Object] --> LLMNR_D[Turn Off Multicast Name Resolution - Enabled]
        DHCP[DHCP Server] --> NBT_D[Set NetBIOS option to Disabled]
        PS[PowerShell Script] --> ADAPT[Set each adapter NetBIOS to Disabled]
        LLMNR_D --> RESULT[No more LLMNR broadcasts]
        NBT_D --> RESULT2[No more NetBIOS broadcasts]
        RESULT --> SAFE[Responder has nothing to answer]
        RESULT2 --> SAFE
    end

Disabling both protocols through Group Policy and DHCP eliminates the poisoning attack vector

Before disabling, verify that no critical applications depend on LLMNR or NetBIOS for name resolution. Applications that reference servers by short names (without a domain suffix) may break if DNS is not configured to resolve those names. Ensure your DNS infrastructure resolves all internal hostnames correctly before removing the broadcast fallback.

Modern Alternatives

mDNS (Multicast DNS) is the modern replacement for LLMNR on local networks. While mDNS has its own security limitations (as discussed in our mDNS article), it is the direction that cross-platform name resolution is moving.

For enterprise environments, the answer is robust DNS infrastructure. Every internal hostname should be resolvable through DNS. DNS suffix search lists should be configured so that short names are resolved correctly. With proper DNS, there is no need for broadcast name resolution fallback.

Active Directory environments should ensure that DNS dynamic updates are working correctly so that all domain-joined machines register their names in DNS automatically. Non-domain machines that need to be resolvable should have static DNS entries or use DHCP-DNS integration.

Understanding these legacy protocols - and the attacks they enable - is part of building a secure network. The BLEShark Nano helps you identify the wireless devices connected to your network, giving you visibility into the environment where these protocols operate and where attackers might be lurking.