Responder: LLMNR/NBT-NS Poisoning Explained

Responder is a tool that captures Windows credentials by exploiting a helpful little behavior built into every default Windows network, and it is one of the first things a tester runs once they have a network cable or a Wi-Fi connection. It requires no credentials to start, no software on any target, and no exploit in the classic sense. It simply listens for Windows machines asking for help and answers “yes, that’s me.” That is why an internal test so often begins here, and why the fix is one of the highest-value hardening steps a Windows environment can take.

The behavior it abuses

When a Windows machine tries to reach a name that DNS cannot resolve (a mistyped share, a decommissioned server, an old printer), it does not give up. It falls back to two legacy broadcast protocols, LLMNR and NBT-NS, effectively shouting to the whole local network: “does anyone know where SERVER-X is?”

These protocols have no authentication. Any machine on the network can answer. Responder is the machine that always answers: “yes, that’s me, send your credentials.” The victim, believing it has found the resource it wanted, dutifully attempts to authenticate, handing over the user’s username and a hashed form of their password.

The whole attack rests on trusting an unauthenticated broadcast, which is exactly the assumption these 1990s protocols were built on and which no longer holds.

The project’s README describes Responder as an LLMNR, NBT-NS and mDNS poisoner with built-in rogue authentication servers, so multicast DNS is the third fallback to check, not only the two legacy Windows protocols. It is still actively maintained: as of September 2026 the version string reads 3.2.2.0, with commits as recent as June 2026. It also has a listen-only analysis mode that shows which of these requests your network sends without answering any of them, a useful way to size the problem before anything is captured.

What actually happens in the attack

1. Responder listens quietly on the local network for LLMNR and NBT-NS broadcasts. This is passive: no scanning, no noise, nothing that looks like an attack.
2. A Windows machine fails a name lookup (which happens constantly on real networks from typos, stale shortcuts, and old references) and broadcasts for help.
3. Responder answers, claiming to be the requested resource.
4. The victim sends an authentication attempt, and Responder captures the username and the Net-NTLMv2 hash of the password.
5. That hash is then either cracked offline to recover the plaintext password, or relayed to another system (using a tool like Impacket’s ntlmrelayx) to authenticate as the victim without cracking anything.

From plugging in to holding valid credentials can take minutes, entirely passively.

What a finding means for you

If Responder appears in a report and captured anything, it tells you two things directly:

• LLMNR and NBT-NS are enabled on your network: the legacy name-resolution fallback is active and being abused. This is the root cause, and it is a configuration, not a bug.
• Password quality and NTLM exposure are a risk: if captured hashes cracked quickly, passwords are weak; if they were relayed successfully, SMB signing was not enforced.

Captured domain credentials are rarely the end of the story. They are the foothold. A tester feeds them into tools like NetExec to find everywhere that account works, turning a passive capture into network-wide movement. That chain (plug in, poison, capture, crack or relay, move) is one of the most reliable paths from “physical or Wi-Fi access” to “domain compromise,” which is why it is tested so consistently. It is also why physical and wireless tests check what a network connection in your office leads to.

How defenders shut it down

This is one of the satisfying findings, because the primary fix is decisive and free:

1. Disable LLMNR and NBT-NS. With modern DNS, these legacy fallbacks are rarely needed. Turning them off (via Group Policy for LLMNR and network configuration for NBT-NS) removes the behavior Responder depends on. The attack simply stops working. This is the single highest-value action. Review multicast DNS (mDNS) at the same time, since it is the third fallback the tool answers.
2. Enforce SMB signing. This defeats the relay variant even where a hash is captured.
3. Strong passwords, so any hash that is captured resists offline cracking.
4. Network segmentation, limiting how far a poisoning attack on one segment can reach.
5. Monitor for it: unusual name-resolution responses and authentication patterns can be detected, though prevention is far better here.

The reason testers check for this on nearly every internal engagement is that the fix is so effective and so often left undone. Disabling two legacy protocols closes one of the most common paths to compromise in Windows networks. Our Active Directory hardening checklist puts these fixes alongside the other relay, poisoning and coercion checks, each with a way to confirm it holds.

How we use it in an engagement

Responder is an early-stage credential-access tool in internal network penetration testing and red team assessments. It frequently provides the initial credentials in an assumed-breach or on-site test, from which lateral movement begins. It answers the question, “if someone got a connection to your internal network, how quickly could they get a valid credential?”, and the honest answer, on an unhardened network, is very. When the domain itself is the question, an Active Directory security assessment runs this check alongside the other paths to Domain Admin.

On our tests it runs only on the network segments in scope and during the agreed testing windows. Any captured credential is used only to show how far it reaches within the rules of engagement, and the report pairs the finding with the Group Policy and network settings that close it, which the free retest then confirms. Internal tests start at $6,000; see the internal penetration testing price page.

The short version

Responder captures Windows credentials by answering the unauthenticated LLMNR and NBT-NS broadcasts that default Windows networks send whenever a name lookup fails. It needs no credentials and no exploit, works passively, and often yields a domain credential within minutes, the foothold for everything after. The defense is decisive: disable LLMNR and NBT-NS, enforce SMB signing, and use strong passwords. It is one of the most common findings on internal tests precisely because the fix is easy and so often missed.

Curious how quickly someone with a connection to your network could capture a working credential? Finding that out is a standard part of every internal penetration test we run. Scope one here.