CyberDefenders — PoisonedCredentials Lab Writeup

Lab Scenario

Your organization's security team has detected a surge in suspicious network activity. There are concerns that LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) poisoning attacks may be occurring within your network. These attacks exploit these protocols to intercept network traffic and potentially compromise user credentials. Your task is to investigate the captured network traffic.

Lab Overview

LLMNR and NBT-NS are fallback name-resolution protocols. A Windows host only reaches for them when DNS fails to resolve a name. So the first thing worth checking is the Protocol Hierarchy: if these two are unusually prominent, name-resolution fallback is being heavily exercised, which is exactly what a poisoning attack produces.

Digging into the traffic, victim hosts were multicasting and broadcasting requests for services, a file share and a printer and a single host kept answering, claiming to be whatever was asked for.

The detail that made the whole case clear was the requested names were misspelled. And yet one host still answered, confidently claiming to own names that don't exist. A legitimate machine only answers for its own name, so a host that answers for several different (and impossible, misspelled) names is lying, and that lie is the attack.

From there, the attack pays off exactly as the lab's name suggests: once a victim connects to the rogue host believing it's the real file share, the victim's machine authenticates automatically, handing its credentials straight to the attacker over SMB.

Let's work through how the scenario was executed.

Lab Analysis

Q1 — The mistyped query from a specific machine

The attacker took advantage of benign traffic from legitimate machines. Can you identify the specific mistyped query made by the machine at 192.168.232.162?

Start with NBT-NS and filter for that host's queries (requests, not responses). The name it's asking to resolve, the typo, is right there in the packet info.

ip.addr == 192.168.232.162 and nbns.flags.response == 0

ip.addr == 192.168.232.162 and nbns.flags.response == 0

Q2 — The rogue machine

To conduct a thorough investigation we need the rogue machine. What is the IP address of the machine acting as the rogue entity?

Flip the previous filter to look at responses to that same query. The logic is: no host on a healthy network should answer a request for a name that doesn't exist. Whoever confidently answers the misspelled query is the rogue entity.

ip.addr == 192.168.232.162 and nbns.flags.response == 1

ip.addr == 192.168.232.162 and nbns.flags.response == 1

Q3 — The second affected machine

Identifying all affected machines is essential. What is the IP address of the second machine that received poisoned responses from the rogue machine?

Now pivot off the rogue host and list everything it responds to across both LLMNR and NBT-NS. The destinations of those poisoned responses are the victims. Look past the first one for a second victim.

(ip.addr == <rogue-ip> and llmnr and dns.flags.response == 1) or nbns.flags.response == 1

(ip.addr == <rogue-ip> and llmnr and dns.flags.response == 1) or nbns.flags.response == 1

Q4 — The compromised username

We suspect user accounts were compromised. What is the username of the account the attacker compromised?

Once a victim connects to the rogue SMB service, its machine authenticates automatically. From the packet list, find the NTLM session-setup message, in the packet detail it exposes the domain, username, hostname and session key in readable fields.

Q5 — The machine accessed via SMB

To understand the extent of the activity: what is the hostname of the machine the attacker accessed via SMB?

Staying in the rogue host's traffic, looking at the NTLM exchange's server-side challenge, its Target Info names the SMB session's identity, including the NetBIOS computer name.

Wrap-up

A textbook LLMNR/NBT-NS poisoning attack: a rogue host answering every query, even misspelled ones no machine could legitimately own, to lure victims into authenticating against it over SMB, leaking their credentials in the process.

The single most important indicator wasn't any one packet, it was a host answering for a name that doesn't exist. Once you internalize that a legitimate machine only ever answers for its own name, the poisoner gives itself away instantly.

Thanks for reading — try the lab yourself on CyberDefenders before peeking at the answers. Cyberdefenders: BlueTeam CTF Challenges | PoisonedCredentials