A Linux server was possibly compromised and a forensic analysis is required in order to understand what really happened. Memory snapshots of the machine are provided in order to solve the challenge.
Information
Category Name: Seized
Files : c73-EZDump.zip 162MB
– dump.mem 1GB
– Centos7.3.10.1062.zip 925KB
My Recommendations
This is my personal preference, I like being organized and deleting a folder when I’m done with it .
mkdir Documents/CyberDefenders/Seized && cd Documents/CyberDefenders/Seized
Download it from CyberDefenders and verify the file with sha1sum:
sha1sum /path/to/c73-EZDump.zip
SHA1: a2c209bb3c221bc70f3418e079e2a22db3cebc53
The zip archive includes the volatility profile for the memory dump.
sudo cp Centos7.3.10.1062.zip /path/to/volatility/plugins/overlays/linux/
Walkthrough
1. What is the CentOS version installed on the machine?
We are given the CentOS profile, which is 7.3.10-1062. On Wikipedia, the versions associated with the corresponding kernels are displayed in the table below:
The CentOS version installed on the machine is 7.7-1908.
Answer: 7.7-1908
2. There is a command containing a strange message in the bash history. Will you be able to read it?
Using the linux_bash plugin:
vol.py -f dump.mem --profile=LinuxCentos7_3_10_1062x64 linux_bash
The bash history shows a command appending a base64 encoded string to a file named ‘y0ush0uldr34dth1s.txt’. We can decode it directly:
echo 'c2hrQ1RGe2wzdHNfc3Q0cnRfdGgzXzFudjNzdF83NWNjNTU0NzZmM2RmZTE2MjlhYzYwfQo=' | base64 -d
#returns shkCTF{l3ts_st4rt_th3_1nv3st_75cc55476f3dfe1629ac60}
Answer: shkCTF{l3ts_st4rt_th3_1nv3st_75cc55476f3dfe1629ac60}
3. What is the PID of the suspicious process?
Using the linux_psaux plugin:
vol.py -f dump.mem --profile=LinuxCentos7_3_10_1062x64 linux_psaux
Looking at the last lines of the output, there are some suspicious things happening:
As we can see, netcat is used to issue a reverse shell, which is then spanwed using python. The PID of netcat is 2854.
Answer: 2854
4. The attacker downloaded a backdoor to gain persistence. What is the hidden message in this backdoor?
In the bash history, a repository called PythonBackup was downloaded and executed. There is no information/description about it, so perhaps more information can be found in the source code. We can download it and examine it:
git clone https://github.com/tw0phi/PythonBackup && cd PythonBackup
cat PythonBackup.py
Looking into the code at app/snapshot.py, the function generateSnapshot downloads a text from pastebin:
We can examine its contents by downloading it to our VM:
curl https://pastebin.com/raw/nQwMKjtZ
Now, all we need to do is decode the base64 encoded string.
Answer: shkCTF{th4t_w4s_4_dumb_b4ckd00r_86033c19e3f39315c00dca}
5. What are the IP address and the port used by the attacker?
Previously, we saw that the attacker issued a reverse shell listening on port 12345. We can use the linux_netstat plugin to see which connections were made to that port:
vol.py -f dump.mem --profile=LinuxCentos7_3_10_1062x64 linux_netstat | grep 12345
To confirm our findings, we can use the plugin linux_bash_env, which will provide additional information about the IP Addresses in use:
vol.py -f dump.mem --profile=LinuxCentos7_3_10_1062x64 linux_bash_env
Pid 2887, the PID from which the reverse shell is spawned from shows that the NCAT Remote Address is 192.168.49.1:
Answer: 192.168.49.1
6. What is the first command that the attacker executed?
As we previously saw, the attacker spawned a bash shell when gaining access to the system:
Answer: python -c import pty; pty.spawn(“/bin/bash”)
7. After changing the user password, we found that the attacker still has access. Can you find out how?
As we saw in bash history, the attacker edited rc.local. Unfortuntaly, it is not possible to dump the file. However, we can dump the memory of PID 2887 to see how it may have been edited.
As opposed to a Windows memory dump, we need to dump memory pages individually:
mkdir 2887
vol.py -f dump.mem --profile=LinuxCentos7_3_10_1062x64 linux_dump_map --pid 2887 -D 2887/
Once that’s done, we can use the command strings on the dumped pages and concatenate them to a single file, which will make it easier to search. Considering the attacker is issuing remote commands, we can look for the string ‘echo’:
strings 2887/* > 2887/strings.txt
cat 2887/strings.txt | grep echo -B 5 -A 5
Right above the command that edits the authorized ssh keys, there is a base64 encoded string referenced as ‘played: ‘:
We can decode it bash:
echo 'c2hrQ1RGe3JjLmwwYzRsXzFzX2Z1bm55X2JlMjQ3MmNmYWVlZDQ2N2VjOWNhYjViNWEzOGU1ZmEwfQo=' | base64 -d
#returns shkCTF{rc.l0c4l_1s_funny_be2472cfaeed467ec9cab5b5a38e5fa0}
Answer: shkCTF{rc.l0c4l_1s_funny_be2472cfaeed467ec9cab5b5a38e5fa0}
8. What is the name of the rootkit that the attacker used?
Given that the rootkit has established backdoors using rc.local, we can safely assume that logging/evidence can be found in the dmesg process. We can use the linux_dmesg plugin to find potential evidence:
vol.py -f dump.mem --profile=LinuxCentos7_3_10_1062x64 linux_dmesg
On the last lines of the output, we can see a reference to CRC65 encryption, which is mentioned in the next question. The modules called is sysemptyrect. We can double check its existence in the filesystem:
vol.py -f dump.mem --profile=LinuxCentos7_3_10_1062x64 linux_enumerate_files > files.txt
cat files.txt | grep sysemptyrect
And in the memory dump as a whole:
strings dump.mem | grep -i 'sysemptyrect' -B 5 -A 5
Here we can see that the insert module command is executed on the kernel, with the crc65 key.
Answer: sysemptyrect
9. The rootkit uses crc65 encryption. What is the key?
If we ignore the previous findings, the key could still be find with basic grep on PID 2887’s memory pages:
cat 2887/strings.txt | grep -i crc65
As we can see, the output shows a crc65 key, however its value isn’t complete. We can instead find the full key by looking for the partial string:
cat 2887/strings.txt | grep 1337tibbartibb -B 5 -A 5
The last line, showing the string between two quotes confirms that the full key is 1337tibbartibbar.
Answer: 1337tibbartibbar
TLDR
– A Linux Memory Forensics challenge of an infected server.
– Volatility2 is the best tool to answer the questions.
