GreHack 2017 – Write Up Forensic 400

CERT-DVT Forensics, Writeups

1 Introduction

GreHack is a french security event which takes place for its 4th edition in Grenoble, on 17th November 2017.

https://grehack.fr/

The CTF takes place from Friday 9:30 PM to Saturday 6:00 AM.
53 teams work hard on around 35 challenges in different topics like: Steganography, Reverse, Web, Hardware, Crypto, Network, Exploit, Forensic and Table football (ye!).

The following write-up details a solution of the highest forensic challenge, created by us for this CTF. All constructive feedbacks are welcome.

2 Challenge description

Title : Inception
Authors : iggy & olivier (idea)
Category : Forensic
Points : 400
File : chall.zip (220M, 1G decompressed)
Validation : 1
Description:
Securimag team had extract the laptop memory of a villain student.
We only known a couple of things :
_ He probably use an up to date Kali-Light distro
_ He use a malicious file to compromise their victims
Could you find and analyze this file from the dump ?

3 Linux volatility profile

So what do we have? The ‘file’ command doesn’t help much:

We know from description than villain use a Kali-Light Linux. We use simple strings to know which version :
Linux memory forensic is a bit harder at the first stage than windows memory analyze, because most of the time volatility doesn’t have the good profile and we must create our own profile.
Olivier already writes a good example here:
https://www.cert-devoteam.fr/en/ndh-qualifications-write-up-bender-bending-rodriguez-challenge/

To summup :
_ installation of kali-light 4.12 in a VM
_ update it to 4.13
_ create the volatility profile as follow :

 apt install dwarfdump
 apt install linux-image-4.13.0-kali1-amd64
 apt install linux-header-adm64
 apt install volatility-tools
 apt install make zip
 cd /usr/src/volatility/tools/linux
 make
 zip /tmp/kali4.13.zip module.dwarf /boot/System.map-4.13.0-kali1-amd64

The kali4.13.zip is our volatility profile for this challenge. To be able to use it, just copy it to volatility/plugins/overlays/linux/ folder.

Ok now we can play.

4 The Malicious file

Using the module linux_bash, hightligh a lot of useful informations :
Villain moves to “Victims” folder, then looks on todo_payload.txt.
Then moves to Dumps folder, and recursive downloads something from http://amstrad-fans.com.
He returns back to home directory, edits his .bashrc and reloads it.
At the end he launches some volatility commands.
Ok, lot of things here. We begin with todo_payload.txt.
Because villain displayed it with the cat command, maybe a simple strings could retrieve the content.

Taking a look on pastebin url, we get a joke explains that source code isn’t here anymore
But we’ve probably found the villain malicious file name : Nude_Admstrad_CPC_6128_Emulator.exe
We try to recover it with linux_find_file module, but the binary isn’t in the dumpfile.

5 http://amstrad-fans.com

The website http://amstrad-fans.com exists. It was hosted on local server, only reachable by CTF players.
But it reveals nothing interesting at first look, only floppy disk image as home page.
To know more on it, we begin with… strings again.


It reveals strange things. At offset 1490b268 to 1490b768, this is typically event log entries from Windows system. It appears that some administrator user downloaded the malicious file.
Unfortunately the file is gone too:
http://amstrad-fans.com/Nude_Amstrad_CPC_6128_Emulator.exe issue a 404 page…
This is the output of wget command. We get some full url path to .dmp files.
Maybe dumps are still here.
http://amstrad-fans.com/d41d8cd98f00b204e9800998ecf8427e/1510100407.dmp
http://amstrad-fans.com/5429f4e508af61b71565164b66196825/1509300346.dmp
http://amstrad-fans.com/7bda79af8fdbef3eed0cc6de1b92d64e/1510359726.dmp
To find which dump file we need to download, the bash history helps us again. Villain modify bashrc then doesn’t provide any ‘-f’ option when he using volatility. It means he probably set the environment variable VOLATILITY_LOCATION :

So the good dump is the : http://amstrad-fans.com/7bda79af8fdbef3eed0cc6de1b92d64e/1510359726.dmp
Unless you like Teletubbies or Hardtek, the two other dumpfiles aren’t relevant.

6 The Windows memory dump

So now we get a second memory dump file, from a “Victim” now, and it’s a windows.
Analyze it is very classical, in addition we have the profile we need to use from psenv output.

Yes, the dump was done when victim executed the malicious file.

We retrieve it with this couple of commands :

7 Reverse the file

The file is a PE binary :

Quick look on it reveals that the content is xored by hardcoded key :

The key is : 0x797872a552B3B0BB
The xor operation needs to be started at rax+0x27, i.e +0x1827 of file itself.
Here the dirty couple of commands we use to xor back the file:
Ok, now look on binary, it’s like a meterpreter.
The todo_payload.txt asks to modify url to match with current CC.
So look for string like “flag”, “http” or “gh17{” (the flag format), and the following url appears :

8 Retrieve the flag

We use volatility again to retrieve the file c:\windows\mob.bin from windows dumpfile :


Finally the flag is on this picture :

 

Yvan Genuer