Mad CTF Disease

Misc [350]

Description: Todo: [x] Be a cow [x] Eat grass [x] Eat grass [x] Eat grass [ ] Find the flag

So we are given a picture of a cow. In cow.jpg

Running Steghide on this image gave us moo.txt:

I did not know what this was so I randomly googled: “decode moo”

We are given a link that resembles the same type of text given to us:

It turns out that this is a COW esolang. So decoding our text using the above link gives us:

Peculiar Packet Capture

Forensics [400pts]



We have a situation brewing. Last week there was an attack on the prime minister of Morocco. His motorcade was stopped by a road blockade where heavily armed men opened fire on them. Fortunately, the prime minister was able to escape safely but many personnel and a few other ministers did not.

ATLAS, a multi-national Private Military Corporation (PMC) based in Colorado, USA, is our main suspect. We believe they were hired to conduct the hit by the opposition political party.

We flew Agent Jason to Colorado to investigate further. He gained access to their building’s reception area dressed in a suit acting as a potential client with an appointment. He was able to intercept wireless network traffic from their corporate wireless network before being escorted out by guards when they realised the bluff.

The network capture is attached below, see if you can recover any important documents which could help us tie ATLAS to the Morocco incident.

We are given a Wireshark capture file and when looking at it, it seems that they are using the EAPOL protocol with authentication keys.

Looking at each of the keys, they are using 802.11 authentication to encrypt the keys. So I thought to decrypt them somehow.

This blog ( contained useful information on how to decrypt the keys.

But first, we needed to crack the WPA2 password in order to use this method. A popular tool is Aircrack-ng, which is what I used for this challenge.


#5 is the only bullet point I used for this challenge. Using rockyou.txt as my wordlist and the MAC address of the source:

It turns out the key was nighthawk.

So using the decrypt-wpa2-psk-using-wireshark method shown above, I had to generate a PSK using this link (provided as well in the blog above):

The SSID was ATLAS_PMC and passphrase was nighthawk. Our hex key is:


When applying the hex key (with key type: wpa-pwk) to our WEP and WPA decryption key in Wireshark preferences, we are now shown packets that were not shown before, most notable a PDF.

So after extracting this PDF from WireShark, we are presented with the flag at the bottom:

Disk Forensics Fun

Forensics [350pts]



Get your forensics gloves out.

We’ve managed to exploit a network service running on a C2 server used for orchestrating a large botnet. From there we were able to escalate our privileges and use that server as a proxy to pivot to other machines in the network.

It’s quite fascinating, based on the machines we have found, we think that these guys are a known bad actor, responsible for leaking private documents and data from corporate and government targets, which changes our current focus from a reconnaissance mission to a criminal investigation which involves gathering evidence on them so we can attribute names to actions for further prosecution in the courts.

Thus, we’ve started to image the disks of all the machines we have managed to pivot on. It’s not the most ideal circumstances for admissibility of evidence, but we do have a warrant on the guys involved and we can let our lawyers do the rest.

Anyway, I’ve attached a disk image of a small Linux server which we believe they’re using for temporarily keeping exfiltrated files.

Can you take a look and see what you find?

Good luck.

We are given an image.E01 file and are asked to investigate this. E01 files are Encase image file formats for disk evidence.

I viewed this file using Autopsy. We see a small Linux system in here:

Looking closely into the main files like HOME and ROOT, I found a PGP message long with PGP public and private keys:

To decode this, I exported the PGP message and private key and used gpg.

This manual is helpful for decrypting PGP using a private key:,output%20doc%20%2D%2Ddecrypt%20doc.

Initially, my output was to doc, but looking further it seems that doc contains HTML elements worth looking into. So I ran it again and extracted the output to an HTML file.

Looking at the doc.html, we see a rather creepy picture:

Those values in the picture seem interesting, so I copied those and decoded from hex, revealing our flag at the bottom:


Access Granted

Steganography [450pts]



Do you recall the C2 group exfiltrating data we were tracking last year? Well, as it turns out, we’ve managed to corroborate their activities with APT-47 nicknamed ‘The Engineers’. Their operations span across a wide range of industries, including disrupting SCADA systems and stealing corporate data.

Recently, they’ve been leaking unreleased tracks from various media groups. A Canadian firm, which suffered a fresh leak, has requested us to take a look. Over the past few days, our analysts have combed through network data trying to identify which computers or servers may have been compromised and used.

In order to bypass detection from IDS/DLP signatures, we think they’re somehow extracting these tracks by hiding them in existing music videos so it blends in with usual traffic. We’ve attached a video that we believe is going to one of their IP addresses, can you take a look?

We are given an mp4 file that is 46MB. Looking at the file using a hex editor, we see that there is a password on the bottom that we will need for later:


I couldn’t find anything interesting for this mp4. There was a MySQL index file, JPEG and PNG using binwalk but the challenge creator confirmed this was a false positive. So looking up video steganography techniques, I found one option that uses a rare technique (indicated by the challenge creator) : TCSteg


It turns out that TCSteg involves adding a hidden volume in an mp4 file. So trying this out, I looked for tools that can open hidden volumes. One option was TrueCrypt but it was discontinued around 2014. So the other option was the updated version: VeraCrypt.

Using VeraCrypt, we are able to use the password we found: guitarmass

Looking at the A: drive, we see an image displaying our flag:

Cheap Facades

Steganography [400pts]

Description: We’ve found a JPEG, but it doesn’t seem to open in any of our editors. Can you see what’s going on?

We are given a flag.jpg that won’t open in any photo viewer. So looking at it in a hex editor we see some strange occurrences.

The image has a JFIF in the header (for jpgs) and IHDR + IDAT (for PNGs). It seems that there is a broken header in this image and it is not really a jpg, but more like a PNG. There is even an IEND at the bottom of the file.

The next step is to replace the broken header with a valid PNG header. Valid PNG headers look like this:

After replacing our broken header image with a valid PNG header, we run pngcheck only to find that it has invalid dimensions 0x0. This is a similar problem to Dimensionless Load ( and requires us to fix the issue.

I used the same python script as I did for Dimensionless Load:

After letting it run, it turns out the dimensions were: 420 x 69

Dimensionless Loading

Steganography [250pts]

Description: This PNG looks to be valid, but when we open it up nothing loads. Any ideas?

We are given an image that is unable to open. Running pngcheck, we see that there are invalid dimensions for the image 0x0. When we view this in a hex editor, the byte blocks where the width and height would be is 0x0.

Intuitively we would want to add some dimensions to this, but doing so will ruin the CRC values and mess up the image. An intended solution is to reverse the CRC values with a valid dimension..but I ended up bruteforcing it anyway.

I wrote a small python script to bruteforce the dimensions and write to a new image as well as run pngcheck to see if it is valid:

After letting it run for a while, it turns out the valid dimensions came out as 1378 x 363:

Cut Short

Steganography [200pts]

Description: This image refuses to open in anything, which is a bit odd. Open it for the flag!

We are given a .png image that does not open in anything we try. So looking at the image using a hex editor, we see a major flaw:

The IEND is supposed to be at the very end of a valid PNG. So, replacing this block with 0’s will allow us to view our flag:

A Monster Issue

Forensic [100pts]



We’ve got a case of industrial espionage, quite an unusual one at that. An international building contractor – Hamilton-Lowe, has written to us that they are having their private client contracts leaked.

After conducting initial incident response, they managed to find a hidden directory on one of their public facing web-servers. However, the strange thing is, instead of having any sensitive documents, it was full of mp3 music files.

This is a serious affair as Hamilton-Lowe constructs facilities for high-profile clients such as the military, which means having building schematics leaked from them could lead to a lapse in national security.

We have attached one of these mp3 files, can you examine it and see if there is any hidden information inside?

So looking at the mp3 file, I ran a quick binwalk to see if there are any hidden files. It turns out there is a compressed zip folder containing a .wav file.

Further examination of the .wav file using the strings command, we see that there is a flag.png hidden in the file.

Now running binwalk on the .wav file and attempting to extract the image, we are stopped by a password:

Looking further into the .wav file, we don’t find anything interesting. So now we look at a wav spectrum analyzer to see if we can get anything.

We see that the password was hidden here the whole time: Shad0ws

Extracting the flag.png will give us our flag:

A Musical Mix-up

Steganography [200pts]

Description: One of our guys found a strange midi file lying around on our servers. We think there might be some hidden data in it. See if you can help us out!

We are given a midi file (challenge.mid) that plays a sequential tune. When we analyze this midi file using a MIDI file to text online tool, we see interesting values:

The numbers on the right look especially interesting, I thought of ASCII decimal values and it turns out that this does spell out the flag:

114 97 99 116 102 123 102 53 48 99 49 51 116 121 95 108 51 118 101 108 95 53 116 51 103 33 125

Flag: ractf{f50c13ty_l3vel_5t3g!}


Web [250pts]

Description: A target service is asking for two bits of information that have the same “custom hash”, but can’t be identical. Looks like we’re going to have to generate a collision?

When we navigate to the home page, we are greeted with the source code, detailing the conditions for getting the flag and type of requests to be made:

So we know that our request body has to be JSON and that we will receive 400 errors if there is an invalid body or if we are missing request parameters “one” and “two”. Also there is a customhash not shown to us that is hashing what we send to /getflag.

Using Postman, I tried out a few sample payloads and received it’s hash value as well as rejections:

Since the hash is custom, bruteforcing would take a while. But, looking back at the source code we see that the parameters “one” and “two” are being compared with == instead of ===.

A loose comparison such as this will lead to vulnerabilities where two non-equal inputs will evaluate as true.

Looking at a useful JS comparison table:

We can see that [1] and “1” evaluate as true. When we try this for our request body, we can receive our flag without having to bruteforce anything: