Hands-On Tutorial: Advanced LLMNR/NBT-NS Poisoning & NTLM Relay Masterclass (2026 Edition)

Hands-On Tutorial: Advanced LLMNR/NBT-NS Poisoning & NTLM Relay Masterclass (2026 Edition)

Executive Summary & BLUF

In modern Windows Active Directory networks, legacy broadcast and multicast name resolution protocols — specifically Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) — remain enabled by default for backward compatibility.

When a user attempts to connect to a network resource (such as a shared folder) and DNS resolution fails, the Windows client broadcasts a request to all nearby devices on the local subnet asking, "Who knows the IP address for this resource?" Because these legacy protocols lack cryptographic authentication, any machine on the subnet can respond to the request.

• Primary Vulnerability: Unauthenticated broadcast name resolution (LLMNR / NBT-NS).
• Attack Vectors: NetNTLMv2 credential harvesting and real-time NTLM authentication relaying (MITRE ATT&CK T1557.001).
• Core Defenses: Group Policy Objects (GPO) to disable LLMNR/NBT-NS, mandatory SMB Signing, LDAP Channel Binding, and SIEM detection rules.

Step 0: Intuition & Mental Model (First Principles)

To understand why this protocol weakness exists, consider how a person looks up directions in an unfamiliar city.

The "Lost Traveler" Analogy

1. Step 1 (DNS - The Official Map): The traveler looks at an official street map (Domain Name System). If the address is listed on the map, they walk directly to their destination.
2. Step 2 (LLMNR/NBT-NS - Shouting in a Crowd): If the address is missing from the map (e.g. a typo like \\filesrver instead of \\fileserver), the traveler stands in the middle of the crowded town square and shouts out loud: "Does anyone know where filesrver is?"
3. Step 3 (The Rogue Answer): A untrustworthy bystander (an unauthorized device on the local network) hears the shout and instantly replies: "Yes! I am filesrver. Send me your credentials so I can let you in."
4. Step 4 (Authentication Handshake): The traveler attempts to authenticate with the bystander, inadvertently handing over a challenge-response hash.

Step 1: Protocol Architecture & The NTLM Handshake

When a Windows machine attempts to connect to an SMB file share, it undergoes the NTLM challenge-response authentication process.

NTLM Challenge-Response Flow Diagram

 [ Victim Client ]                              [ Target Server / Rogue Listener ]
        |                                                       |
        | ----- (1) Type 1: Negotiate Message ----------------> |
        |                                                       |
        | <---- (2) Type 2: Challenge Message (8-byte nonce) -- |
        |                                                       |
        | ----- (3) Type 3: Authenticate Message -------------> |
        |           (Encrypted Response using NT Hash)          |

Protocol Sequence Breakdown

1. Type 1 (Negotiate): The client notifies the server of supported NTLM options and security capabilities.
2. Type 2 (Challenge): The server generates a random 8-byte challenge string (nonce) and sends it back to the client.
3. Type 3 (Authenticate): The client encrypts the 8-byte challenge using a key derived from the user's password hash (NT Hash) and returns the NetNTLMv2 response to the server.

Step 2: Isolated Lab Setup & Infrastructure Topology

All research and testing must take place within an isolated virtual lab environment.

Lab Topology Diagram

                     +----------------------------------+
                     | Attacker Host (Kali / Arch)      |
                     | IP: 192.168.56.20                |
                     +----------------------------------+
                                      |
         ================== Isolated L2 Subnet ==================
         |                            |                         |
         v                            v                         v
+------------------+        +------------------+      +-------------------+
| DC01 (AD Domain  |        | WORKSTATION01    |      | WORKSTATION02     |
| Controller)      |        | (Windows 11)     |      | (Windows 10)      |
| IP: 192.168.56.10|        | IP: 192.168.56.101      | IP: 192.168.56.102|
+------------------+        +------------------+      +-------------------+

Step 3: Phase-by-Phase Guided Implementation

Phase 1: Identifying Unauthenticated Protocols with Nmap

Before auditing broadcast responses, verify which SMB signing and name resolution controls are active across target hosts.

# Nmap scan checking SMB Signing requirements across subnet
nmap -p 445 --script smb-security-mode 192.168.56.0/24

Understanding Nmap Output

• Message signing enabled and required: Host enforces SMB signing. Relaying authentication to this machine will fail.
• Message signing enabled but not required: Host accepts unsigned SMB connections. This host is vulnerable to NTLM authentication relay attacks.

Phase 2: Intercepting Credentials Safely in Lab Environments

Tools like Responder act as passive rogue listeners, answering incoming LLMNR and NBT-NS queries on the local subnet.

Key Settings in Responder.conf

[Responder Core]
; Line 12: Enable LLMNR rogue listener
LLMNR = On

; Line 15: Enable NBT-NS rogue listener
NBT-NS = On

; Line 18: Enable WPAD rogue proxy listener
WPAD = On

; Line 30: Enable Authentication Servers
SMB = On
HTTP = On

Line-by-Line Configuration Annotations

• LLMNR = On: Configures Responder to listen on UDP port 5355 for multicast name queries.
• NBT-NS = On: Listens on UDP port 137 for NetBIOS name requests.
• SMB = On: Spawns a rogue SMB service on TCP port 445 that responds to authentication attempts with an NTLM challenge.

Step 4: Troubleshooting & Edge Cases ("Why Attacks Fail")

Understanding why network security controls block relay or poisoning attempts builds deep security intuition.

Step 5: Blue Team Remediation & Hardening Guide

Eliminating broadcast name resolution vulnerabilities requires disabling legacy protocols across the enterprise via Group Policy Objects (GPO).

1. Disabling LLMNR via Group Policy (GPO)

1. Open Group Policy Management Console (gpmc.msc).
2. Navigate to: Computer Configuration -> Administrative Templates -> Network -> DNS Client.
3. Locate Turn off multicast name resolution.
4. Set policy status to Enabled.

2. Disabling NBT-NS via Network Adapter Settings

# PowerShell command to disable NetBIOS over TCP/IP across all network interfaces
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_*' -Name NetbiosOptions -Value 2

3. Enforcing SMB Signing Across All Domain Hosts

1. Navigate to: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
2. Set Microsoft network server: Digitally sign communications (always) to Enabled.

Summary & Mastery Checklist

• Intuition Mastered: Understood LLMNR/NBT-NS as unauthenticated fallback shouting when DNS fails.
• Protocol Mechanics: Mapped the 3-step NTLM challenge-response handshake sequence.
• Defensive Controls: Identified how SMB Signing and EPA prevent authentication relaying.
• Enterprise Hardening: Applied GPO settings to disable legacy broadcast name resolution across Active Directory endpoints.

Authored by Syed Zada Abrar — Founder & Lead Researcher, Andrax Pentester.