Introduction
In this lab, we delve into a simulated network security incident involving poisoned credentials, where attackers exploit vulnerabilities in Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS)protocols. These protocols, while designed to aid name resolution in local networks, are inherently vulnerable due to their reliance on broadcast queries and lack of robust authentication. Cybercriminals often exploit these weaknesses to perform man-in-the-middle attacks, redirect traffic, and harvest sensitive information such as user credentials.
The scenario begins with a surge in suspicious network activity detected by the organization’s security team. Initial analysis indicates the use of poisoning attacks targeting LLMNR and NBT-NS to intercept and manipulate legitimate network traffic. Using the powerful network forensic tool Wireshark, we analyze captured network traffic to identify the rogue machine, uncover the scope of the attack, and track the compromised accounts and systems.
Throughout this walkthrough, we methodically investigate key aspects of the attack, including identifying poisoned queries, tracing the attacker’s IP address, and analyzing SMB authentication attempts. The goal is to provide a comprehensive understanding of how such attacks unfold, equip you with the skills to detect similar incidents in real-world scenarios, and emphasize the importance of securing vulnerable network protocols to protect critical resources and user credentials.
Link-Local Multicast Name Resolution (LLMNR): A protocol that allows computers on the same local network to resolve hostnames to IP addresses without needing a DNS server.
NetBIOS Name Service (NBT-NS): An older Microsoft protocol that does the same thing as LLMNR — resolves hostnames on a local network — but it predates DNS and LLMNR. It’s essentially the legacy version.
Analysis
Q1. In the context of the incident described in the scenario, the attacker initiated their actions by taking advantage of benign network traffic from legitimate machines. Can you identify the specific mistyped query made by the machine with the IP address 192.168.232.162?
The machine at 192.168.232.162 broadcast a NetBIOS Name Service (NBNS) request attempting to resolve FILESHAARE<20> — a mistyped hostname. The broadcast was sent to 192.168.235.255, meaning it was sent to every device on the local network. Because no legitimate server existed with that name, the misspelling created an opportunity for an attacker to spoof a response and intercept the connection.
Q2 We are investigating a network security incident. To conduct a thorough investigation, We need to determine the IP address of the rogue machine. What is the IP address of the machine acting as the rogue entity?
Packet 51 reveals the rogue machine. When 192.168.232.162 broadcast its mistyped query for FILESHAARE<20>, the machine at 192.168.232.215 responded — claiming to know the host’s location.
This is the hallmark of an NBT-NS poisoning attack. Because the NBNS protocol has no authentication mechanism, any machine on the network can respond to a broadcast query and claim to be the requested host. By sending a crafted reply to the victim’s failed lookup, 192.168.232.215 positioned itself as a man-in-the-middle — ready to intercept traffic or capture NTLMv2 credential hashes from the victim’s authentication attempt.
Q3 As part of our investigation, identifying all affected machines is essential. What is the IP address of the second machine that received poisoned responses from the rogue machine?
Filtering the capture reveals a second victim — the machine at 192.168.232.176. Like the first, it received a poisoned NBNS response from 192.168.232.215, which falsely claimed to resolve queries for non-existent hostnames.
This is the rogue machine’s core technique — by answering broadcast queries that no legitimate host responds to, it silently inserts itself between victims and their intended destinations, setting the stage for credential capture.
Q4 We suspect that user accounts may have been compromised. To assess this, we must determine the username associated with the compromised account. What is the username of the account that the attacker compromised?
The rogue machine’s poisoning attack ultimately targets SMB authentication. Once victims are redirected to 192.168.232.215, their machines automatically attempt to authenticate via SMB — handing over credentials without the user’s knowledge.
Packet analysis confirms this. An SMB2 session setup response from the rogue machine carries a STATUS_MORE_PROCESSING_REQUIRED status, signalling an active NTLM handshake in progress. Inside the packet, NTLMSSP data exposes the intercepted account details:
| Field | Value |
|---|---|
| Username | janesmith |
| Domain | cybercactus.local |
| Host | WORKSTATION |
This is the payoff of the poisoning chain — the rogue machine never needed to brute force anything. By simply answering broadcast queries, it tricked the victim’s machine into voluntarily authenticating against it, handing over credentials in the process.
Q5 As part of our investigation, we aim to understand the extent of the attacker’s activities. What is the hostname of the machine that the attacker accessed via SMB?
The NTLMSSP challenge embedded in the SMB2 session setup response reveals more than just an authentication attempt — it exposes the target system’s identity. The Target Info field within the challenge message lists the DNS computer name as AccountingPC.cybercactus.local, confirming the hostname and domain of the machine being accessed.
This ties directly to the poisoning chain. The rogue machine at 192.168.232.215 didn’t just intercept credentials — it specifically facilitated unauthorized SMB access to AccountingPC, a named machine within the cybercactus.local domain.
