responder turns a windows name lookup into a stolen hash

the typo that hands over your credentials

you fat-finger a share name. windows tries dns, dns comes back empty, and instead of just giving up like a normal piece of software, windows panics and yells the question to the entire local network. "hey, does ANYONE know what \\fileservr is?" that broadcast is the whole vulnerability. responder just sits there and answers "yeah, that's me" before anyone else can. this post is about how that trick works so you can recognize it running on your own network and shut the door on it.

what's actually happening under the hood

windows has two legacy name resolution protocols that kick in when dns fails: llmnr (link local multicast name resolution) and nbt-ns (netbios name service). they exist for convenience, so old apps and misconfigured lookups still "just work" on a lan. the problem is neither one verifies who's answering. any device on the same broadcast segment can claim to be the resource being asked for.

responder is a tool that listens for these broadcast requests and answers all of them, pretending to be whatever the victim machine is looking for. once the victim believes it found the right host, it tries to authenticate to it, and that's where the damage happens. windows doesn't send your plaintext password during this handshake, but it does send an ntlmv2 hash as part of the authentication attempt. that hash lands right in responder's lap.

breaking down the command

responder -I eth0 -wv

-I eth0 tells responder which network interface to listen on, this needs to be the interface that's actually connected to the target lan segment.

-w turns on the wpad proxy server, which can trick browsers into routing traffic through responder too, extending the attack beyond just name lookups.

-v just makes it verbose so you see every request and response happening in real time.

the captured hash gets logged to a file. from there:

hashcat -m 5600 ntlmv2.txt rockyou.txt

-m 5600 tells hashcat the hash format is ntlmv2. ntlmv2.txt is the captured hash, and rockyou.txt is a wordlist hashcat will try against it. if the password is common or weak, it cracks in seconds. if it's long and random, this whole attack chain hits a wall, which is a good hint at part of your defense strategy too.

why this still works everywhere

llmnr and nbt-ns have been legacy since before a lot of currently employed sysadmins were born. microsoft hasn't ripped them out because some ancient internal tools and printers still depend on them. most orgs never touch the default settings because nobody wants to be the person who breaks the one weird legacy app nobody remembers the purpose of. so the broadcast-and-trust behavior just sits there, quietly waiting for a typo.

how to actually defend your network

the fix is boring, which is exactly why almost nobody does it: turn the protocols off.

for llmnr, push this via group policy: computer configuration > administrative templates > network > dns client > turn off multicast name resolution, set to enabled.

for nbt-ns, go into each network adapter's tcp/ip settings, advanced, wins tab, and set "disable netbios over tcp/ip." you can also script this fleet-wide with powershell instead of clicking through every machine by hand.

after disabling both, test with a deliberate typo on a share path and confirm nothing broadcasts. you should just get a clean "not found" instead of a chatty broadcast asking the whole subnet for help.

other layers worth stacking on top: enforce smb signing so even a captured hash can't be relayed into a live session, require long random passwords so cracked hashes are useless even if captured, and monitor your network for responder's tells, unexpected traffic on ports 5355 (llmnr) and 137 (nbt-ns) from a host that has no business answering name queries.

the takeaway

responder doesn't break into anything, it just answers a question your own network is asking too loudly. the fix isn't some expensive tool, it's flipping two legacy settings off and making sure your passwords are long enough that a cracked hash is a dead end. do that, and the next typo on your network stays a typo instead of a credential leak.