Noxious

CHALLENGE DESCRIPTION

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.

SOLUTION

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.

Hint

First identify the IP Address of the domain controller. Any LLMNR requests originating from some other machine to another machine is a sign of a rogue machine pretending to be a Domain controller to capture hashes. Filter for LLMNR. We see only 1 IP address responding to our victim machine to their query. This IP Address does not belong to the domain controller.

Answer

172.17.79.135

What is the hostname of the rogue machine?

Hint

Add a filter for the IP address and DHCP. In Wireshark, it will be “ip.addr == 172.17.79.135 && dhcp”. Then look for the hostname value in one of the packets. The reason why we use this is because the device used dhcp to get an ip address assigned to itself and map it to its hostname.

Answer

Kali

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?

Hint

First filter for SMB traffic. In Wireshark it is “smb2”. Here we see some ntlmssp negotiate and auth which means the hash indeed got captured. To further narrow down this add the filter smb2 && ntlmssp. We can see the user name in NTLMSSP_AUTH packets

Answer

john.deacon

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?

Hint

First we need to modify the wireshark view option. Go to View > Time display format > UTC DATE and look at the the time of the first 3 packets.

Answer

2024-06-24 11:18:30

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

Hint

When looking at LLMNR traffic we saw that attackers machine responded to a query “DC01” which means that the victim typed DCC01 instead of DC01 which caused the DNS to fail and the machine to fall back to LLMNR protocol to resolve the query and thats where attackers rogue machine responded to the query pretending to be a domain controller.

Answer

DCC01

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?

Hint

Filter for ntlmssp details of the NTLMSSP_CHALLENGE PACKET (Packet # 9291 in our case) expand SMB2 (Server Message Block ProtocolVersion 2) -> Session Setup Response (0x1) -> Security Blob -> GSS-API Generic -> SimpleProtected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> NTLM Server Challenge.

Answer

601019d191f054f1

Now doing something similar find the NTProofStr value.

Hint

In Packet(Packet # 9292) packet details expand SMB2 (Server Message Block Protocol Version 2) -> Session Setup Response (0x1) -> Security Blob -> GSS-API Generic -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> -> NTLM Response -> NTLMv2 Response -> NTProofStr.

Answer

c0cc803a6d9fb5a9082253a04dbd4cd4

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.

Hint, NetNTLMv2 format

User::Domain:ServerChallenge:NTProofStr:NTLMv2Response(without first 16 bytes).

Look at the packet from question 7, we will get all the info above.

The NTLMv2 Response value can be found from where we found NTProofStr. Remove the first 16 bytes(32 characters) from the value. Then crack the hash using hashcat.

hashcat -a 0 -m 5600 hashfile.txt rockyouwordlist.txt

Answer

NotMyPassword0k?

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

Hint

Filter for SMB traffic. In Wireshark, it is “smb2”. Then keep scrolling until you see a tree connect/disconnect of a NON-DEFAULT File share name. This will make sense if you keep in mind the typo the victim made in Question 5.

Answer

\\DC01\DC-Confidential