The Magnet Forensics Weekly CTF has been running since October and sets one question each week using an image that changes each month. The October questions were based on an Android filesystem dump. November’s image is Linux, more specifically a Hadoop cluster comprising of three E01 files. The images were created by Ali Hadi as part of his OSDFCon 2019 Linux Forensics workshop; the November CTF questions are based on Case 2, which can be downloaded here.

This was another two-part challenge; identify what was installed following a compromise, then determine why. You can find my other Magnet Weekly CTF write-ups here.

Part 1

What package(s) were installed by the threat actor? Select the most correct answer!

The question as written doesn’t mention which of the images are in scope, but the on the video announcement for the question Ali Hadi specified the question refers to the primary node (HDFS-Master.E01). As usual I started by mounting the mounting the image using ewfmount.

# ewfmount /mnt/hgfs/Shared/mwctf/linux/HDFS-Master.E01 /mnt/ewf
# losetup --read-only --offset $((2048*512)) /dev/loop20 /mnt/ewf/ewf1
# mount -o ro,noload,noexec /dev/loop20 /mnt/ewf_mount/

Initially I thought the “threat actor” referenced in the question was another bit of wordplay that I have completely missed so often over the last questions; “threat actor” to “Advanced Persistent Threat” to the “apt” package manager. I suspect I’m seeing connections that weren’t intended, but the apt/history log is where I found the answer to Part 1.

Assuming that the most recent entries in the log would point toward the threat actor, I used the tail command.

tail /mnt/ewf_mount/var/log/apt/history.log

Using the default options tail shows the two most recent apt executions from the log: the first looks like a Linux kernel upgrade, and the second installed php and the associated packages for PHP 7.0

I found the “select the most correct answer” comment to be a bit vague but my first answer of php was accepted.

One interesting point from the log: note the length of time between apt recording any package management activity.

Start-Date: 2017-11-08 06:12:58
Commandline: /usr/bin/unattended-upgrade

Start-Date: 2019-10-07 01:30:31
Commandline: apt install php

Almost two years between the commands! Timezones are hard, but it’s probably a safe assumption that the host was compromised around the 7th of October 2019.

Flag (Part 1)

php

Part 2

Why? (two attempts)

• hosting a database
• serving a webpage
• to run a php webshell
• create a fake systemd service

Part 2 simply asks why? Four options are provided, but with only two attempts available we need to do some analysis rather than just guessing. That being said though, the first two options seemed unlikely post-compromise activities, so I began by investigating the systemd services.

The systemd service descriptions are stored in the /etc/systemd/system directory:

ll /mnt/ewf_mount/etc/systemd/system/

Based on the timestamp alone the cluster.service file stands out. But the 6th of October 2019 is earlier than the PHP installation we found in Part 1. Let’s get the inode number and check with istat:

ll -i /mnt/ewf_mount/etc/systemd/system/cluster.service
sudo istat -o 2048 /mnt/ewf/ewf1 2229804

File Created: 2019-10-06 22:28:16.492115650 (UTC)

That’s better. My SIFT VM is configured to use UTC locally. It seems that the timestamps written into the log entries will need to be manually adjusted. Timezones are still hard.

Now, let’s look at the service description file itself.

cat /mnt/ewf_mount/etc/systemd/system/cluster.service

That’s interesting! The service starts as the root user (suggesting some privilege escalation) and executes a PHP file. Let’s check that out.

cat /mnt/ewf_mount/usr/local/hadoop/bin/cluster.php

There’s our PHP shell! Binding to port 17001 and executing commands using the shell_exec function.

This is another point that I found the question to be a little unclear. We do have a fake systemd service, but that service calls a PHP shell. It seems that the threat actor had elevated privileges to allow the service creation regardless of whether PHP was installed, so PHP is only really necessary to run the PHP shell. Unfortunately, that answer was incorrect. I guess our PHP shell is just a bind shell rather than specifically a webshell, but nevermind.

We have one attempt left, and we definitely have a fake systemd service, so no harm done.

Flag (Part 2)

create a fake systemd service

That wraps up the Linux analysis challenges! December will focus on Windows memory analysis – specifically the memory image from the 2020 Magnet Virtual Summit CTF which I wrote-up back in June.