Operator On The Wire
← Back to Knowledge Base
BLUE TEAM / SOC / FILTERING / ATTACKS / TRANSPORT LAYER / UDP

LLMNR NBNS Poisoning


Filters

# General

smb2 
ntlmssp
ntlmssp.auth or ntlmssp.negotiate or ntlmssp.challenge

# Challenge packets

ntlmssp.messagetype == 0x00000002
ntlmssp.challenge
smb2 && ntlmssp.messagetype == 0x00000002

# Combined Filter

(llmnr or nbns) and ntlmssp
llmnr
nbns
udp.port == 5355   # LLMNR
udp.port == 137    # NBNS

Overview

  • LLMNR (Link-Local Multicast Name Resolution) and NBNS (NetBIOS Name Service) are fallback name resolution protocols.
  • Used when DNS fails.
  • No authentication → easily spoofed.
  • Attackers respond faster than legitimate hosts to capture NTLM hashes.

Attack Flow

  1. Victim tries to resolve hostname (e.g., \fileserver)
  2. DNS fails → fallback to LLMNR/NBNS
  3. Broadcast request sent
  4. Attacker responds: “I am that host”
  5. Victim initiates NTLM authentication
  6. Attacker captures NTLMv2 hash (Responder, Inveigh)

Key Detection Patterns

1. Suspicious LLMNR/NBNS Responses

  • Multiple responses to same query
  • Response from non-authoritative host
llmnr.flags.response == 1
nbns.flags.response == 1

2. NTLM Authentication Sequence Timing

Look for 3-step handshake:

  1. NTLMSSP_NEGOTIATE
  2. NTLMSSP_CHALLENGE
  3. NTLMSSP_AUTH

Detection Idea:

  • Very fast sequence → attacker on same LAN
  • All 3 packets within milliseconds

3. Extract NTLM Data

Fields to inspect:

  • ntlmssp.auth.username
  • ntlmssp.auth.domain
  • ntlmssp.auth.host
  • ntlmssp.ntlmv2_response

4. Repeated Name Resolution Failures

Indicators:

  • Same hostname queried multiple times
  • No DNS success → fallback triggered
llmnr and dns == 0

5. Unusual Source Responding

  • Workstation responding to name queries instead of server
  • Non-DNS server answering many queries

6. Broadcast Storm / Poisoning Tool

Indicators:

  • High volume LLMNR/NBNS responses
  • Same MAC responding to many names
eth.src == TARGET_MAC and (llmnr or nbns)

DFIR Workflow

  1. Filter:

    llmnr or nbns
    
  2. Identify queries → who is asking

  3. Identify responses → who is answering

  4. Check if responder is legitimate

  5. Pivot to NTLM:

    ntlmssp
    
  6. Track authentication sequence

  7. Extract credentials


Red Flags Summary

  • Multiple responses to one query
  • Workstation acting as name server
  • NTLM authentication over LLMNR/NBNS
  • Fast NTLM handshake timing
  • Repeated unresolved hostname queries
  • Same MAC answering everything

Tools

  • Responder (classic attack tool)
  • Inveigh (PowerShell version)
  • Wireshark
  • Zeek (ntlm logs)

Defense

  1. Disable LLMNR via GPO
  2. Disable NetBIOS over TCP/IP
  3. Enforce SMB signing
  4. Use strong passwords (prevent cracking)
  5. Network segmentation
  6. IDS rules for NTLM over LLMNR/NBNS