Responder is a tool that captures Windows credentials by exploiting a helpful little behaviour 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 behaviour 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.
What actually happens in the attack
- 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.
- A Windows machine fails a name lookup , which happens constantly on real networks from typos, stale shortcuts, and old references , and broadcasts for help.
- Responder answers, claiming to be the requested resource.
- The victim sends an authentication attempt, and Responder captures the username and the Net-NTLMv2 hash of the password.
- 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.
How defenders shut it down
This is one of the satisfying findings, because the primary fix is decisive and free:
- 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 behaviour Responder depends on. The attack simply stops working. This is the single highest-value action.
- Enforce SMB signing. This defeats the relay variant even where a hash is captured.
- Strong passwords, so any hash that is captured resists offline cracking.
- Network segmentation, limiting how far a poisoning attack on one segment can reach.
- 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.
Where it fits 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.
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 defence 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.
Written by
Invadel Team
Senior penetration testers writing from real engagements — the same team that scopes, tests, and reports for our clients. About Invadel →