From Broadcast to Breach: LLMNR/NBT-NS Poisoning in Action

Description

In earlier versions of Windows networks, the NetBIOS protocol was used to handle communication and services between systems. A key part of this was the NetBIOS Name Service (NBT-NS), which managed name registration and resolution.

Microsoft later introduced Link-Local Multicast Name Resolution (LLMNR) as the successor to NBT-NS. LLMNR provides the same functionality by allowing systems on the same local network to resolve hostnames when DNS is unavailable. It supports both IPv4 and IPv6 and broadcasts queries to all devices on the subnet when a DNS lookup fails.

The weakness of LLMNR and NBT-NS is that they accept responses from any device without authentication. This allows an attacker on the same subnet to respond to name resolution requests and trick a system into sending authentication attempts. Using tools such as Responder, the attacker can capture NTLMv2 hashes, usernames, and domain details, which can then be cracked offline or relayed to other services.

This attack does not rely on exploiting a software vulnerability. It takes advantage of default Windows behavior and only requires the attacker to be present on the same local network segment as the victim.

How can this be a bad thing?

When Windows cannot resolve a hostname through DNS, it falls back to LLMNR or NBT-NS to ask other devices on the local network. The problem is that these protocols do not verify who is responding. Any device on the subnet can reply, and the requesting system will trust the answer.

LLMNR does not require authentication to perform those name resolutions. That means any computer on the local network can send or respond to an LLMNR query. If an attacker is listening on the network, they can intercept these queries and reply with their own information.

During an LLMNR poisoning attack, the attacker listens for LLMNR requests. When a request is broadcast, their device responds with its own IP address, redirecting the victim’s traffic. Once the victim attempts to connect, their system automatically sends authentication data such as NTLMv2 hashes.

An attacker can then capture this authentication data and either crack it offline to recover the password or relay it to other systems in order to gain unauthorized access. In short, the lack of authentication in LLMNR and NBT-NS enables attackers to impersonate trusted systems, capture login details, and move deeper into the network without exploiting traditional software vulnerabilities.

LLMNR Mechanism

LLMNR is a fallback protocol. It kicks in when the normal method for finding a computer on the network, DNS, fails. It’s like shouting a question in a crowded room when you can’t get a hold of the information desk.

Here’s the step-by-step process:

• A DNS Request Fails. A user’s computer tries to connect to a network resource, like \\fileserver. It first asks the official DNS server for the address. If the DNS server doesn’t know the name (maybe it was typed wrong, or the server is offline), it replies, "I don’t know."
• The Computer Asks the Room. With no answer from DNS, the computer sends the same question out as a multicast message to the entire local network segment. It’s like standing up and asking, "Hey, everyone on this local network, which one of you is fileserver?" This message is sent to a specific multicast address (224.0.0.252 for IPv4) that all LLMNR-enabled computers are listening on.
• The Right Computer Answers. The computer that actually has the name fileserver hears the question. It responds directly to the asking computer with a unicast message saying, "That’s me. My IP address is 192.168.1.10."
• The Connection is Made. The original computer now has an IP address. It uses that address to establish a direct connection to fileserver and access the share.

The protocol is built on trust. The asking computer assumes that any answer it gets to its multicast question is truthful. It does not check who is answering or if they are allowed to answer. There is no security to prevent someone from yelling out a lie.

Responder is a popular tool to perform LLMNR poisoning attacks.

What is Responder?

Responder is an open-source penetration testing tool commonly used to exploit weaknesses in network authentication protocols such as LLMNR, NBT-NS, and MDNS. It works by listening for broadcast name resolution requests on a local network and then replying to them in order to impersonate the requested service.

When a victim system tries to connect to the attacker-controlled service, Responder captures authentication data, such as NTLMv2 hashes, usernames, and domain information. These captured credentials can later be cracked offline to recover plaintext passwords or used directly in relay attacks to gain unauthorized access to other systems.

Proof of Concept (PoC)

1- Attacker prepares the environment:

The attacker connects to the same local subnet or VLAN as the target systems and starts Responder in listening mode:

sudo responder -I eth0 -wd

• -I eth0 specifies the network interface
• -w enables WPAD rogue proxy server
• -d enables answers for NBT-NS and LLMNR

2- Victim sends an LLMNR query
A victim machine attempts to resolve a hostname (e.g., fileserver01.local) that DNS cannot resolve. The system falls back to broadcasting an LLMNR request across the local network.

3- Responder intercepts and poisons the request
Responder replies before any legitimate host, claiming ownership of the requested name. The victim accepts the response and attempts to connect to the attacker-controlled system.

Example output:

[LLMNR] Poisoned answer sent to 10.10.1.50 for name fileserver01 [HTTP] NTLMv2 Username : DEMO\\jdoe [HTTP] NTLMv2 Hash : 11223344556677889900AABBCCDDEEFF…

4- Authentication data is captured
Once the victim attempts authentication, Responder records:
1- Username: DEMO\jdoe
2- Domain/workstation: DEMO-WKS01
3- NTLMv2 hash (sample shown above)

5- Cracking the Captured NTLMv2 Hash

1- Captured NTLMv2 hash

From the LLMNR poisoning attack, Responder provides the following

DEMO\jdoe::DEMO-WKS01:1122334455667788:5D2DA2EBB35A3AC:83AD72D79FA919D7422F7F88A36A287:01010000000000008025DBC5783DC0196F21E5C5D000

2- Save the hash to a file

3- Run Hashcat against the NTLMv2 hash

Hashcat mode 5600 is used for NTLMv2:

hashcat -m 5600 -a 0 hash.txt /usr/share/wordlists/rockyou.txt

• -m 5600 → specifies NTLMv2 hash mode
• -a 0 → straight dictionary attack
• /usr/share/wordlists/rockyou.txt → common password list
• If successful, Hashcat will reveal the plaintext password:
  DEMO\jdoe::demo123!

In some cases, if specific services are involved, cleartext credentials may also be captured: Responder captures the credentials in cleartext:

1. The attacker now has direct login credentials for the MSSQL database.

2. This allows unauthorized access to application data, stored procedures, and potentially lateral movement to other systems.

Impact of LLMNR/NBT-NS Poisoning

• Credential Theft
  Attackers can capture NTLMv2 challenge-response hashes or even cleartext credentials (e.g., MSSQL, SMB, LDAP, HTTP).
  These credentials can be cracked offline to reveal plaintext passwords or directly reused in “pass-the-hash” or relay attacks.
• Unauthorized Access
  With valid credentials, attackers can authenticate to databases, file shares, or application servers.
  In your case, captured MSSQL credentials give direct database access, potentially exposing sensitive application data.
• Privilege Escalation
  If privileged accounts (domain admins, service accounts, or database admins) are captured, attackers can escalate quickly to full network control.
• Lateral Movement
  Stolen credentials enable attackers to pivot across the network, accessing other systems and expanding their footprint.
• Data Exfiltration & Service Disruption
  Attackers can extract sensitive information, modify or delete database contents, or disrupt services relying on the compromised accounts.
• No Need for Software Vulnerabilities
  The attack exploits default Windows behavior, not an unpatched vulnerability. This makes it particularly dangerous because many environments remain exposed if LLMNR/NBT-NS is enabled.

Fix & Implementation

1) Disable LLMNR (Group Policy)

GPO path:
Computer Configuration → Administrative Templates → Network → DNS Client → Turn Off Multicast Name Resolution = Enabled

Scope: Apply to all workstations and servers (including VDI).
Verify: On a client, run Get-DnsClient | Select-Object InterfaceAlias,UseMulticast → should be False

2) Disable NetBIOS over TCP/IP (NBT-NS)
NetBIOS is per-adapter. Do this by GPO or PowerShell.
PowerShell (run as admin on endpoints, or via GPO Startup Script):

Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled=TRUE" | ForEach-Object { $_.SetTcpipNetbios(2) } | Out-Null # 2 = Disable NetBIOS over TCP/IP

Verify: Adapter → IPv4 → Advanced → WINS → “Disable NetBIOS over TCP/IP”.

3) Block LLMNR at the network/host firewall (belt-and-suspenders)

• Port: UDP/5355 (LLMNR)
• Windows Defender Firewall rule (local/GPO):

New-NetFirewallRule -DisplayName "Block LLMNR" -Direction Inbound -Protocol UDP -LocalPort 5355 -Action Block
New-NetFirewallRule -DisplayName "Block LLMNR Outbound" -Direction Outbound -Protocol UDP -RemotePort 5355 -Action Block

4) Enforce SMB signing (stops classic NTLM relays to SMB)

GPO paths:

• Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options
• Microsoft network client: Digitally sign communications (always) = Enabled
• Microsoft network server: Digitally sign communications (always) = Enabled

Note: Test legacy apps first; some old NAS devices may break—remediate or isolate.

5) Reduce/Restrict NTLM usage

GPO path:
Security Options → Network security: Restrict NTLM: Audit and restrict NTLM authentication

• Start in Audit to inventory, then move to Deny policies where safe.
• Ensure NTLMv1 is disabled everywhere.

6) Prefer Kerberos; fix DNS so fallback isn’t needed

• Ensure all hosts have correct A/PTR records and DNS suffix search lists.
• Remove stale records; fix duplicate SPNs.
• Make sure services are reachable by FQDN (apps should not rely on short names).

7) Detect & monitor

• EDR/IDS: alert on LLMNR/NBT-NS traffic, Responder/Inveigh binaries, and Option 252 beacons.
• Windows logs: 4624/4625 anomalies; unexpected workstation names; auth to odd IPs.
• Network: look for UDP/5355 bursts and WPAD HTTP hits.

8) Harden LDAP / AD against NTLM relay

On Domain Controllers:

• LDAP signing:
  Domain controller: LDAP server signing requirements = Require signing
• Channel binding: set registry on DCs
  HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding = 2 (DWORD)

Conclusion

LLMNR and NBT-NS poisoning is a classic but still dangerous attack that thrives on default Windows behavior. By simply being on the same subnet, an attacker can impersonate trusted systems, capture NTLMv2 hashes, and potentially recover cleartext credentials. From there, they gain the ability to access sensitive data, move laterally, and escalate privileges without ever exploiting a software vulnerability.

The most effective defense is to eliminate reliance on these legacy protocols by disabling LLMNR and NBT-NS, enforcing secure authentication methods such as Kerberos, and ensuring DNS infrastructure is properly configured. Combined with network monitoring and credential-hardening practices, these measures significantly reduce the risk of credential theft through broadcast poisoning attacks.