Day 19 in the Advent of Cyber 2023. The elves are hard at work inside Santa's Security Operations Centre (SSOC), looking into more information about the insider threat. While analysing the network traffic, Log McBlue discovers some suspicious traffic coming from one of the Linux database servers. Quick to act, Forensic McBlue creates a memory dump of the Linux server along with a Linux profile in order to start the investigation.
WARNING: Spoilers and challenge-answers are provided in the following writeup.
Official walk-through video is as well available at Youtube - MWR CyberSec.
Day 19 - CrypTOYminers Sing Volala-lala-latility
When looking at a machine suspected to be hacked or otherwise used in a way not intended, we can perform forensics to understand what have happened on the machine and device a plan to ensure eradication and bringing it back to full operational function. The first incident responders works with what is called the "level of volatility", focusing on forensics material and evidence that is very volatile - like the content of the memory which is normally stored in RAM not surviving after a reboot on a machine and even when running, often updates and moves. Data like harddisks and alike is much more resilient and can be found later.
So, gathering the memory of a system is important in the earlier stages, and performing forensics on those memory-dumps is a bit different as the content is a direct dump of the memory and thus it is required to know the exact OS and build as they define exactly how the memory layout and data structures are laid out.
The tool Volatility is a python module created for performing such forensics in memory dumps.
The Challenge
We're provided a analyst machine with Volatility 2 pre installed and both the memory capture and a prepared profile. Quickly, for good measure, investigating the linux.mem file provided - we can see that it indeed seems to be a memory-dump from a Linux machine, just like in the last Volatility CTF Writeup.
The first task we're given is to find the password used in a bash history. Checking the bash history is often a very good place to start when looking through a memory dump, as it might reveal what a threat actor have been during. This is done with the command linux_bach in volatility using the correct memory-profile.
We quickly see an exposed password used for getting a root-command prompt on the MySQL DB running on the machine, and we can answer the first question. Though, looking further on the bash history, we can also see that someone has used curl to download something called "toy_miner" and saved it as miner - and just after, running it via ./miner. This is very suspicious.
The next question we're asked is to find the PID of the miner that is running. This is surely connected to the miner that we saw in the bash history. We can utilize the volatility command linux_pslist to get a list of all processes that ran on the machine when the memory dump was taken.
ubuntu@volatility:~/Desktop/Evidence$ vol.py --profile="LinuxUbuntu_5_4_0-163-generic_profilex64" -f linux.mem linux_pslist
Volatility Foundation Volatility Framework 2.6.1
Offset Name Pid PPid Uid Gid DTB Start Time
------------------ -------------------- --------------- --------------- --------------- ------ ------------------ ----------
0xffff9ce9bd5baf00 systemd 1 0 0 0 0x000000007c3ae000 2023-10-02 18:08:02 UTC+0000
0xffff9ce9bd5bc680 kthreadd 2 0 0 0 ------------------ 2023-10-02 18:08:02 UTC+0000
--cropped for brevity--
0xffff9ce9ad115e00 systemd-udevd 10279 387 0 0 0x000000007ba64000 2023-10-02 18:22:36 UTC+0000
0xffff9ce9b1e4c680 miner 10280 1 1000 1000 0x0000000074fa2000 2023-10-02 18:22:37 UTC+0000
0xffff9ce9bc23af00 mysqlserver 10291 1 1000 1000 0x000000006f166000 2023-10-02 18:22:37 UTC+0000Again, here we quickly can see the miner running and the PID of 10280, and by that answering the second question. Though, taking a closer look at the process list, we can see both a mysqld and a mysqlserver. Normally MySQL only have one main process and that is called mysqld, so the other one is again a very suspicious process that we in a "normal" investigation would like to investigate further.
In the next two questions we now need to provide the MD5 hashes of the two suspicious processes running on the system. For this we can use the volatility command linux_procdump to extract the binary of the processes into a newly created directory and then use md5sum to calculate the MD5 hashes for the two files.
For the next question we're asked to use the command strings on the extracted process binary for the miner process we extracted earlier and look for a suspicious URL.
And lastly, we're tasked to answer the location/cronjob the mysqlserver process dropped in on the file system after reading the elfie file. Taking a look at the challenge description we can see that cronjobs are looked for. This is to try and get an understanding and find any places where the treat actor might have been using to get persistens on the machine.
So, we're going to use the volatility command linux_enumerate_files to output files on the system and pipe the output to grep where we can filter just for files with "cron" in the name.
As seen, a file /var/spool/cron/crontabs/elfie is kinda suspicious and the challenge description as well informs that asking the user of the system revealed that they aren't using cronjobs anywhere on this system. So running an extraction of the file via linux_find_file via the files inode and -O to extract the file in the same manner as we did for the processes we now have the file in the extracted directory. Running a quick cat on the file, as we get the answer for the last question in the challenge.
