Description

In earlier Windows network environments, the NetBIOS protocol played a central role in system communication. One of its core components, the NetBIOS Name Service (NBT-NS), was responsible for name registration and resolution within local networks.

To modernize this functionality, Microsoft introduced Link-Local Multicast Name Resolution (LLMNR ) as a successor to NBT-NS. LLMNR enables hostname resolution on local networks when DNS fails, supporting both IPv4 and IPv6. Instead of relying on a centralized server, it broadcasts queries to all devices within the same subnet, allowing any host to respond.

However, both LLMNR and NBT-NS suffer from a critical design weakness: they do not authenticate responses. As a result, any device on the local network can reply to name resolution requests. This opens the door for attackers to impersonate legitimate systems and intercept network traffic.

By leveraging tools such as Responder, an attacker can respond to these broadcast requests and trick victim machines into initiating authentication attempts. This process allows the attacker to capture sensitive information, including NTLMv2 hashes, usernames, and domain details. These credentials can then be cracked offline or relayed to other services to gain unauthorized access.

Importantly, this attack does not exploit a traditional software vulnerability. Instead, it abuses default Windows behavior and only requires the attacker to be present on the same local network segment as the target.

Why Is This a Security Risk?

When a Windows system fails to resolve a hostname via DNS, it automatically falls back to LLMNR or NBT-NS. These protocols broadcast requests across the local network, trusting any response they receive without verification.

Because no authentication is required, any device on the subnet can respond to these queries. An attacker monitoring the network can intercept such requests and reply with a malicious response, effectively redirecting the victim’s traffic.

In an LLMNR poisoning attack, the attacker listens for broadcasted name resolution requests and responds with their own IP address. This causes the victim to initiate a connection to the attacker’s system. During this process, the victim automatically sends authentication data, such as NTLMv2 hashes.

The attacker can then capture this data and either crack it offline to recover plaintext credentials or relay it to other systems to authenticate as the victim. Ultimately, the absence of authentication in LLMNR and NBT-NS allows attackers to impersonate trusted resources, harvest credentials, and move laterally within the network all without exploiting conventional software flaws.

LLMNR Mechanism

LLMNR (Link-Local Multicast Name Resolution) is a fallback name resolution protocol used when DNS fails to resolve a hostname on a local network. It can be thought of as a backup mechanism that allows devices to “ask the local network” for a name when the usual directory service cannot provide an answer.

Here is how the process works step by step:

1. DNS resolution fails
A user’s computer attempts to access a network resource, such as \\fileserver. It first queries the configured DNS server to resolve the hostname into an IP address. If DNS cannot resolve the name due to a typo, missing record, or server unavailability, it responds with a failure or “unknown host.”

2. The system broadcasts a local request
After DNS fails, the computer sends an LLMNR query to the local network. Instead of targeting a specific server, it uses multicast communication to reach all devices on the subnet. This is similar to asking: “Does anyone on this local network know the IP address of fileserver?”
For IPv4, this query is sent to the multicast address 224.0.0.252, which all LLMNR-enabled systems listen on.

3. A device responds
Any system on the local network that recognizes the requested name can respond. The machine that actually hosts fileserver replies directly to the requester with its IP address, for example: 192.168.1.10.

4. Connection is established
The requesting system receives the response and proceeds to connect directly to the provided IP address, allowing access to the shared resource.

The key issue with LLMNR is that it is built on implicit trust. Any device on the network is allowed to respond to queries, and the requesting system does not verify the authenticity of the responder. There is no built-in authentication or validation mechanism, meaning a malicious device can impersonate a legitimate host simply by replying faster than the real one.

Scenario Example LLMNR/NBT-NS Poisoning

Let’s go through another high-level example of how this attack can unfold:

1. A user tries to access a shared folder on the network by typing \\finance-share, but mistakenly enters \\finanace-share.
2. DNS is queried first, but it cannot resolve the incorrect hostname and returns that the resource is unknown.
3. Since DNS fails, the system falls back to LLMNR/NBT-NS and broadcasts a request across the local network asking if any device knows the location of \\finanace-share.
4. An attacker on the same network, running a tool such as Responder, detects this request and replies, falsely claiming to be the requested file server.
5. The victim’s system trusts the response and automatically initiates an authentication attempt to the attacker’s machine, sending credentials in the form of an NTLMv2 hash.
6. The attacker can then capture this hash and either attempt to crack it offline to recover the plaintext password or relay it to other services to gain unauthorized access, depending on the environment and configuration.

Technical Overview and Practical Implementation

Ehxb@KanSec[/Home]$ responder -h
                                         __
  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|
           NBT-NS, LLMNR & MDNS Responder 3.0.6.0
  Author: Laurent Gaffie ([email protected])
  To kill this script hit CTRL-C
Usage: responder -I eth0 -w -r -f
or:
responder -I eth0 -wrf
Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -A, --analyze         Analyze mode. This option allows you to see NBT-NS,
                        BROWSER, LLMNR requests without responding.
  -I eth0, --interface=eth0
                        Network interface to use, you can use 'ALL' as a
                        wildcard for all interfaces
  -i 10.0.0.21, --ip=10.0.0.21
                        Local IP to use (only for OSX)
  -e 10.0.0.22, --externalip=10.0.0.22
                        Poison all requests with another IP address than
                        Responder's one.
  -b, --basic           Return a Basic HTTP authentication. Default: NTLM
  -r, --wredir          Enable answers for netbios wredir suffix queries.
                        Answering to wredir will likely break stuff on the
                        network. Default: False
  -d, --NBTNSdomain     Enable answers for netbios domain suffix queries.
                        Answering to domain suffixes will likely break stuff
                        on the network. Default: False
  -f, --fingerprint     This option allows you to fingerprint a host that
                        issued an NBT-NS or LLMNR query.
  -w, --wpad            Start the WPAD rogue proxy server. Default value is
                        False
  -u UPSTREAM_PROXY, --upstream-proxy=UPSTREAM_PROXY
                        Upstream HTTP proxy used by the rogue WPAD Proxy for
                        outgoing requests (format: host:port)
  -F, --ForceWpadAuth   Force NTLM/Basic authentication on wpad.dat file
                        retrieval. This may cause a login prompt. Default:
                        False
  -P, --ProxyAuth       Force NTLM (transparently)/Basic (prompt)
                        authentication for the proxy. WPAD doesn't need to be
                        ON. This option is highly effective when combined with
                        -r. Default: False
  --lm                  Force LM hashing downgrade for Windows XP/2003 and
                        earlier. Default: False
  -v, --verbose         Increase verbosity.

As demonstrated earlier in the module, using the -A flag places Responder into analyze mode. In this mode, it passively monitors the network and displays NBT-NS, BROWSER, and LLMNR requests without actively poisoning or responding to them. An interface or IP address must always be specified for proper operation.

Several commonly used options enhance functionality depending on the testing scenario. The -wf flag enables the built-in WPAD rogue proxy server, while -f is used to fingerprint remote hosts, identifying their operating system and version. The -v flag increases verbosity, which can be useful for troubleshooting but generates significantly more output in the console. Additional options such as -F and -P can force NTLM or Basic authentication and enforce proxy authentication; however, these may trigger login prompts and should be used with caution. The -w option activates the WPAD proxy service, which can be particularly effective in larger environments where browsers with auto-detect proxy settings (such as Internet Explorer) may automatically route traffic through it, allowing HTTP session capture.

When configured and running, Responder listens for network name resolution and authentication-related requests. If a credential capture is successful, the tool immediately displays the captured hash in the terminal and stores it in a log file per target host under /usr/share/responder/logs. The naming format typically follows MODULE_NAME-HASH_TYPE-CLIENT_IP.txt. For example, a captured SMB authentication attempt may be saved as SMB-NTLMv2-SSP-172.16.5.25. By default, one entry is printed to the console unless verbose mode is enabled. In addition to log files, captured hashes are also stored in a SQLite database, which can be configured through the Responder.conf file located in /usr/share/responder, or within a cloned GitHub version of the tool.

The tool must be executed with root or sudo privileges to function correctly. It also requires that specific network ports are available on the attack system for proper operation. These typically include:

UDP 137, UDP 138, UDP 53, UDP/TCP 389, TCP 1433, UDP 1434,
 TCP 80, TCP 135, TCP 139, TCP 445, TCP 21, TCP 3141, 
TCP 25, TCP 110, TCP 587, TCP 3128,
 as well as multicast UDP 5355 and 5353.

Finally, individual rogue services such as SMB can be selectively enabled or disabled through the Responder.conf configuration file, depending on the testing requirements.

Responder Logs

Ehxb@KanSec[/Home]$$ ls
Analyzer-Session.log                Responder-Session.log
Config-Responder.log                SMB-NTLMv2-SSP-172.16.5.200.txt
HTTP-NTLMv2-172.16.5.200.txt        SMB-NTLMv2-SSP-172.16.5.25.txt
Poisoners-Session.log               SMB-NTLMv2-SSP-172.16.5.50.txt
Proxy-Auth-NTLMv2-172.16.5.200.txt

When Responder successfully captures authentication data, each captured hash is saved into a separate file based on the service, protocol, and source host. As shown above, every target system and authentication type is organized into its own log file, making it easier to analyze and process the collected credentials.

For example, different files may contain SMB, HTTP, or proxy authentication attempts from various IP addresses, all stored separately for clarity and tracking.

Once configured, starting a Responder session is straightforward:

Starting Responder with Default Settings

sudo responder -I ens224

LLMNR and NBT-NS poisoning demonstrate how legacy Windows name resolution mechanisms can be abused to capture sensitive authentication data. Because these protocols rely on trust and do not validate responses, any device on the same local network can impersonate a legitimate host and intercept credential requests.

Tools like Responder automate this process by listening for broadcast name resolution traffic and responding to it with malicious replies. When successful, this leads to the capture of NTLMv2 hashes and other authentication data, which can then be used for offline cracking or relay attacks.

Ultimately, this attack highlights a critical security lesson: even without exploiting software vulnerabilities, default network behaviors and misconfigurations can expose organizations to serious credential theft risks. Proper mitigation, such as disabling LLMNR/NBT-NS and enforcing secure authentication protocols, is essential to reduce this attack surface.