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.
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?
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.
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:
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 (https://elnath.io/2020/06/09/dimensionless-loading/) 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
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:
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
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.