Inveigh is a spoofing tool that abuses LLMNR and NBT-NS name resolution to trick hosts into sending authentication attempts to an attacker. It is used to capture hashes or relay credentials on local networks. Defenders should disable those protocols where possible, harden name resolution, and monitor for unexpected responder activity.
How Inveigh Works
Inveigh is a local-network spoofing tool that abuses multicast and broadcast name-resolution behaviour. By answering queries for LLMNR and NBT-NS, it positions itself as the responder a host trusts when DNS does not resolve a name.
This matters because name-resolution poisoning is not just about getting traffic to the attacker, it is about inducing authentication attempts to flow to an untrusted endpoint. Once that happens, the attacker may capture challenge-response material or, in some environments, relay the resulting authentication to another service.
Why LLMNR and NBT-NS Are Abused
LLMNR and NBT-NS exist to help devices on a local network discover names when DNS is unavailable or incomplete. That convenience becomes a weakness when hosts accept answers from whichever system responds first, especially on flat networks with weak segmentation.
Tools like Inveigh exploit that trust assumption, making them especially effective in environments where legacy name resolution is still enabled and where clients will fall back silently. The problem is not the protocol alone, but the combination of fallback behaviour, broad broadcast visibility, and insufficient hardening of workstation name resolution.
For a practical overview of adjacent attack paths and defender context, NHIMG’s Lateral Movement Guide covers name-resolution poisoning, NTLM relay, and the downstream use of stolen credentials.
What Inveigh Enables After Capture
The immediate value of a spoofing tool is often credential interception, but the downstream value can be broader. Hash capture may support offline cracking, while relay scenarios can provide access to services that still accept the negotiated authentication without stronger protections.
That is why responders should treat responder activity as an access-control event, not merely a network nuisance. Even when the captured material is not directly reusable, it can expose account names, domain relationships, workstation behaviour, and authentication patterns that help an attacker choose the next move.
The underlying protocol exposure is discussed in NHIMG’s Network Ports and Protocols Security Guide, which places LLMNR and other risky fallback services in the wider context of insecure network defaults.
Defensive Controls and Detection Signals
Defence starts with reducing the conditions that let spoofing succeed. Disabling LLMNR and NBT-NS where possible, preferring DNS with consistent configuration, and hardening clients so they do not fall back unnecessarily all reduce exposure. Segmentation also matters, because these attacks depend on being able to see and answer local-resolution traffic.
Detection should focus on unexpected responder behaviour, unusual multicast responses, and authentication attempts that originate immediately after name-resolution failures. A single workstation advertising itself as a resolver can be enough to create broad credential exposure, so monitoring should emphasise both the network symptom and the identity side effect.
When the response path involves relay or downstream use of captured credentials, practitioners can use the Lateral Movement Guide to connect the poisoning event to later access abuse and containment priorities.
Risk and Threat Considerations
These tools are dangerous because they convert routine name lookups into an authentication trap. If clients still trust broadcast responders, a low-friction local attacker can turn ordinary workstation activity into credential capture, relay attempts, or reconnaissance of internal accounts and services.
Failure mechanism: Legacy name resolution is accepted before stronger name-resolution paths, so a rogue responder wins the query and elicits authentication material that the attacker can capture or relay.
Impact: The result can be credential compromise, lateral movement, or trust abuse across internal services, especially where NTLM or similar fallback authentication remains in use.
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 NIST SP 800-53 Rev 5, 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 | This tool implements LLMNR/NBT-NS poisoning to intercept authentication traffic. |
| Recommendation — Map responder activity to T1557.001 and hunt for poisoned name-resolution responses and relay attempts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The tool captures reusable authentication material that should be governed and rotated. |
| Recommendation — Treat captured hashes and tokens as authenticators to revoke, rotate, and monitor under IA-5. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The attack succeeds by abusing access paths and fallback trust on local networks. |
| Recommendation — Remove unnecessary local name-resolution paths and restrict who can participate in internal authentication flows. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The term concerns authentication abuse and access-control failure caused by poisoned resolution. |
| Recommendation — Apply PR.AA-05 by hardening authentication pathways and limiting fallback trust to unapproved responders. | ||
Practitioner Guidance
Why practitioners should care: Inveigh is a good example of how a small protocol weakness becomes an identity and access problem. The main judgement is not whether the tool is noisy, but whether your environment still allows a poisoned name response to trigger useful authentication traffic.
What to watch for: Look for repeated resolver-like responses from non-infrastructure hosts, authentication bursts after failed name lookups, and endpoints that unexpectedly participate in local name-resolution traffic. Those signals usually point to an exposure that is structural, not incidental.
Practitioner takeaway: If you cannot yet remove the protocols everywhere, reduce the blast radius with segmentation, client hardening, and monitoring that treats resolver impersonation as an active compromise path.
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 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org