Introduction

In the bustling town of Eastmarsh, Garrick Stoneforge’s workshop site once stood as a pinnacle of enchanted lock and toolmaking. But dark whispers now speak of a breach by a clandestine faction, hinting that Garrick’s prized designs may have been stolen. Scattered digital remnants cling to the compromised site, awaiting those who dare unravel them. Unmask these cunning adversaries threatening the peace of Eldoria. Investigate the incident, gather evidence, and expose Malakar as the mastermind behind this attack.

Type: Forensics
Difficulty: Medium
Event: Hack The Box Cyber Apocalypse 2025: Tales From Eldoria (ctftime)
Author: thewildspirit

Official write-up:
https://github.com/hackthebox/cyber-apocalypse-2025/tree/main/forensics/ToolPie

Initial recon

Given:

$ sha256sum *
03b6b7b65e4a2cd1b02b35ef814ce79c2d6746436394f7b42757cb0c4d79f88a  capture.pcap

$ wc -c *
8613560 capture.pcap

Archive contains only capture.pcap - which given its size (over 8.5 MB) it can be expected to contain some binary data exchange.

Investigation

Start wireshark and let’s see what we have there.

Brief scrolling through the packets show a lot of TCP packets. Borrowing the presentation technique from the author let’s do not infer the conclusions based on the glance of such inferior and unreliable tool like an eye. Statistics > Protocol Hierarchy - yes, majority of traffic is TCP data.

We can go furhter and check Statistics > Conversations:

One route stands out and it’s the one that transferred ~9MB of data to the 13.61.7.218 on port 55155. Because we’ve already seen the HTTP requests, ports :80 and :443 should not be that suspicious (but only in this CTF scenario, usually :80 is something that should be given special care).

01. What is the IP address responsible for compromising the website?

We have one IP on the radar - but so far we only know that it is where probably exfiltrated data were sent. We still don’t know who initiated the attack. Because question especially asks about the website, let’s check all HTTP traffic.

One specific raw stands out - /execute coming from 194.59.6.66. Packet details ultimately points that this indeed was mallicious intent.

Answer: 194.59.6.66

02. What is the name of the endpoint exploited by the attacker?

Already found.
Answer: execute

03. What is the name of the obfuscation tool used by the attacker?

Decode the payload sent to the /execute endpoint. Right click on JavaScript Object Notation: application/json, Show Packet Bytes, select Show as JSON and save. Little clean up and we have stage 1, python script:

We can further analyze the object.

import marshal,lzma,gzip,bz2,binascii,zlib

compressed_data = b'BZh91AY&SY\x8d <<binary data>>'
marshalled_object = bz2.decompress(compressed_data)
code = marshal.loads(marshalled_object)

print(type(code))

# List all attributes and methods of the object
print("Available attributes and methods:", dir(code))

# Filter and show only callable methods
methods = [m for m in dir(code) if callable(getattr(code, m))]
print("Callable methods:", methods)

if hasattr(code, "co_consts"):
    print("Constants:", code.co_consts)
else:
    print("No constants found")

if hasattr(code, "co_names"):
    print("co_names:", code.co_names)
else:
    print("No co_names found")

if hasattr(code, "co_varnames"):
    print("co_varnames:", code.co_varnames)
else:
    print("No co_varnames found")

At this point we can see many references to the Py-Fuscate.

Answer: Py-Fuscate

04. What is the IP address and port used by the malware to establish a connection with the Command and Control (C2) server?

This was already established in initial recon and doubled in the output of previous script.

Answer: 13.61.7.218:55155

05. What encryption key did the attacker use to secure the data?

In the output of previous script we see references to the Crypto.Cipher package and AES - so with great probability we can assume that indeed AES was used to encrypt data. This alghoritm needs two parameters to work - encryption key and IV vector. Usually encryption key is constant and known for the decryptor and IV vector is different for each ciphertext. In the easiest way, IV vector is sent in plain text together with the encrypted data.

For this and the next question we first have to somehow disassembly the Python bytecode. The most straighforward is to use dis package.

Dissassembling Python bytecode

This can be done using dis.dis(). One caveat with that is the method returns None and prints directly to the standard output. One way to catch is to redirect call to some file (python dismal.py > source.dis)

import marshal,lzma,gzip,bz2,binascii,zlib
import dis

# Compressed data (example)
compressed_data = b'<<bytecode>>'
marshalled_object = bz2.decompress(compressed_data)
code = marshal.loads(marshalled_object)
dis.dis(code)

We ends with semi-readable pseudo code that looks a lot like an assembler code.

It is problematic to discuss how I’ve analyzed the pseudocode, but at this point this fragment is most important to us:9

This can be translated to Python code:

cypher = AES.new(key.encode(), AES.MODE_CBC, key.encode())

And here is where the attacked made a mistake - in his encryption alghoritm used the same value for both encryption key and IV vector.. and passed that value in plaintext together with the encrypted data.

client.send((user+SEPARATOR+k).encode())

Inspecting TCP packets sent to C&C:

Answer: 5UUfizsRsP7oOCAq

06. What is the MD5 hash of the file exfiltrated by the attacker?

We have all the information needed to recover the file.

In wireshark Analyze > Follow … > TCP Stream. Find stream with big chunks of data, select only communication to C&C, raw (important later) and save.

Now open up CyberChef. Input AES paremeters we know.

With this we can further decode all top 4 lines from the wireshark view.

1. Some bytes

2. check-ok

3. ok

4. 8504240

When you hover over the packet details in the “Follow TCP Stream” you can see from which packet data comes from:

Clear all filters and navigate to packet no. 91 - now two packets before, in 89, there is request from C&C for which response was number 8504240. Select packet 89, select Data segment, right click and copy value. This is another way to acquire the packet data from a single packet.

Decrypted value gives us information that C&C requested a PDF file and 8504240 is its size in bytes.

Now, come back to the “Follow TCP Stream” window, ensure only traffic to C&C is selected and save. Do hexdump of the saved data.

Notice that we have an unwated data at the beginning of the encrypted file. Content starts from e1 4c fe a8 (see the content of packet 94 or 5th line in “Follow TCP Stream”). Now, to carve out the unncessary data, we have to remove that many bytes (e1 starts after 69 bytes in hexadecimal base):

$$(60+9){(16)} = 105{(10)}$$

$ dd skip=105 bs=4096 iflag=skip_bytes if=raw.enc of=rawdata.enc

The result should look like this

Now upload file to the CyberChef and decode the PDF file.

Save the file and calculate its MD5, or just add MD5 block in CyberChef.

Answer: 8fde053c8e79cf7e03599d559f90b321

Bonus: pycdc

I have tried other ways to acquire something closer to the Python code - but the best what I had was running following with the Python 3.13:

import marshal,lzma,gzip,bz2,binascii,zlib
import importlib

# Compressed data (example)
compressed_data = b'<<bytecode>>'

marshalled_object = bz2.decompress(compressed_data)
code = marshal.loads(marshalled_object)
pyc_data = importlib._bootstrap_external._code_to_timestamp_pyc(code)

with open("mal_313.pyc", "wb") as out_file:
    out_file.write(pyc_data)

Then running pycdc (https://github.com/zrax/pycdc) on acquired PYC file.

This was most certainly to the fact that Py-Fuscate was used with combination of unsupported Python versions for pycdc and decompyle3.