Summary
Noxious is a very easy difficulty sherlock challenge from Hack The Box. The challenge provides a single capture.pcap file for analysis.
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.
Task 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.
The challenge brief informed me that the malicious user was suspected to have performed an LLMNR poisoning attack, so I filtered for LLMNR traffic.
Answer
172.17.79.135
Task 2
What is the hostname of the rogue machine?
I made the assumption that I was going to find the hostname inside a packet that came from the malicious machine. I assumed that the malicious machine would send its hostname in a response to a request for such information.
When new machies join a network, they need to be given an IP address before they can attack contact other machines. IP addresses are given to hosts by a DHCP (Dynamic Host Configuration Protocol) server. Clients communicate their hostnames along with their MAC addresses when requesting an IP address from a DHCP server. This can be seen as option 12 in the options table on the DHCP Wikipedia article.
I filtered the packet capture down to just DHCP traffic using the following filter:
dhcp
I already knew that the malicious machine had the IP address 172.17.79.135 (at the time that the packet capture was taken), so I examined the packets that came from that IP. The first DHCP Discover packet was a red herring. It did indeed contain a hostname within it, however this was not the right answer.
The next packet from 172.17.79.135 was a DHCP Request packet, where the client asked the DHCP server for an IP address. There was also a hostname in this packet, and it certainly fit the profile of a hacker.
Answer
kali
Task 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?
Given that this was an LLMNR poisoning attack, the attacker was most likely trying to target users’ NTLM hashes. To confirm this, I applied the following filter to the captured traffic:
ntlmssp
This showed all of the packets that were sent for NTLM authentication attempts. From the filtered traffic, it was pretty obvious that there was only one user caught up in this.
NTLM hashes are hashes of user passwords that are sent over the network instead of the password itself. This is to prevent the leakage of user credentials to anyone that may be snooping on the network traffic. The problem is that these hashes are potentially crackable if the user has chosen a weak password, and a hacker is able to capture the hash as it is sent over the network (or if the user’s computer is tricked into sending the hash to the hacker).
Answer
john.deacon
Task 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?
The default time format used by Wireshark is Seconds Since First Captured Packet, which isn’t helpful when trying to determine a timestamp. Fortunately, this can be changed under:
View > Time Display Format > UTC Date and Time of Day
After making that change, I then applied the NTLM filter again, and checked the timestamp of the first NTLMSSP_AUTH packet.
Answer
2024-06-24 11:18:30
Task 5
What was the typo made by the victim when navigating to the file share that caused his credentials to be leaked?
A common way for this kind of poisoning attack to succeed is for a user to mistype the name of a network service that they need to authenticate to with their NTLM hash, the most common being an SMB share. In such a siutation, the attacker runs responder (as they did in this scenario), and advertise an SMB share that is named extremely similarly to a legitimate one. The hope is that an unfortunate user will accidentally mistype the share name, send a request to authenticate to the phony share, and in turn send their password hash to authenticate to it.
To resolve the name of the SMB share to the IP addresses of the server hosting it, a DNS query needs to be processed. I filtered for DNS traffic to see what I could find. Given that I had browsed the traffic for a while by this point, I had learned that the AD domain was named FORELA.LOCAL. I used this information in my filter to find only the DNS requests that were being used to locate domain resources:
dns contains "local"
Right at the top of the results was a telling query response:
The response No such name A DCC01.forela.local indicated that the user had been trying to connect to DC01.forela.local, but had instead added in an extra C, leading to them authenticating to the rogue SMB share being hosted by responder on the malicious machine.
Answer
DCC01
Task 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?
I again filtered the traffic to just the NTLM traffic with the following display filter:
ntlmssp
The server challenge is found in the packet that the server sends in a response to an authentication request. When a client wants to authenticate with NTLM, the server will send them a challenge that they can only successfully complete with their password hash. The client sends their repsonse to the challenge back to the server. The server then sends the challenge, and the client’s challenge response to the domain controller. The domain controller (which knows the user’s password hash) will then also solve the server’s challenge using the user’s password hash that it has stored. If the domain controller’s challenge response matches the response that the client sent to the server, then the client is authenticated.
The server’s challenge takes the form of a random number, and is found in the STATUS_MORE_PROCESSING_REQUIRED packet.
Answer
601019d191f054f1
Task 7
Now doing something similar find the NTProofStr value.
The NTProofStr is found in the response that the client sends back to the server after receiving the challenge, inside the NTLMSSP_AUTH packet.
Answer
c0cc803a6d9fb5a9082253a04dbd4cd4
Task 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.
An NTLMv2 hash is structured as follows:
USER::DOMAIN:SERVER_CHALLENGE:NTPROOFSTR:NTLMV2RESPONSE
Note: the first 32 characters have to be removed from NTLMV2RESPONSE
I had gathered all of the required information during the previous tasks, and so I was able to assemble the hash.
john.deacon::FORELA:601019d191f054f1:c0cc803a6d9fb5a9082253a04dbd4cd4:010100000000000080e4d59406c6da01cc3dcfc0de9b5f2600000000020008004e0042004600590001001e00570049004e002d00360036004100530035004c003100470052005700540004003400570049004e002d00360036004100530035004c00310047005200570054002e004e004200460059002e004c004f00430041004c00030014004e004200460059002e004c004f00430041004c00050014004e004200460059002e004c004f00430041004c000700080080e4d59406c6da0106000400020000000800300030000000000000000000000000200000eb2ecbc5200a40b89ad5831abf821f4f20a2c7f352283a35600377e1f294f1c90a001000000000000000000000000000000000000900140063006900660073002f00440043004300300031000000000000000000
I saved the hash to a file, and then cracked it with hashcat and the rockyou.txt wordlist.
hashcat --force -m 5600 hash.txt /usr/share/wordlists/rockyou.txt
After letting hashcat run for a bit, it cracked the user’s password.
Answer
NotMyPassword0K?
Task 9
Just to get more context surrounding the incident, what is the actual file share that the victim was trying to navigate to?
To find the SMB file share that the user was trying to connect to, I filtered the packet capture using the following filter:
smb2
Scrolling through the packets reveals the file share.
Answer
\\DC01\DC-Confidential
Conclusion
By the end of the challenge, the full scale of the attack was clear. A malicious user had connected a machine running Kali Linux to the network. They then proceeded to start up responder which ran a rogue SMB file share named DCC01, a name that was extremely close to the legitimate share DC01. When the user john.deacon accidentally typed the share name incorrectly, his password hash was sent to the hacker when his computer attempted to authenticate to this phony SMB share. From there, the hacker was more than likely able to crack the password hash since the password itself was weak, and found inside the rockyou.txt wordlist. With the password in hand, the hacker could connect to any network resources as john.deacon, including the file share DC-Confidential. With a name like that, one can only imagine the kind of information that was stolen. The first step towards recovery for Forela is going to be changing John’s password…
Some of the lessons we can take away from this are:
- Choose a strong and complex password to prevent hash cracking
- Monitor network traffic for suspicious activity
- Probably don’t use
NTLMfor authentication anymore
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.