LLMNR Poisoning

How LLMNR poisoning works

LLMNR poisoning succeeds because devices fall back to a local, unauthenticated name-resolution path when DNS does not answer. An attacker on the same broadcast domain can answer those queries first, causing hosts to trust a malicious responder and redirecting credential-bearing traffic or authentication handshakes to the attacker instead.

This attack is especially effective in flat or poorly segmented networks, where many devices can hear the same multicast traffic and where legacy Windows name-resolution fallbacks remain enabled. Once a target accepts the false response, the attacker can often stay invisible to the user while the traffic flow is quietly diverted.

Because the technique abuses normal host discovery rather than exploiting a software flaw, the practical danger is less about one vulnerable application and more about a trust assumption in the local network. That makes the attack portable across many systems that still rely on fallback name resolution.

Why LLMNR poisoning is dangerous

The main danger is that a forged answer can turn a routine lookup into an interception point for credentials, challenge-response exchanges, or follow-on relay attempts. In environments that still permit NTLM fallback, the poisoned response can create a path from simple name-resolution abuse to authentication abuse and privilege escalation.

LLMNR poisoning also works well as an opportunistic capture method because it needs only local network reachability and a device willing to ask the fallback question. In practice, that makes it attractive in internal phishing, post-compromise pivoting, rogue access point scenarios, and any environment where an attacker can share a segment with potential victims.

For a deeper view of how this fits into broader interception and relay patterns, see NHIMG’s Man-in-the-Middle Attacks Guide and NTLM Relay Guide.

How organisations reduce exposure

The most effective reduction step is to remove or limit the fallback behaviour that makes the attack possible, then make local-network abuse harder through segmentation and tighter protocol controls. In Windows-heavy estates, that usually means treating name-resolution poisoning as part of a broader hardening effort rather than as a standalone quirk.

Exposure review should start with asset inventory and network placement: identify systems that still permit LLMNR or related fallback behaviour, then check whether those hosts sit on shared user networks, Wi-Fi segments, or other places where an attacker could answer broadcast traffic. Vendor advisories and platform guidance remain the authoritative source for exact configuration options.

NHIMG’s Network Ports and Protocols Security Guide is useful here because it places LLMNR alongside other risky network services and insecure protocol choices that deserve removal or isolation.

Detection and post-compromise review

Detection is partly network-based and partly authentication-based. On the network side, watch for repeated multicast or broadcast name-resolution responses from unexpected hosts. On the identity side, review whether machines began authenticating to unusual endpoints shortly after a name-resolution failure, especially when the session later led to NTLM or relay activity.

After suspected poisoning, investigate whether credentials, hashes, session material, or service tokens were exposed during the interaction and whether any downstream lateral movement occurred. If compromise is confirmed or strongly suspected, rotate the impacted secrets and review adjacent accounts or systems that may have been reachable from the captured authentication.

NHIMG’s Lateral Movement Guide and MITRE ATT&CK T1557 Adversary-in-the-Middle both help place LLMNR poisoning in the attack chain that follows local interception.

Practitioner Guidance

Why practitioners should care: LLMNR poisoning is not just an old Windows nuisance, it is a practical interception primitive that can expose credentials and create a bridge into relay, lateral movement, and privilege escalation. Treat it as a network trust problem, not only a host configuration issue.

What to watch for: Prioritise environments where fallback name resolution is still enabled, SMB and NTLM remain widely usable, or segmentation lets an attacker hear many victims on the same layer 2 domain. Those conditions make the attack both easier to launch and harder to contain.

Practitioner takeaway: The safest long-term posture is to remove the fallback path, constrain local broadcast reach, and verify that detection covers both poisoned responses and the authentication activity that follows.

Related resources from NHI Mgmt Group

• Why do LLMNR poisoning attacks create such a high risk for credential theft in Windows environments?
• What are the signs that LLMNR poisoning is going undetected in an enterprise network?
• How do attackers use LLMNR/NBT-NS poisoning and relay?
• How can security teams detect LLMNR/NBT-NS poisoning and relay attacks?