AD Security Series — Phase 1: LLMNR/NBT-NS Poisoning from Linux: How a Misconfigured Protocol Hands You Hashes

Phase 1 of the AD Security Series. Phase 0 was all about recon — finding the domain controller, mapping the network, and running Responder in analyze mode to see what the network was saying without answering it. If you missed it, go back. This part builds directly on that.

Disclaimer: This article is for educational purposes and authorized testing only. Everything shown here was done in a lab environment I have permission to attack. Don’t run Responder on a network you don’t own.
Someone typed a share name wrong. Windows asked the whole network for help. A liar answered first.

The Typo

It starts with a typo.

A user double-clicks a shortcut to the print server. Or types a path by hand. And misses a letter. \\print01 becomes \\printer01. One extra er.Nobody thinks about it. The user retypes the path, mumbles something, moves on.

But for a few seconds, that machine asked the whole network a question.And the answer it got was not from the server it wanted.

That’s the whole attack, honestly. Everything else is detail.

When DNS Fails, Windows Asks Everyone

Let me explain this the simple way, the way I understood it.

You want a printer, or a file, or any resource. Your machine asks the DNS server:
“who is that exact name? give me its IP address.” DNS answers when it knows the name. Clean, done.

But sometimes DNS fails. And Windows doesn’t just give up. It falls back to two old protocols:

The machine broadcasts to the whole local network: “hey, does anyone know where this thing is?” The order is DNS first, then LLMNR, then NBT-NS. You never see them fire when everything works. They only wake up when something breaks.

And here’s the kicker:

When these protocols are used, ANY host on the network can reply.

Not just the machine you meant. Any host. Including the one running Responder.

Anyone Can Answer

LLMNR has no authentication. No check, no handshake, no “prove you’re the print server.” First one to answer wins. It was designed for a time when the local network was a trusted place, like a house where you leave the door unlocked because everyone inside is family.

Responder is a tool that exists to be that first answer. It listens for LLMNR and
NBT-NS requests, and when it hears one, it answers:

“Yes, that’s me.”

The victim believes it. Opens a connection, sends its username and a password hash to authenticate. The resource doesn’t even need to exist. Responder imitates it anyway, and the client just hands over its credentials. Like asking a stranger on the street where the post office is and the stranger says “yeah hop in.” And you hop in.

Nobody breaks anything. The protocol gives the hash away on its own.

The Attack, Step by Step

The way it plays out:

  1. Someone types a share name wrong.
  2. DNS says: unknown host.
  3. The machine broadcasts: “anyone know where this is?”
  4. Our machine, Responder running, answers: “I’m the one you’re looking for.”
  5. The victim sends its username and a password hash.
  6. We crack that hash offline. Or relay it, if the conditions are right (later phase).

Six steps. No exploit. No bug. It’s default Windows behavior. A typo happened, and the protocol did what it was built to do. That’s what makes it nasty — nothing is broken.

Listen Before You Lie

One thing I do before poisoning anything: I run Responder in analyze mode first. It’s just a flag, -A:

sudo responder -I ens224 -A

In this mode it doesn’t answer anything. It just listens. Requests scroll by and you see what the network is actually saying. Fly on the wall. You’re in the room, nobody knows you’re there.

We already did this in Phase 0, actually. Before touching a single target, we ran Responder in analyze mode and watched what the network broadcast. So I knew LLMNR was in use before I poisoned anything.

It helps in a few ways. Maybe the protocols aren’t even used — some networks disabled this already, and then there’s no attack to run. You also learn the land: hostnames, the DC’s IP, which machines are chatty. All free, without sending one malicious packet.

Then, and only then:

sudo responder -I ens224

Responder listens and answers everything it hears. And then… you wait.

The Wait

Nobody shows you this part. Nothing happens for a while.

Responder is a trap. Traps need bait, and bait needs time. A typo has to happen. A script has to hit a dead DNS record. A user has to try mounting a share that was renamed. That doesn’t happen on your schedule. It happens on the network’s.

So you leave Responder running in a tmux window and go do other stuff. Nmap, whatever. The classic move: start it first thing in the morning, or right after lunch, let it run while you work. It needs traffic, and traffic needs humans.

And when a hash finally lands, Responder prints it and saves it to a log file (reponder/logs/Responder-Session.log). Every capture. And that log becomes its own little problem.

The Messy Log

Check the log after a while and it’s a mess. Not because it’s unreadable. Because it’s full. Same user captured five times. Another user, twice. Ten lines that are really three people.

I ran a small command to clean it. Just to keep the first hash of each user and drop the rest. Because cracking the same user’s hash five times is wasted time, and time is the one thing you never have enough of in an engagement.

That’s it. That’s the whole trick. The log was messy, I sorted it, one hash per user, ready for the next step.

The Hash

When a victim hits the trap, you get a hash that looks like a username, a domain, and two long strings of hex. That’s a NetNTLMv2 hash.

Here’s the thing that confused me for way too long: this is not the same as an NTLM hash.

The NT hash is what Windows stores for the password. NetNTLMv2 is a challenge-response. It’s proof that the client knows the password, but it’s produced fresh every time, with a random challenge. Like a signature that changes on every document. You can’t reuse it to log in. You can’t pass-the-hash with it.

So two options:

  1. Crack it offline. Try millions of passwords until one produces the same
    challenge-response.
  2. Relay it. Forward the authentication attempt to another host that accepts it. Needs SMB signing disabled on the target. That’s a whole later phase.
  3. For now: crack.

The Crack

hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

Mode 5600. That’s the one for NetNTLMv2. I know it like my own phone number at this point.

hashcat loads rockyou — fourteen million passwords. The mugshot book of the internet. And it chews through them, comparing each one against the math locked inside the hash.

Then the screen changes. Status: Cracked.

That’s the moment. Anonymous on the network, and now you hold a valid domain user’s password. A foothold.

Was it fancy? No. Did it break anything? Not a single thing. A typo, a broadcast, a liar, a messy log, a sorted file, and a weak password fell out the other side. That’s how a misconfigured protocol hands you hashes.

The Cheat Sheet

Up Next

Phase 1 done. We have a foothold.

Next phase: the same attack, but from the other side of the fence — LLMNR/NBT-NS poisoning from a Windows host. Inveigh instead of Responder, PowerShell instead of a Linux shell. Same goal, different tool.

Follow the series on Medium to stay in order. The AD Security Series — Phase 2:
LLMNR/NBT-NS Poisoning from Windows is coming.

— Moncef

AD Security Series — Phase 1: LLMNR/NBT-NS Poisoning from Linux: How a Misconfigured Protocol Hands… was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.