Analyzing mDNS and LLMNR for Name Poisoning Attacks

In a well-architected enterprise network, the Domain Name System (DNS) serves as the single source of truth for hostname resolution. However, the reality of modern networking is far more fragmented. From BYOD (Bring Your Own Device) ecosystems to IoT deployments and legacy Windows environments, networks are frequently flooded with "zero-configuration" protocols designed to facilitate seamless device discovery.

While protocols like Multicast DNS (mDNS) and Link-Local Multicast Name Resolution (LLMNR) provide significant usability benefits, they introduce a critical architectural weakness: the reliance on unauthenticated, multicast-based resolution. This post explores the technical mechanics of how these protocols can be exploited via name poisoning attacks and examines the operational challenges of mitigating these risks.

The Mechanics of Name Resolution Fallback

To understand the attack surface, one must first understand the resolution hierarchy. When a client attempts to access a resource (e.g., `\\internal-srv`), the operating system follows a deterministic search order:

1. Local Hosts File: The system checks `/etc/hosts` or `C:\Windows\System32\drivers\etc\hosts`.
2. DNS Query: The system queries the configured DNS server.
3. LLMNR/mDNS Fallback: If the DNS query fails to return an answer (specifically an `NXDOMAIN` or a timeout), the client broadcasts a query to the local subnet via LLMNR or mDNS.

The vulnerability lies in the "fallback" phase. Unlike DNS, which typically relies on a structured, hierarchical, and often authenticated (via DNSSEC) architecture, LLMNR and mDNS operate on a "first-to-respond" principle. There is no inherent cryptographic verification to ensure that the entity responding to the multicast query is the legitimate owner of the hostname.

LLMNR (Link-Local Multicast Name Resolution)

Defined in RFC 4795, LLMNR is primarily a Windows-centric protocol. It utilizes UDP port 5355 and targets the multicast address `224.0.0.251` (IPv4). It is designed to allow hosts on the same link to resolve names without a central server.

mDNS (Multicast DNS)

Defined in RFC 6762, mDNS is the backbone of Apple's Bonjour and various Linux implementations (Avahi). It utilizes UDP port 5353 and targets `224.0.0.251` (IPv4) or `ff02::fb` (IPv6). mDNS is ubiquitous in IoT, printers, and media-sharing devices.

The Anatomy of a Name Poisoning Attack

Name poisoning (or spoofing) occurs when an attacker intercepts a failed DNS resolution attempt and injects a fraudulent response. The goal is to redirect the victim's traffic to an attacker-controlled machine.

The Attack Lifecycle

1. Observation: The attacker monitors the local network segment for LLMNR or mDNS queries. Tools like `Responder` or `Inveigh` are commonly used to listen for these specific UDP broadcasts on ports 5353 and 5355.
2. The Trigger: A user or automated process attempts to access a non-existent or unresolvable hostname (e.g., a typo in a file share path).
3. The Race Condition: The client broadcasts the query. The attacker, seeing the query, immediately crafts a UDP response packet. This response contains the "poisoned" payload: the hostname the user requested, mapped to the attacker's IP address.
4. The Interception: If the attacker's response reaches the client before a legitimate response (if one exists) or before the client's timeout period expires, the client accepts the poisoned entry and updates its local cache.
5. Exploitation (The Payload): Once the client is directed to the attacker's IP, the attacker can execute several high-impact maneuvers:

• NTLM Relay: If the victim attempts to authenticate via SMB or HTTP, the attacker intercepts the NTLM authentication challenge/response and relays it to another server on the network, potentially gaining unauthorized access to sensitive resources.
• Credential Harvesting: The attacker hosts a fake web server or SMB share that prompts the user for credentials, capturing hashes or even cleartext passwords.
• Man-in-the-Middle (MitM): The attacker acts as a transparent proxy, inspecting or modifying traffic between the victim and the intended (but redirected) destination.

Practical Example: The Responder Workflow

Consider an attacker running `Responder` on a compromised workstation in a corporate VLAN.

```bash

Attacker executes Responder on the eth0 interface

sudo python3 responder.py -I eth0 -dwv

```

When a legitimate user types `\\finance-docs` into Windows Explorer, and `finance-docs` does not exist in the DNS zone, the following occurs:

1. The Windows client sends an LLMNR query to `224.0.0.251:5355`.
2. `Responder` intercepts this packet.
3. `Responder` sends a spoofed LLMNR response: `finance-docs is at 10

Conclusion

As shown across "The Mechanics of Name Resolution Fallback", "The Anatomy of a Name Poisoning Attack", "Practical Example: The Responder Workflow", a secure implementation for analyzing mdns and llmnr for name poisoning attacks depends on execution discipline as much as design.

The practical hardening path is to enforce deterministic identity policy evaluation with deny-by-default semantics, certificate lifecycle governance with strict chain/revocation checks, and host hardening baselines with tamper-resistant telemetry. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track detection precision under peak traffic and adversarial packet patterns and certificate hygiene debt (expired/weak/mis-scoped credentials), then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.