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.

LLMNR (Link-Local Multicast Name Resolution) is a fallback name-resolution protocol used by Windows when:

• DNS fails
• NetBIOS name resolution is unavailable

Instead of asking a DNS server, the machine basically shouts on the local network: “Hey, who is FILESERV01?”

LLMNR poisoning is when an attacker:

1. Listens for LLMNR broadcast requests
2. Responds pretending to be the requested host
3. Tricks the victim into authenticating to the attacker
4. Caputres NetNTLM hashes

That’s the “poisoning” part — you inject fake answers into name resolution.

Typical Attack Flow:

1. Victim tries to access: \\intranet-share
2. DNS fails
3. LLMNR broadcast goes out
4. Attacker replies: That’s me
5. Victim send NTLM auth
6. Attacker captures NetNTLM hash

LLMNR port is UDP 5355. So on Wireshark, we can filter on:

udp.port == 5355

Once filtered, we see 172.17.79.135 is responding to broadcasts

Task 2 – What is the hostname of the rogue machine?

• Filtering on the source IP we discovered and filtering on DHCP logs using the following query: ip.addr == 172.17.79.135 && dhcp, we find that the hostname is 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?

• Filtering on port 445 using the following query: tcp.port==445, we find that the user was 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?

• We should filter on NTLM Authentication Type 3. Doing this, we find 2024-06-24 13:18:30. Converting it to UTC, we get 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?

• To get the query, we need to filter on LLMNR by typing llmnr in wireshark. We find that the typed 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?

NTLMSSP = NT LAN Manager Security Support Provider

Which is the authentication protocol layer that implements NTLM

NTLMSSP is not a network protocol by itself.

It’s a security mechanism that is:

• Embedded inside other protocols
• Exchanged as structured binary messages

NTLM type 2 is the challenge message.

Type 1 (Negotiate)  → no challenge
Type 2 (Challenge)  → SERVER CHALLENGE (8 bytes)
Type 3 (Auth)       → RESPONSE (hash), no challenge shown

It’s sent by the server to the client and its job is simple but critical:

“Here is a random challenge. Prove you know the password without sending it.”

Without Type 2, NTLM cannot work.

Filtering hence on ntlmssp && ntlmssp.messagetype == 2, we find the challenge to be 601019d191f054f1:

Task 7 – Now doing something similar find the NTProofStr value.

NTProofStr = NT Proof String. It is sent in NTLM Type 3 (Authenticate). Filtering on messatype 3 and NTLM in wireshark using ntlmssp && ntlmssp.messagetype == 3, we get the response:

The NTProofStr value is the first 16 bytes after removing the metadata:

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.

• To crack the password, we need the following:

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

• The value will be:

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

• Cracking using Hashcat:

hashcat -m 5600 hash /usr/share/wordlists/rockyou.txt

• We get the password 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?

• The file was \\DC01\DC-Confidential: