Switzerland - Relayed and Betrayed (network)

34KB
betrayer.pcap
Open

Upon a cursory inspection of the packets in the pcap, we notice mentions of ntlmssp, which refers to a protocol that uses the NTLM challenge-response mechanism.

In this case we're interested in the LLMNR protocol.

LLMNR (Link-Local Multicast Name Resolution) is used in Windows environments for name resolution within a local network, particularly when DNS fails to resolve a hostname. When a host cannot resolve a name via DNS, it sends a request to the multicast address 224.0.0.252, asking if any other host on the network can resolve the name. In this instance, the host at 192.168.56.33 attempted to resolve the hostname "dcc02" using LLMNR. This suggests that the hostname "dcc02" may have been entered incorrectly on that host. Additionally, after 192.168.56.33 broadcasted the request, a response was received from 192.168.56.104.

As such, it is possible that LLMNR poisoning was performed using the compromised machine 192.168.56.104.

An attacker can use tools such as Responder or Inveigh on a compromised machine to listen for LLMNR requests and capture NTLMv2 hashes from unsuspecting users. In other words, based on the packet data in this pcap file, it may be possible to identify the leaked NTLMv2 hash.

The NTLMv2 hash follows the format shown below. username::domainname:ServerChallenge:NTProofStr:NTLMv2Response. This is of the same format as the flag that is required of us!

Therefore, if the following four pieces of information sent from 192.168.56.104 to 192.168.56.33 can be identified in the packet data, it may be possible to determine the credentials of the user whose information was leaked.

I referred to https://www.youtube.com/watch?v=lhhlgoMjM7o to obtain the NTLM hash.

  1. Filter by ntlmssp packets. We see something like this:

  1. Get the server challenge by going to the Session Setup Response packet > Security Blob > GSS-API > Simple Protected Negotiation > negTokenTarg > NTLM Secure Service Provider > NTLM Server Challenge

  1. Get the NTLMv2Response by going to the NTLMSSP_AUTH packet > GSS-API > Simple Protected Negotiation > negTokenTarg > NTLM Secure Service Provider > NTLM Response > NTLMv2 Response

  1. The HMAC-MD5 is the NTProofStr you see right below NTLMv2Response (it is also the first 16 bytes of the NTLMv2 Response)

  2. To find the domain and user name, in the same NTLMSSP_AUTH packet go to NTLMSSP_AUTH packet > GSS-API > Simple Protected Negotiation > negTokenTarg > NTLM Secure Service Provider > Domain name / User name

After obtaining all this information, we notice that the last part of the flag / hash (NTLMv2Response) is longer than the flag specified (the NTLMv2Response is 652 characters instead of the expected 620. This is because the first 32 characters or 16 bytes are used as the NTProofStr and are therefore redundant.

When we submit the flag in the format 

CSG_FLAG{username::domainname:ServerChallenge:NTProofStr:NTLMv2Response[:32]}

it is accepted.

Last updated