Security teams detect LLMNR/NBT-NS poisoning and relay attacks by monitoring for repeated name-resolution responses from unexpected hosts, especially where clients fall back to multicast or broadcast lookups. Look for authentication attempts that follow those responses and for traffic between workstations and unusual relay targets. Disabling unnecessary name resolution methods reduces exposure.
How poisoning and relay attacks show up in network telemetry
Detection starts with the name-resolution pattern itself. In a healthy environment, clients should not be repeatedly broadcasting or multicasting queries and then accepting answers from unexpected peers. When those responses are followed by authentication handshakes or NTLM activity, the sequence is often more informative than any single packet, because poisoning and relay rely on turning ordinary fallback behaviour into an access path.
Watch for abrupt shifts from normal DNS-driven resolution to LLMNR or NBT-NS, especially on subnets where those protocols should be rare. If several hosts answer the same query, or if the responder is not a known infrastructure service, treat that as a strong lead rather than noise. The same applies when a workstation begins talking to an unusual relay target soon after a name-resolution response.
Correlating those signals is easier if you compare them with the expected protocol surface for the environment. The Network Ports and Protocols Security Guide is useful for separating normal SMB, NetBIOS, and related traffic from the traffic patterns that often accompany poisoning and relay setups.
Which hosts and sessions deserve immediate scrutiny
The most useful investigation focus is not every name-resolution event, but the combinations that indicate an attacker is trying to capture or reuse authentication. Look for a workstation that answers queries it should not answer, then observe whether that response is followed by inbound authentication from another host, especially in the same broadcast domain. Relay attacks become more likely when the target accepts authentication without strong channel protections.
Session context matters. A single spoofed response may be harmless if no client uses it, but a matching authentication attempt, a login to an administrative share, or a sudden SMB session to a non-standard endpoint raises the priority immediately. At scale, repeated patterns across multiple hosts usually indicate a responder tool is active rather than a one-off misconfiguration.
That is why lateral-movement evidence is so important here. The Lateral Movement Guide helps connect name-resolution abuse to the downstream behaviors that often follow successful relay, including remote-service access and credential reuse.
Why the control question is really about reducing the attack surface
Detection is only half the job. Poisoning and relay are far easier when clients still rely on multicast or broadcast name resolution and when SMB or related services allow weak authentication paths. If a network still permits unnecessary fallback lookups, an attacker only needs to be close enough to answer them first. If signing or equivalent protections are absent, relay is much easier to turn into access.
Teams should therefore treat the protocol mix as part of the control plane, not just the network design. Disabling LLMNR and NBT-NS where they are not needed removes the easiest poisoning opportunity, and constraining vulnerable service paths reduces the value of any captured authentication. Current best practice is to combine protocol reduction with monitoring, because one without the other leaves blind spots.
The detection story also benefits from broader threat context. The State of NHI & AI Agent Breach Report 2026 is relevant here because relay and credential theft are part of the same attacker pattern: harvest access, then move laterally using whatever trust the environment already grants.
Risk and Threat Considerations
Poisoning and relay attacks are dangerous because they weaponise a normal trust assumption, that a local name response and a subsequent authentication exchange are both legitimate. Once that assumption breaks, attackers can pivot from passive observation to credential interception and session abuse without needing to deploy malware on the victim host.
Failure mechanism: The attacker answers multicast or broadcast name-resolution queries faster than the legitimate responder, then relays the resulting authentication to a service that accepts it, often bypassing the need to know the password.
Impact: Successful relay can lead to unauthorized access, lateral movement, privilege escalation, and in some environments, compromise of administrative or service accounts that were never intended to be exposed on the local subnet.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1557 — Adversary-in-the-Middle | Poisoning and relay are classic adversary-in-the-middle access paths. |
| Recommendation — Map the observed sequence to adversary-in-the-middle tradecraft and hunt for relay-enabled authentication reuse. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Disabling risky name-resolution paths and limiting reachable services reduces relay exposure. |
| Recommendation — Restrict exposed services and remove unnecessary protocols that enable local-network relay abuse. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Detection depends on monitoring abnormal name-resolution and follow-on authentication behavior. |
| AC-4 — Information Flow Enforcement | Relay succeeds when local traffic can reach unintended services or trust boundaries. | |
| Recommendation — Correlate resolver activity with authentication events to identify suspicious relay chains. Enforce information-flow restrictions that block unauthorized workstation-to-service paths. | ||
Practitioner Guidance
What to verify: Confirm that the hosts generating the suspicious responses are authorised infrastructure systems, not peer workstations or attacker-controlled listeners. Validate that the downstream authentication target is expected for that client and subnet before you treat the event as benign.
Decision rule: If you see repeated fallback name resolution followed by authentication to an unusual host, treat it as a potential active relay chain and investigate the full path, not just the initial query. If the environment still permits the protocol, prioritise reducing exposure first and then tune detection around the remaining edge cases.
What good looks like: Clients resolve names through approved infrastructure, fallback protocols are disabled or rare, and any residual broadcasts are low-volume, explainable, and easy to correlate with known test activity or legacy services.
Practitioner takeaway: The highest-value signal is the sequence, not the packet, suspicious resolution response, followed by authentication, followed by movement to an unexpected target.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org