Mayhem

Can you find the secrets inside the sea of mayhem? - by hadrian3689

The following post by 0xb0b is licensed under CC BY 4.0


In Mayhem we have been provided with a PCAP file. Our task is to analyze it, find the secrets and decode the traffic.

PCAP Analysis

At first glance, we have HTTP traffic. This originates from a Python web server. The files Install.ps1 and notepad.exe are being transmitted via port 1337.

After the notepad.exe is transferred we have further HTTP traffic. This time only on port 80. Post requests are sent at regular intervals, the data content of these appears to be encrypted.

This seems to be caused from notepad.exe. We extract the HTTP objects in order to analyze them further.

Research

Decompiling the executable using ghidra did not bring any new findings. But we can also submit them to Virustotal for analysis.

As expected, this is flagged as malicious. It is also associated with Havoc, a C2 framework. This could be a beacon. A Havoc C2 beacon is a lightweight agent that communicates with a Havoc C2 server, allowing remote control of a compromised system. It typically operates covertly, sending periodic check-ins and receiving instructions.

Havoc:

How traffic from a Havoc beacon can be analyzed is described by Immersive Labs in a blog post.

From the blog post we can draw the necessary information on how to identify and decode the traffic as such.

The traffic is encrypted as assumed. Havoc uses AES in CTR mode for this purpose.

The key material (AES key + IV) is also transmitted. Since we have HTTP traffic in front of us, we probably have access to it.

In addition, a magic byte value is transmitted to identify the demon traffic

Upon checking the Havoc C2 GitHub repository, we identified the definition of the 0xDEADBEEF magic value, found in the Defines.h file.

We search for the hex value 0xDEADBEEF and actually find it.

In addition to these, we also find the agent id, the AES key and the IV as described in the blog post.

Using tshark we can extract all media.type post requests and decipher them individually using CyberChef.

However, we must remove the header information beforehand, or only take the data into account. (Marked in white in the image above). And we see that we can decipher the traffic:

The following packets after the initial one have a header without the AES key and IV. This header is only 40 bytes long (to be identified by the COMMAND_NOJOB). By removing this header first, the subsequent data can be decrypted with the same key and IV.

Fortunately, Immersive Labs also provides a script that allows you to analyze the Havoc PCAP traffic. This script is able to extract the AES key and IV, identify the commands and store the deciphered requests and responses.

We run the script without any special flags and see that it was able to extract the AES key and the IV and some commands. We do not see what exactly happens.

We can identify the following commands.

We can identify the following commands.

We look at the source and see that the response and request bodies are stored decrypted as .bin files at the storage path if the --save flag is used. Unfortunately it is a bit of a mess and not chronologically ordered. Nevertheless, sufficient to answer all questions.

Example content:

Modifying havoc-pcap-parser.py And Decryption Of The Traffic

Tested with the following packages and tshark version:

pyshark 0.6

lxml 5.3.2

tshark 4.2.2 There may be an issue where different versions of pyshark / tshark parse the pcap differently, resulting in a different hex encoding in packet.http.file_data / empty file_data field which will not allow you to decrypt the data due to an exception thrown by tsharkbody_to_bytes.

We customize the script to decrypt even if the --save flag is not set and if something can be decrypted it is also printed to the console:

Here is the customized version of the script:

After running the script we can answer the question with context to the commands issued:

What is the SID of the user that the attacker is executing everything under?

The attacker printed a flag for us to see. What is that flag?

The attacker added a new account as a persistence mechanism. What is the username and password of that account? Format is username:password

The attacker found an important file on the server. What is the full path of that file?

What is the flag found inside the file from question 5?

Last updated

Was this helpful?