TL;DR: Week 8 of the #MagnetWeeklyCTF started down the side quest I was hoping to dig into, but only scratched the surface of my itch.
Check out the week 1 blog post for how to get started on the Magnet Weekly CTF.
Get the first challenge
The weekly challenge for week 8 was split into two, short parts. The first was:
What package(s) were installed by the threat actor? Select the most correct answer!
This goes back to the questions in week 6 dealing with how and where Ubuntu records actions related to package installation, so we can start with that knowledge.
Open the target file(s)
We already looked at the log files are in
/var/log/apt/, but before we can know which the threat actor installed, we need to know when the threat actor was active. During week 6 I saw two interesting1 binaries in
/home/hadoop and thought they, plus bash history, might give us the right clues. Using
ls -al we can get an approximate date for the binary. Then as we examine the
/home/hadoop/.bash_history, we can use
wc -l to tell us how big the file is and determine the next steps. Since it is 374 lines long, and because I’m assuming the response team was quick, I opted to look at the last 25 lines with
tail -n 25 first to see if that would work quicker. If not, we could always expand the
tail we look at.
From these steps we see that the intersting binary was modified around October 6 2019, that
/home/hadoop/.bash_history is 374 lines, and that in the last 25 lines, someone executed this binary (
./45010) a few times. Why would you run something a few times? I normally do that when I forget to install something it requires or fail to set up the environment variables correctly. We see the user run the binary, then looked at
ll (this is generally
ls -l), then copied the same binary over to the other to nodes with
scp. Seems like it is likely the threat actor, so now we have a better starting point of the time to check, even though
.bash_history doesn’t store timestamps.
Check the logs
Going back to our log files, I also started with
tail since it seemed that these acts were some of the last potential actions on the server.
Sure enough, the last entry in
/var/log/apt/history.log is from October 7 2019, but early morning, which seems like it is just the timezone offset for my local computer. In that case, the command that was run was
apt install php, although a lot of packages were installed as a result. Because Magnet is looking for the “most correct answer”, they wanted “php” as the actual package installed by the actor, not caring about the slew of packages that underpinned it.
Get the Second Challenge
The second weekly challenge was:
- hosting a database
- serving a webpage
- to run a php webshell
- create a fake systemd service
To answer this question, I first recalled that the
/home/hadoop/.bash_history had the threat actor checking out a PHP file located at
/usr/local/hadoop/bin/cluster.php. Looking at that file with
cat gave an incorrect answer because I read it too quickly.
I read the file, saw
shell_exec and immedaitely answered “to run a php webshell” in haste, as if the wrong answer given quickly will be worth more points. When that failed, I went back to actually thinking about the question and what I was presented with.
This can’t be “hosting a database” because PHP on its own doesn’t provide a database. It could be “serving a webpage”, depending on how strictly we want to say “serving” and I thought I might want to poke around to see if something else was hidden away. But first I opted to check the systemd services folder to see if that would give a quicker answer to rule out the final possibility.
Inside this folder, we see a service was created on Octber 6 2019, seems like it might be the answer given the overlap with the threat actor’s activities. Looking at that service itself, it is trying to run our target PHP file.
This makes it clear that PHP was needed to execute their PHP file and listen for incoming instructions as root. Therefore the answer is “create a fake systemd service”.
grep to find all the packages generally installed by the user and not something automated, you could try this:
Since we had already seen why Java was installed, this would lead to the correct answer of PHP. An alternative for the second question is simply looking at what is presented and being honest about what is possible, instead of jumping to conclusions, since a webshell isn’t a webshell without the web, PHP doesn’t run databases, and it can’t serve a webpage without an actual web server.
I had really hoped to explore this malware more, but this taste of the side quest will have to do. One very important lesson in all of this is that you should never, ever, run code found in CTF images. Many players did to solve week 5 of the CTF and in doing so they potentially could have compromised their own machine, depending on what they ran. More on this in a future post.