HTB Sherlock: Noxious

Noxious

HackTheBox Sherlock, FORELA environment again. Security team suspected a rogue device on the internal network running Responder to pull off an LLMNR poisoning attack, job is to trace it from a pcap and confirm whether the captured hash was crackable.

Task 1: Rogue device IP#

Q: 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.

Filtered the pcap for LLMNR traffic. One host answered every query on the network, similar to a Responder behavior.

Answer: 172.17.79.135

Task 2: Rogue device hostname#

Q: What is the hostname of the rogue machine?

Checked the DHCP exchange from that IP, the hostname was in the request.

Answer: kali

Task 3: Captured hash username#

Q: 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?

Followed the SMB traffic between the victim and the rogue host. The victim tried to authenticate, and the rogue machine caught the credentials.

Answer: john.deacon

Task 4: First hash capture time#

Q: 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?

Filtered for ntlmssp and took the timestamp of the first authentication attempt against the rogue host.

Answer: 2024-06-24 11:18:30

Task 5: Victim’s share typo#

Q: What was the typo made by the victim when navigating to the file share that caused his credentials to be leaked?

In the victim’s first SMB request, the netname was DCC01, instead of DC01. That typo meant the name never resolved via DNS, so it fell back to LLMNR, and the rogue host answered.

Answer: DCC01

Task 6: NTLM server challenge#

Q: 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?

Rogue device’s response to the NTLM negotiate carried it:

SMB2 (Server Message Block Protocol version 2), STATUS_MORE_PROCESSING_REQUIRED, Session Setup Response, MessageId 2
    Session Setup Response (0x01)
        Security Blob […]:
            GSS-API Generic Security Service Application Program Interface
                Simple Protected Negotiation
                    negTokenTarg
                        NTLM Secure Service Provider
                            NTLM Server Challenge: 601019d191f054f1

Answer: 601019d191f054f1

Task 7: NTProofStr value#

Q: Now doing something similar find the NTProofStr value.

Answer: c0cc803a6d9fb5a9082253a04dbd4cd4

Task 8: Password recovery#

Q: 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.

Added the NTLMv2 hash together in hashcat’s format (username::domain:ServerChallenge:NTProofStr:NTResponseFull):

john.deacon::FORELA::601019d191f054f1:c0cc803a6d9fb5a9082253a04dbd4cd4:010100000000000080e4d5940...

Ran it against rockyou:

./hashcat.bin -m 5600 -a 0 hash.txt rockyou.txt

Cracked in less than 1 second.

Answer: NotMyPassword0K?

Task 9: Intended file share#

Q: Just to get more context surrounding the incident, what is the actual file share that the victim was trying to navigate to?

Filtered for SMB2 traffic to see the share the victim actually meant to access.

Answer: \\DC01\DC-Confidential