# PLATFORM          HTB
# CTF NAME          Noxious
# DIFFICULTY        Very Easy
# CTF LINK          https://app.hackthebox.com/sherlocks/Noxious

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.

---

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 typically happens over UDP port 5355. In this regard, we’ll filter our packet capture to match this rule

udp.port == 5355

• Only the DC should respond to LLMNR queries.
• Consider the source IP of requests coming fromForela-Wkstn001 as the rogue machine.

What is the hostname of the rogue machine?

• Now that we have a suspect device, we can use its IP to query for DHCP packets.

ip.addr == 172.17.79.135 && dhcp

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?

smb2

ntlmssp

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?

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?

DCC01

• DCC01 queried instead of DC01. This caused a fallback to LLMNR.
• Can be seen in the first screenshot (question 1)

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?

601019d191f054f1

• on Packet 9291, expand SMB2
  • Session Setup Response
    • Security Blob
      • GSS-API Generic Security Service Application Program Interface
        • Simple Protected Negotiation
          • negTokenTarg
            • NTLM Secure Service Provider
              • NTLM Server Challenge

Now doing something similar find the NTProofStr value.

• on Packet 9292, expand SMB2
  • Session Setup Response (0x1)
    • Security Blob
      • GSS-API Generic
        • Simple Protected Negotiation
          • negTokenTarg
            • NTLM Secure Service Provider
              • NTLM Response
                • NTLMv2 Response
                  • NTProofStr.

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.

• The NTLM authentication and negotiation occur in sets of three (3) packets. Each negotiation includes an: 

  1. NTLMSSP_NEGOTIATE packet.

  2. NTLMSSP_CHALLENGE packet.

  3. NTLMSSP_AUTH packet.

• To filter after the information above, use ntlmssp in wireshark.

• To recover this hash, we have to craft the following value

{User}::{Domain}:{ServerChallenge}:{NTProofStr}:{NTLMv2Response}(without first 16 bytes/32 characters).

OBTAINING USER

• in NTLMSSP_NEGOTIATE, expand SMB2 -> SMB2 Header -> Session ID -> Account.

OBTAINING DOMAIN

• Same path as above. included in the screenshot above also.

OBTAINING SERVERCHALLENGE

• In NTLMSSP_CHALLENGE packet expand SMB2 -> Session Setup Response (0x1) -> Security Blob -> GSS API Generic -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> NTLM Server Challenge.

OBTAINING NTPROOFSTR

• In NTLMSSP_AUTH Packet expand SMB2 -> Session Setup Request (0x1) -> Security Blob -> GSS-API Generic -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> -> NTLM Response -> NTLMv2 Response ->NTProofStr.

OBTAINING NTLMV2RESPONSE

• In NTLMSSP_AUTH Packet expand SMB2 -> Session Setup Request (0x1) -> Security Blob -> GSS-API Generic -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> NTLM Response -> NTLMv2 Response. 

The final value is

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

• To crack this, we can use hashcat

hashcat -a0 -m5600 hash.txt rockyou.txt

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

• Look through SMB (smb2 filter in Wireshark) logs for non-standard shares.