TryHackMe Mayhem—Writeup

Welcome back to my writeup! Today I will show you the step-by-step on how I solved Mayhem from TryHackMe!
File Analyzation
The challenge provides a .pcap file, which I examined using Wireshark for network traffic analysis.

Initially, the captured network data reveals HTTP traffic, which appears to come from a Python-based web server. Upon closer inspection, we can see that two files—Install.ps1 and notepad.exe—are being transferred over port 1337.
As I dug deeper into the packet data, I came across this particular traffic.

Once the transfer of notepad.exe is complete, additional HTTP traffic emerges—this time strictly over port 80. A series of POST requests are made at consistent intervals, and the data within these requests seems to be encrypted.
Next, I proceeded to extract the HTTP objects for a more in-depth analysis.

I began by reverse engineering notepad.exe, but it didn’t reveal anything useful.
Given that this is an executable file, I had a strong suspicion it might be malicious. To verify, I generated its MD5 hash using md5sum and then submitted it to VirusTotal for a malware scan.

Just as I suspected, the file was flagged as malicious. Interestingly, it’s linked to Havoc, a command-and-control (C2) framework. This suggests that the file might function as a beacon—essentially a small, stealthy agent designed to maintain communication with a Havoc C2 server. These beacons usually run silently in the background, regularly reaching out to the server to check for new commands or deliver updates, allowing an attacker to remotely manage the compromised system.
At this stage, I wasn't sure how to analyze traffic from a Havoc beacon. Fortunately, I came across some documentation that provided the answers I was looking for.
The traffic is encrypted, with Havoc using AES in CTR mode for encryption. The key material, including both the AES key and IV, is also transmitted along with the traffic. Given that we’re dealing with HTTP traffic, it’s likely that we have access to this data.
Additionally, a specific "magic byte" is included to help identify the beacon traffic. While reviewing the Havoc C2 GitHub repository, I discovered the definition of the 0xDEADBEEF magic value in the Defines.h file, which confirmed its role in recognizing the traffic.
The next step involves creating a program to decrypt the communication between the C2 server and the client in order to answer the task’s questions. The Havoc C2 server exchanges keys during the process, and if we manage to capture them, we can use them to decrypt the traffic. Fortunately, I found an existing script on GitHub that is specifically designed to decrypt traffic between a Havoc C2 server and an agent, which proved to be very useful for this task.
When we execute it, this is the result we get.

We got the Key and IV, and also the magic bytes deadbeef .
By examining the request, you'll notice these commands.
The next step I took was to create my own script, one that not only reveals the key but also decrypts the entire traffic.
Run and we should obtain the complete decrypted traffic.
Now, let's answer the questions based on the output generated by the script I created.
What is the SID of the user that the attacker is executing everything under?

What is the Link-local IPv6 Address of the server? Enter the answer exactly as you see it.

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?

We've successfully solved the Mayhem!
Last updated