Introduction:
Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Noxious blue team challenge from HackTheBox, you’re in the right place.
This is the third challenge in the Detecting Active Directory Attacks track and it wastes no time dropping us into a classic blue team scenario. If you’re a completionist, or just want to follow along in order, check out my walkthrough of Campfire-2.
For this challenge, we’re stepping into the role of a network forensic investigator responding to an IDS alert. A rogue device has appeared inside the Active Directory network, and the IDS has detected unusual LLMNR activity. Our task is to analyze a packet capture, identify the attacker’s system, determine whether NTLM authentication material was captured, and ultimately assess whether the exposed credentials could be cracked offline.
For the investigation, we’ll spend most of our time in Wireshark, dissecting network traffic, following TCP streams, examining SMB authentication exchanges, and extracting the information needed to reconstruct a captured NetNTLMv2 challenge-response. We’ll also pivot into Hashcat to validate whether the captured authentication material could be cracked using a common wordlist.
I’ll walk through each step of the investigation, explain the reasoning behind the analysis, and show how the individual pieces fit together to tell the full story. By the end, you’ll have a better understanding of how LLMNR poisoning attacks work, how to investigate them from a packet capture, and what evidence to look for when validating potential credential exposure.
Sounds like fun, right? Let’s go!
And hey, if you find this walkthrough helpful, whether it helps you level up your network forensics skills, gets you over a stumbling block, or just serves as a useful reference, consider following me for more weekly deep dives.
Thanks for reading and going on this investigation with me!
This write-up is for educational purposes only. All intellectual property related to the challenge belongs to the respective owners HackTheBox.
Challenge Scenario:
The IDS device alerted us to a possible rogue device in the internal Active Directory network. The Intrusion Detection System also indicated signs of LLMNR traffic, which is unusual. It is suspected that an LLMNR poisoning attack occurred. The LLMNR traffic was directed towards Forela-WKstn002, which has the IP address 172.17.79.136. A limited packet capture from the surrounding time is provided to you, our Network Forensics expert. Since this occurred in the Active Directory VLAN, it is suggested that we perform network threat hunting with the Active Directory attack vector in mind, specifically focusing on LLMNR poisoning.
Setup the Analysis Environment & Extract the Challenge File:
Safety first! It’s always important when working with lab/challenge files from [HackTheBox] (or any educational lab/challenge/range), to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”
To keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but if you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.
https://github.com/mandiant/flare-vm
Once you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!
Question 1: Its suspected by the security team that there was a rogue device in Forela’s internal network running responder tool to perform an LLMNR Poisoning attack. Please find the malicious IP Address of the machine.
Let’s kick off this investigation by extracting the challenge file noxious.zip, leaving us with our primary analysis artifact, capture.pcap. This network packet capture will let us dissect Forela’s network traffic around the time of the IDS alert and identify the host performing the suspected LLMNR poisoning attack.
Overview of the challenge artifacts
Open capture.pcap in Wireshark. Our first task is to identify the rogue device’s IP address and determine the source of the LLMNR traffic.
For some helpful background context, Link-Local Multicast Name Resolution (LLMNR) is a legacy name resolution protocol that allows hosts on the same local network to discover each other when DNS resolution fails. The problem is that LLMNR responses can be spoofed. If a user attempts to reach a device that doesn’t exist in DNS, LLMNR may be used as a fallback. An attacker can abuse this behavior by intercepting the request and responding as though they’re the resource being requested.
This type of attack is often performed using Responder, an open-source tool “used for LLMNR, NBT-NS and MDNS poisoning” and capturing authentication requests.
With the packet capture open in Wireshark, we’ll need to apply a display filter to identify LLMNR traffic. The first step is determining which port the protocol uses.
According to the TCP UDP Ports Directory, LLMNR uses port 5355 over both TCP and UDP. This gives us the filter we need:
|
|
Wireshark: Filtering for LLMNR traffic
After applying the filter and focusing on the internal IPv4 traffic, we can identify LLMNR communication between 172.17.79.135 and 172.17.79.136. The destination IP, 172.17.79.136, matches the victim workstation identified in the scenario (Forela-WKstn002).
Given the nature of the traffic and the challenge context, 172.17.79.135 appears to be the source of the suspicious LLMNR response and is likely the rogue device responsible for the poisoning attack.
Question 2: What is the hostname of the rogue machine?
Now that we’ve identified the IP address of the rogue device, we also want to determine its hostname.
To get a quick view of the hostnames resolved within the PCAP, let’s use Wireshark’s Resolved Addresses feature by navigating to Statistics > Resolved Addresses > Hosts and looking for 172.17.79.135.
Wireshark: Using the resolved addresses view
This seemed like a solid approach, but it didn’t give us the answer we were looking for. Time to pivot.
Let’s make the assumption that the attacker’s device received its IP address via DHCP when it joined the network. If that’s the case, we may be able to find the hostname embedded within the DHCP traffic.
Apply the following display filter:
|
|
Wireshark: Identifying the hostname in the DHCP traffic
Focusing on packet 12714, we can see a DHCP request originating from 172.17.79.135. Expanding the DHCP packet details reveals the hostname field, which contains the value kali.
Question 3: Now we need to confirm whether the attacker captured the user’s hash and it is crackable!! What is the username whose hash was captured?
Now that we’ve identified LLMNR traffic between the rogue device and the victim, we need to determine whether the attacker successfully captured the victim’s NTLM authentication material.
Before diving into the packet analysis, let’s add a bit more context. Earlier, I mentioned that LLMNR poisoning is commonly performed using Responder. Looking at the MITRE ATT&CK framework, this activity aligns with Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001).
The MITRE ATT&CK entry notes:
“By responding to LLMNR/NBT-NS/mDNS network traffic, adversaries may spoof an authoritative source for name resolution to force communication with an adversary controlled system. This activity may be used to collect or relay authentication materials.”
With that in mind, our next step is to inspect the authentication traffic generated after the poisoned name resolution. I’m making a bit of an assumption here, but in a typical LLMNR poisoning attack, the victim attempts to authenticate to the attacker’s system, often over SMB, resulting in an NTLM challenge-response exchange that can be captured by tools such as Responder.
To quickly identify NTLM authentication traffic associated with SMB, apply the following Wireshark display filter:
|
|
Wireshark: Identifying NTLMSSP authentication traffic
This immediately highlights several NTLMSSP authentication events. By examining the NTLMSSP_AUTH messages, we can identify the account attempting to authenticate to the rogue host: john.deacon.
Question 4: In NTLM traffic we can see that the victim credentials were relayed multiple times to the attacker’s machine. When were the hashes captured the First time?
From the same view, we can see that several NTLMSSP_AUTH authentication events occurred, and we’re looking for the timestamp associated with the first one.
Wireshark: Identifying multiple NTLMSSP_AUTH events
One small but important step before recording the timestamp is to verify the time display format being used by Wireshark. Many CTFs want timestamps in UTC rather than the local system time, so it’s worth checking before submitting an answer.
To change the display format, navigate to:
|
|
Wireshark: Identifying the first event with the UTC timestamp
Now we have an accurate time stamp we can use to submit.
Once the timestamps are displayed in UTC, we can identify the earliest NTLMSSP_AUTH event, grab the timestamp, and submit.
Question 5: What was the typo made by the victim when navigating to the file share that caused his credentials to be leaked?
Now that we’ve successfully identified the first authentication event, let’s take the investigation a step further and follow the TCP stream associated with packet 9292 to review the surrounding network activity.
As we work through the related packets, we eventually stumble on packet 9279. Examining the packet details reveals a valuable clue. Under the SMB negotiation information, we can see the NetName value DCC01.
Wireshark: Identifying the NetName referenced during the SMB connection
This might ring a bell. Back in Question 1, while examining the LLMNR traffic, we observed several name resolution requests for DCC01, including a response from the attacker’s system responding “Hey, that’s me”.
This strongly suggests that the victim intended to access DC01 but accidentally typed DCC01 instead. Because DCC01 could not be resolved through DNS, Windows fell back to using LLMNR for name resolution.
Putting the pieces together, when the attacker responded to the LLMNR request, the victim’s system attempted to connect to the rogue host instead of the legitimate DC01 server. That connection triggered an NTLM authentication attempt, exposing the victim’s NTLM authentication material to the attacker.
Question 6: To get the actual credentials of the victim user we need to stitch together multiple values from the ntlm negotiation packets. What is the NTLM server challenge value?
Next up, let’s stick with our current TCP stream and shift our focus to identifying the NTLM Server Challenge value used during the authentication exchange.
We can cheese this one a little by taking advantage of Wireshark’s search functionality. Click the magnifying glass icon and search the packet details pane for the string:
|
|
Wireshark: Locating the NTLM Server Challenge value
This quickly leads us to the NTLM challenge-response exchange, where we can locate the server’s challenge value. This value is generated by the server and sent to the client during the challenge-response authentication process.
Question 7: Now doing something similar find the NTProofStr value.
The next question asks us to identify the NTProofStr value. Fortunately, the process is very similar to the previous question.
We can once again leverage Wireshark’s search functionality to quickly locate the value within the packet details. Select the search icon, choose to search within the packet details, and search for: NTProofStr
According to Microsoft Learn, the NTProofStr is an HMAC value that forms part of the NTChallengeResponse structure used during NTLMv2 authentication.
Wireshark: Locating the NTProofStr value
This is another important component of the captured NTLM authentication material and, together with the other values we’ve collected, can be used to reconstruct the NTLMv2 challenge-response data for offline password cracking.
Question 8: To test the password complexity, try recovering the password from the information found from packet capture. This is a crucial step as this way we can find whether the attacker was able to crack this and how quickly.
Speaking of offline password cracking, let’s put all of this together.
We know the compromised user, domain, Server Challenge value, and NTProofStr value. The last thing we need is the NTLMv2 Response, which we can also find in packet 9292, right above where we found the NTProofStr.
Wireshark: Finding the NTLMv2 Response Hash
So, what do we do with all of this? We’ll assemble the NTLM authentication material we’ve collected and test whether it can be cracked offline using Hashcat.
In doing some research, Hashcat lists example NetNTLMv2 hashes in the following format:
|
|
We have each of these values already. One trick is that the captured NTLMv2 Response includes the NTProofStr at the beginning, so we need to remove the first 16 bytes, or 32 hexadecimal characters, from the captured response before adding it to our final hash format.
Let’s put everything together manually and save the assembled value into a file called hash.txt.
Assembling the collected authentication material
Now, we need to do some cracking. Unfortunately, I’m working from Flare VM, which is more of an analysis environment. For this step, I personally need to save the assembled output into a file and bring it into my Kali Linux environment, which has the right tools for the job. If you’re already using something like Kali Linux, you should be in good shape with Hashcat available.
Once inside your red team environment, we can run the following command:
|
|
Here, -a0 tells Hashcat to run a dictionary attack, while -m5600 tells it that we’re providing a NetNTLMv2 hash. For the wordlist, we’ll use the classic rockyou.txt, which is appropriate for a challenges like this. Don’t expect it to be this easy in the real world.
Now let it rip!
Hashcat: Cracking the NetNTLMv2 challenge-response material
Once the cracking process completes, we can see that we’ve recovered the victim user’s password. This tells us that the exposed NTLM authentication material was susceptible to offline password cracking using a common wordlist.
Question 9: Just to get more context surrounding the incident, what is the actual file share that the victim was trying to navigate to?
For our final task, let’s add some additional context by identifying the legitimate file share the victim was attempting to access before mistyping DCC01.
We already know the victim’s IP address from Question 1, so let’s focus on their SMB activity and see if we can identify any legitimate network shares they were connecting to around the time of the incident.
Apply the following display filter:
|
|
From the filtered results, look for a Tree Connect Request. This is part of the SMB connection process and identifies the share a client is attempting to access.
Wireshark: Identifying the legitimate share accessed by the user
Examining the Tree Connect Request packets reveals the network share the victim was legitimately attempting to access before the LLMNR poisoning attack occurred.
This provides some useful context around the incident because it helps us understand the user’s intended destination and how a simple typo resulted in their authentication material being exposed to the rogue host.
And with that, we’ve come to the end of our investigation. Great job now let’s wrap this thing up!
Conclusion:
That’s a wrap on Noxious! How fun was that? A big thank you to HackTheBox for another awesome Sherlock.
In this investigation, we started with an IDS alert reporting suspicious LLMNR traffic inside an Active Directory environment and followed the evidence all the way through to credential exposure. Along the way, we identified a rogue device running Responder, confirmed an LLMNR poisoning attack, traced SMB authentication activity, extracted captured NetNTLMv2 authentication material, and successfully recovered the victim’s password through offline cracking. To top it all off, we were able to reconstruct the original chain of events and determine that the entire attack stemmed from a simple hostname typo made by the user - whoops! Not bad for starting with nothing more than a packet capture!
I chose this challenge because I’ve been seeing more and more examples of legacy name resolution protocols like LLMNR showing up in attack paths, security assessments, and threat reports. I wanted to spend some hands-on time investigating the protocol, understanding exactly how the attack goes down, and learning what artifacts defenders can use to identify it. There’s a big difference between reading about a technique and going hands-on through packet data.
The most interesting part for me was learning more about the NetNTLMv2 cracking process. I understood the general concept of captured authentication material being cracked offline, but I hadn’t spent much time digging into how the individual pieces fit together. Seeing the Server Challenge, NTProofStr, and NTLMv2 Response extracted from the packet capture, then manually reconstructing the format required by Hashcat, helped connect those dots. It was a sobering reminder that attackers don’t need to steal plaintext passwords to create risk. In many situations, captured authentication material alone may be enough if the underlying password isn’t strong enough to withstand offline cracking.
So, my takeaway is that legacy protocols and weak passwords can create a dangerous combination. While disabling unnecessary protocols like LLMNR can help reduce the attack surface, strong passwords remain an important layer of defense because they make offline cracking much more difficult and time consuming. Challenges like this are a great reminder about why defense in depth is so important.
Thanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we’re in this together!
Until next week’s challenge, stay curious and be safe out there!
Tools & References:
Challenge Link: https://app.hackthebox.com/sherlocks/Noxious?tab=play_sherlock
Flare-VM: https://github.com/mandiant/flare-vm
MITRE ATT&CK - Responder (S0174): https://attack.mitre.org/software/S0174/
TCP UDP Ports - LLMNR: https://tcp-udp-ports.com/port/5355/
MITRE ATT&CK - Adversary-in-the-Middle: Name Resolution Poisoning and SMB Relay (T1557):https://attack.mitre.org/techniques/T1557/001/
Microsoft Learn - NTLM2 V2 Response:https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/d43e2224-6fc3-449d-9f37-b90b55a29c80
Hashcat - Example Hashes:https://hashcat.net/wiki/doku.php?id=example_hashes