LLMNR poisoning is an attack against Link Local Multicast Name Resolution, a fallback name resolution method used when DNS fails. An attacker responds to broadcast queries on the local network, tricks devices into trusting a malicious host, and can then collect credentials or support further privilege escalation.
Expanded Definition
LLMNR poisoning is a local network name resolution attack that abuses Link-Local Multicast Name Resolution, which some Windows environments use when DNS does not answer. The attacker listens for unresolved name queries and replies first, causing a victim to treat the attacker as the requested host.
That distinction matters because LLMNR is a fallback protocol, not a primary directory service. It is often enabled implicitly by default or legacy configuration, so the real boundary is not “can this resolve names” but “should this broadcast fallback exist at all on a trusted segment.” A common misunderstanding is to treat LLMNR as harmless noise because it only operates on the local subnet; in practice, it can become a credential-capture primitive when clients authenticate to the spoofed responder.
Guidance vs consensus: there is strong practitioner consensus that disabling LLMNR is preferable in most enterprise networks, but the exact rollout path depends on endpoint mix, Windows policy control, and any legacy application that still relies on multicast name resolution. For background on the protocol itself, the Microsoft overview of Link-Local Multicast Name Resolution is the most direct reference.
Examples and Use Cases
- A workstation cannot reach a file share by DNS name, emits an LLMNR query, and a rogue host answers with a malicious SMB endpoint.
- A penetration tester or red team operator uses the broadcast response window to capture NTLM challenge-response traffic from nearby endpoints.
- A flat office network with permissive multicast discovery allows one compromised laptop to impersonate common internal names for other hosts on the segment.
- A legacy branch environment keeps LLMNR enabled because a small application stack still depends on fallback name resolution, creating a tradeoff between compatibility and exposure.
The operational tradeoff is straightforward: the protocol can improve resilience when DNS is unavailable, but that same fallback behavior creates an easy spoofing opportunity on shared broadcast domains. In practice, the risk rises with noisy, undersegmented networks where many clients can see the same multicast traffic.
Security Implications
When LLMNR poisoning succeeds, the immediate problem is not just incorrect name resolution. The attacker can position a malicious service in the middle of a normal authentication flow, then collect hashes, relay authentication attempts, or steer the victim toward a hostile resource.
Failure mechanism: the victim trusts a local response because the fallback protocol has no strong identity validation for the responder. That trust gap is especially dangerous where Windows endpoints will automatically try SMB, HTTP, or related protocols after resolving the name, allowing credential material to be exposed without an obvious user-visible error.
Impact: one poisoned query can lead to credential theft, lateral movement, and escalation from a single host to broader domain access if captured credentials are reused or relayable. A practical observation for defenders is that repeated unexplained multicast name queries often indicate either misconfiguration or active abuse, and both deserve investigation.
Domain and Governance Relevance
LLMNR poisoning is a network security problem first, but its governance impact is usually felt through endpoint hardening and control standardisation. The term matters because it is often a sign that a legacy fallback service is still allowed to operate where DNS hygiene, segmentation, and secure name resolution should have made it unnecessary.
For identity and access governance, the key change is that a seemingly simple broadcast protocol can become a credential interception path. That means authentication safeguards are only partly effective if endpoint clients will still negotiate with unauthenticated local responders. Disabling LLMNR, constraining related name-resolution fallbacks, and reducing broadcast reach are therefore control decisions, not just network preferences.
In mixed estates, the question is rarely whether LLMNR exists somewhere, but whether its residual use is knowingly accepted, measured, and contained. Where it remains enabled, defenders should treat it as a control exception with an explicit business reason rather than an assumed default.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay | Directly covers LLMNR poisoning as a local name-resolution abuse. |
| Recommendation — Detect broadcast poisoning activity and disable LLMNR/NBT-NS to remove the attack path. | ||
| CIS Controls v8 | 8.2 — Unapproved and Unauthorized Software | Covers preventing legacy discovery services and unsafe local attack surfaces. |
| Recommendation — Remove or block legacy multicast name-resolution services that expand local exposure. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations Are Managed | Maps to controlling authentication paths that can be abused after spoofed resolution. |
| PR.PT-4 — Communications and Control Networks Are Protected | Applies to protecting broadcast and local-link communication channels used in the attack. | |
| Recommendation — Tighten authentication paths so spoofed local responders cannot obtain reusable credentials. Segment local broadcast domains and restrict unnecessary multicast traffic. | ||
