How to Detect and Prevent LLMNR/NBNS Poisoning Attacks

Attack scenario:

1. User types \\fileserv01 in Windows Explorer (mistyped \\fileserver01)
2. Windows queries DNS for fileserv01: DNS returns NXDOMAIN
3. Windows sends LLMNR broadcast: "Who has fileserv01?"
4. Attacker's Responder.py answers: "I have fileserv01: 10.0.0.99"
5. Windows initiates SMB authentication to 10.0.0.99
6. Responder captures the NTLMv2 challenge-response hash:
   jsmith::CORP:1122334455667788:AABBCC...:0101000000000000...
7. Attacker cracks with hashcat or relays to another target

Running Responder (attacker perspective: for lab/pentest understanding):

# From Kali Linux on same network segment as target
python3 Responder.py -I eth0 -rdwv
# -r: enable NBT-NS/NBNS poisoning
# -d: enable DHCP poisoning
# -w: start WPAD rogue proxy server
# -v: verbose

# Captured hashes appear in:
cat /opt/Responder/logs/SMB-NTLMv2-SSP-10.0.0.50.txt
# Output: jsmith::CORP:1122334455667788:aabbcc....<truncated>

# Crack with hashcat:
hashcat -m 5600 SMB-NTLMv2-SSP-10.0.0.50.txt rockyou.txt
# -m 5600: NetNTLMv2 hash mode

NTLM relay (no cracking needed: relay directly to another target):

# Instead of cracking, relay captured NTLM auth to a target SMB server
# Run ntlmrelayx alongside Responder (with SMB disabled in Responder to avoid interception)
python3 ntlmrelayx.py -tf targets.txt -smb2support
# If the captured hash belongs to a local admin on targets.txt servers,
# ntlmrelayx authenticates as that user to those servers: no password needed

Disable LLMNR (highest priority: modern networks do not need this protocol):

GPO path:
Computer Configuration > Administrative Templates > Network > DNS Client >
"Turn off multicast name resolution"
Setting: Enabled

# This disables LLMNR on all domain machines the GPO applies to
# Verify: run Wireshark on the network and check for LLMNR queries on port 5355

Disable NBNS (NetBIOS Name Service):

NBNS cannot be disabled via a simple GPO setting: it requires either a DHCP option or registry key pushed via GPO startup script.

# GPO Startup Script to disable NetBIOS over TCP/IP on all adapters:
# Create a script: Disable-NetBIOS.ps1

$NICs = Get-WmiObject Win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled }
foreach ($NIC in $NICs) {
    # 2 = Disable NetBIOS over TCP/IP
    $NIC.SetTcbpNetbios(2)
}

# Link to GPO:
# Computer Configuration > Windows Settings > Scripts (Startup/Shutdown) >
# Startup > Add > Disable-NetBIOS.ps1

# Or via DHCP option 001 in the Windows DHCP server:
# Set scope option 001 (Microsoft Disable Netbios Option) to 0x2 (disable)
# This works for all DHCP clients without requiring a GPO script

Verify LLMNR is disabled:

# On a target machine after GPO applies:
# Attempt an LLMNR query for a non-existent host
Resolve-DnsName nonexistenthost1234 -ErrorAction SilentlyContinue
# Should fail immediately (no broadcast fallback)

# Capture traffic on the segment to verify no LLMNR traffic:
# sudo tcpdump -i eth0 udp port 5355
# Should show no traffic after the GPO applies

# Check current LLMNR status:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" `
  -Name "EnableMulticast" -ErrorAction SilentlyContinue
# 0 = LLMNR disabled

Network-level detection: spurious LLMNR responses:

Legitimate LLMNR does not generate many responses: only the actual host that has the name responds. A Responder instance generates a response to every LLMNR query it sees, generating anomalous response volumes.

# Zeek signature for LLMNR poisoning
# Detect: a host responding to LLMNR queries for names it cannot own
# Key indicator: same source IP responding to LLMNR queries for many different hostnames

# In Zeek dns.log, filter for responses (qtype answers ≠ NXDOMAIN)
# from the same IP for many different hostnames in a short window:
zeek-cut ts id.orig_h id.resp_h query qtype rcode < dns.log | \
  awk '$6 == "0" && $5 == "1"' | \
  awk '{print $2}' | \
  sort | uniq -c | sort -rn | head -10
# Any IP responding to a large number of LLMNR queries is Responder-like behavior

Microsoft Sentinel KQL: detect Responder NTLM capture attempts:

// Alert: NTLM authentication attempts to hosts not in your known server list
// Responder captures auth by pretending to be legitimate servers
SecurityEvent
| where EventID == 4776  // NTLM credential validation
| where TimeGenerated > ago(1h)
// Workstation in 4776 is the machine the user tried to authenticate to
// If that workstation is not a legitimate server, it may be Responder
| where Workstation !in (known_servers)  // Define your server list
| summarize
    FailedAuthCount = count(),
    Accounts = make_set(TargetUserName)
    by Workstation, IpAddress
| where FailedAuthCount > 5
| sort by FailedAuthCount desc

// Or detect: Event 4625 (failed logon) from the Responder machine
// Users attempting to connect to non-existent server get auth failure
SecurityEvent
| where EventID == 4625
| where LogonType == 3  // Network logon
| summarize
    FailCount = count(),
    SourceIPs = make_set(IpAddress),
    TargetAccounts = make_set(TargetUserName)
    by WorkstationName, bin(TimeGenerated, 5m)
| where FailCount > 10

Honey credential detection (active deception):

Deploy a monitoring account in AD whose password you broadcast as a fake service credential. If Responder captures it and an attacker tries to use it:

# Create a monitoring account that should NEVER have valid logons
New-ADUser -Name "svc-backup-monitor" -SamAccountName "svc-backup-monitor" \
  -Enabled $true -AccountPassword (ConvertTo-SecureString "R@nd0mP@ss!" -AsPlainText -Force)

# Create an Azure AD monitoring alert:
# Any 4624 (successful logon) or 4625 (failed logon) from svc-backup-monitor
# is suspicious: this account should never log in

# Alert in Sentinel:

SecurityEvent
| where EventID in (4624, 4625, 4648)
| where TargetUserName == "svc-backup-monitor"
| project TimeGenerated, EventID, IpAddress, LogonType, AuthenticationPackageName
// Any activity on this account = Responder captured the credential

Enable SMB signing (prevents NTLM relay attacks):

GPO path:
Computer Configuration > Windows Settings > Security Settings >
Local Policies > Security Options >
"Microsoft network server: Digitally sign communications (always)": Enabled
"Microsoft network client: Digitally sign communications (always)": Enabled

# SMB signing prevents ntlmrelayx from relaying captured credentials
# to SMB targets: the relay attempt fails signature verification
# Note: SMB signing has performance overhead on high-throughput file servers

Enable Extended Protection for Authentication (EPA) on IIS:

# EPA prevents NTLM relay attacks targeting web services
# Enable in IIS Manager: Authentication > Windows Authentication > Advanced Settings
# Extended Protection: Required

# Or via PowerShell:
Import-Module WebAdministration
Set-WebConfigurationProperty -Filter \
  "system.webServer/security/authentication/windowsAuthentication" `
  -PSPath "IIS:\Sites\Default Web Site" `
  -Name "extendedProtection.tokenChecking" `
  -Value "Require"

Block unnecessary outbound SMB (445/TCP) at the perimeter:

NTLM relay attacks that target external infrastructure require outbound 445. Block this at the firewall: internal SMB traffic stays on the LAN while external relay attempts are stopped.

Network segmentation to limit blast radius:

LLMNR and NBNS are layer-2 broadcast protocols: they only reach hosts on the same network segment. VLANs that separate workstations, servers, and management traffic naturally limit Responder to a single segment. An attacker who has compromised a workstation can only poison LLMNR for other workstations on the same VLAN: not for server VLANs.