CyberDefenders Write-up: CTF01

This is going to be my write-up for the first blue team CTF from CyberDefenders, involving investigating a Linux image.

The Prompt:

We’re provided with a .E01 file, which is an EnCase image format. I used FTK Imager as it was faster for me than Autopsy. Let’s break it down one question at a time.

1. What is the RHEL version of the operating system?

For this, we can simply take a look at the os-release file located in /usr/lib directory;

2. How many users had a login shell?

For this, we can look at the/etc/passwd file;

Check the references section at the end to know more about the differences between a login shell & a normal shell.

3. How many users were allowed to run the SUDO command on the system?

Now, typically to know which users have super user access we would simply look for the group sudo in /etc/group file. But in this case, I noticed that there was no such group.

However, a group named `wheel` stood out with 2 distinct users.

The wheel group is a special user group used on some Unix systems to control access to the su command, which allows a user to masquerade as another user.

Now, groups aren’t there for no reason. They exist because there is a general need of administration in such systems. So, upon taking a look at the sudoers file, which is the place where user permissions are stored, we see this;

An entry for the **wheel** group with same permissions as root, which is **ALL!** So, we have 2 users (cyberdefenders & rachel) who were allowed to run sudo.

4. What was the password of ‘rossatron’ account?

We can easily obtain hashes of all the users from /etc/shadow file, and use John to crack them.

…And it’s **rachelgreen**, who would’ve guessed it?

5. What was the victim’s IP address?

Now before we dive deep into the attack’s entire scope, I’d like to summarize it because context is necessary as the question order wouldn’t do any good to understanding it.

This is a classic authentication bypass & privilege escalation attack, by exploiting a recent vulnerability that allowed to create a privileged user & then set a password for it. (CVE info covered in a later question)

The attacker in this case, first got access to the user chandler somehow (from within the same network as we’ll see next), and created a privileged user rachel by exploiting the vulnerability in the policy kit.

From dnf.rpm.log file, we can see that the `polkit` daemon and dependencies, had to be downgraded so that the attacker could exploit it.

For this question, we can find the victim’s IP address from secure log file in /var/log directory.

6. What service did the attacker use to gain access to the system?

Let’s examine the .bash_history files of the compromised users to get a clear picture of the attack vector.

**[.bash_history** of user **chandler]**

Notice that the attacker adds his RSA key to the authorized_keys file in .ssh/ directory to maintain persistence.

We can see the attacker’s and his machine’s name.

We can also verify this in the secure log file;

[**secure** log file found at **/var/log**]

So, the answer will be ssh, the service that was used to gain access.

7. What was the attacker’s IP address?

The attacker’s IP (192.168.196.128) is in the same subnet as the victim’s IP (192.168.196.129). We can safely assume that the attacker was either able to get a reverse shell, an ssh connection or had physical access to the machine.

This was the first IOC that I found at the time of solving this challenge, we directly download a shell script from the attacker’s domain. The attacker uses cron to schedule a python script which will play in later.

8. What authentication attack did the attacker use to gain access to the system? (one word no spaces)

We can easily answer this one as **brute-force** attack examining the `secure` log file.

9. How many accounts was the attacker able to get their password?

We’re not counting the user rachel here because it was created by the attacker.

10. When did the attack start? (DD/MM/YYYY)

For this, we can look at the secure log file (as seen in above screenshots), and the brute force attack is shown to start on August 23rd.

So, 23/08/2021 is the answer.

11. What is the compromised user account used to gain initial access to the system?

As seen earlier from the .bash_history files, the user chandler was compromised first from whose shell the attacker pivoted to create the privileged user rachel.

12. What is the MITRE ID of the technique used to achieve persistence after the intial access? (Txxxx.xxx)

A quick search for persistence tells us the MITRE ID we need;

13. What is the CVE number used by the attacker to escalate privileges? (CVE-xxxx-xxxx)

After looking around a bit, I found the exact CVE, check references for more;

As of 30/09/21, this vulnerability hasn’t been patched.

The answer will be CVE-2021–3560.

14. The attacker dropped a backdoor to achieve persistence. The backdoor received commands from a Gmail account. What is the email used to send commands?

Here’s where things get interesting. Thus far, we haven’t established the attacker’s motive yet. As it turns out, the attacker planted a keylogger on the machine, persistence and a backdoor to it. A full APT in action!

Remember the python script which was scheduled using the cron functionality? We can find it’s location by taking a look at the cron file located at /var/log.

We find a Command-n-Control python script!

On top of that, the same script is set to run as root, on each boot using spool functionality.

Let’s examine the c2c.py script;

This script set’s up an SMTP server, and receives commands from the attacker, much like a reverse shell.

15. The attacker downloaded a keylogger to capture users’ keystrokes. What is the secret word the attacker was able to exfiltrate?

Now, coincidentally we have the best for last…

Remember, that xfil.txt file?

Hmmm… Nothing that makes sense… maybe yet??

We also found a xfil.py script at /etc/ so let’s examine that;

The script seems to be using termbin, which is like paste-bin but you can use it from within a shell.

The file that’s opened, /dev/input/event1 and other such files in coordination, is where the Linux kernel stores the keyboard input temporarily to interpret the events of mouse and keyboard. All that data, is encoded in hex here before creating a termbin.

Termbin is the platform where data was being sent to, if you go to their landing page we can see the usage.

I tried running a test command and the output gives me the link to the termbin just created.

The test command writes what I echoed which are these curly braces.

In the script, {} is being used as a wildcard to send the keystrokes in /dev/input/event1 file, via the format() method in python. After a termbin link is generated, the script seeks out the unique identifier and saves it to xfil.txt! If we use the part that we found earlier in rachel’s home directory to visit the page…

Oh no! A 404? We don’t like to see that…

The termbin link must’ve expired, but the challenge author informed that even so, you can finish the challenge. After thinking for a while, I sought out the wayback machine to see if an instance was captured whilst the link was still up…

We’ll need to decode this data from hex first;

This gives us similar output to the character special event files.

Let’s save it as bin, to interpret the keystrokes;

This little python snippet prints the input data from the raw unreadable format.

Run & save the result in a new file using python rev.py > steps.txt

Now we have this data which is how the Linux kernel parses the keystrokes to the actual value in the OS.

Here’s the format of the above data;

(TimeStamp_INT, 0 [Reserved], TimeStamp_DEC, 0 [Reserved], type, code [key pressed], value [press/release])

The useful part for us here are the key pressed, all the second last values.

You can find the official mappings of keys to values, from the official Linux kernel repo.

After mapping the keypresses from their parsed values manually, I got this;

YOUR SECRET IS HAVEAGOOOODDAY

Which I most definitely did, thanks to the challenge author!!!

Keep an eye out for CTF02 over at CyberDefenders!

End Notes and References:

A very important lesson I’ve learnt from this challenge is to make the logs your best friend. Oftentimes, we overlook silly but very critical information which can be essential in pivoting and going about a case.

Also, to develop a habit of note-keeping. A simple thing to do but finishing this write-up, I realize it’s more useful than I thought!

What is Login Shell in Linux?

What is the significance of the “wheel” group?

CVE-2021–3560: a reliable C based exploit for CVE-2021–3560.

Exploring /dev/input

linux/input-event-codes.h at master · torvalds/linux