LLMNR/NBT-NS Poisoning Investigation Report
Our security monitoring flagged a spike in suspicious name resolution traffic on the network. Given the symptoms, there were concerns of an LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) poisoning attack. These types of attacks are dangerous because they let an attacker impersonate legitimate hosts, capture credentials, and move laterally. I was tasked with digging into the PCAP to confirm what happened, identify the rogue machine, and figure out the scope of the compromise.
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?
Looking at the traffic from 192.168.232.162, I saw multiple LLMNR/NBNS broadcasts. The key detail was a query for:
FILESHAAREThat extra “A” was the trigger. Since DNS couldn’t resolve it, the machine fell back to multicast resolution, which is where attackers jump in.
Answer Q1: The mistyped query was FILESHAARE.
This typo was the first domino to fall. Because LLMNR was still enabled, the machine shouted its request across the subnet, essentially asking “does anyone know who FILESHAARE is?” That’s the perfect opening for an attacker to impersonate the resource.
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?
When I filtered for responses to FILESHAARE, I spotted replies coming from:
192.168.232.215This host answered queries it shouldn’t, which identified it as the rogue system.
Answer Q2: The rogue machine’s IP address is 192.168.232.215.
Legitimate DNS servers don’t use LLMNR or NBNS to reply. Seeing a random workstation respond is a dead giveaway of poisoning activity. This told me exactly which machine was running Responder or a similar tool.
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?
The poisoned responses weren’t limited to just one machine. Tracing the rogue replies from 192.168.232.215, I found a second victim at:
192.168.232.176Answer Q3: The second affected machine was 192.168.232.176.
This confirmed the scope of the attack was wider than a single endpoint. Multiple systems were getting poisoned, which meant the attacker had more than one chance to capture credentials.
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?
Following the SMB authentication attempts to the rogue host, I saw an NTLMSSP_AUTH packet that contained the following:
User: cybercactus.local\janesmith
Answer Q4: The compromised username was janesmith.
This was the proof of compromise. The attacker didn’t just poison responses — they successfully tricked a workstation into sending real user credentials. Even though only the NTLM hash was exposed, it could still be cracked offline or used in a relay attack.
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?
Looking at SMB session setup traffic from 192.168.232.215, I saw the rogue system attempting to connect to:
ACCOUNTINGPC
Answer Q5: The hostname accessed via SMB was ACCOUNTINGPC.
Blurb:
This was the attacker testing their stolen credentials. By trying to authenticate against ACCOUNTINGPC, they were moving from simple credential capture into actual lateral movement.
Final Report
This investigation confirmed a full LLMNR/NBT-NS poisoning attack. It started when a victim machine (192.168.232.162) mistyped a share name (FILESHAARE). That broadcast request was intercepted by a rogue host (192.168.232.215), which responded with a poisoned answer. Not only did this impact the original victim, but another machine (192.168.232.176) was also poisoned. Shortly after, we saw the user account janesmith authenticate to the rogue system, exposing NTLM credentials. The attacker then attempted to use those credentials to access ACCOUNTINGPC over SMB, a clear sign of attempted lateral movement. To remediate, the organization should disable LLMNR and NBT-NS enterprise-wide, reset the compromised account janesmith, thoroughly review ACCOUNTINGPC for persistence or abnormal activity, and set up monitoring rules to detect unauthorized multicast name resolution traffic in the future. These steps would close the gap exploited here and strengthen defenses against credential-harvesting attacks.
