A Linux server was possibly compromised and a forensic analysis is required in order to understand what really happened. Hard disk dumps and memory snapshots of the machine are provided in order to solve the challenge.
Information
Category Name: Ulysses
Files : c24-Ulysses.zip 449.8 MB
– Debian5_26.zip 354 KB
– victoria-v8.kcore.img 1.1 GB
– victoria-v8.memdump.img 256 MB
– victoria-v8.sda1.img 910 MB
My Recommendations
Download it from CyberDefenders and verify the file with sha1sum:
sha1sum /path/to/c24-Ulysses.zip
SHA1: b53238c60a72d6056dacff51ab041c9688553d07
This is my personal preference, I like being organized and deleting a folder when I’m done with it .
mkdir Documents/CyberDefenders/Ulysses && cd Documents/CyberDefenders/Ulysses
Volatility is all you need to solve this category. Make sure you copy the provided profiles to the volatility path:
vol.py -h
cp Debian5_26.zip /path/to/overlays/linux
If this doesn’t work, then install it following these instructions.
sudo mount victoria-v8.sda1.img /mnt/Linux
Walkthrough
1. The attacker was performing a Brute Force attack. What account triggered the alert?
Honestly, I didn’t really understand what is meant by ‘triggered alert’. In the auth.log (next question), the failed attempts are all for an invalid user named ‘ulysses’.
In the /home directory, there is only one user – pepito. Ulysses doesn’t exist in any of the the /etc/ files.
Answer: ulysses
2. How many were failed attempts there?
We can check auth.log for failed login attempts:
cat /mnt/Linux/var/log/auth.log | grep 'Failed'
There are a lot of failed attempts, we can simplify the count by doing:
cat /mnt/Linux/var/log/auth.log | grep 'Failed' | wc -l
#returns 32
Answer: 32
3. What kind of system runs on the targeted server?
Operating System information can be found in /etc/os-release. However, the file doesn’t exist. That is because the system must be quite old. We need to look into /etc/issue instead:
cat /mnt/Linux/etc/issue
Answer: Debian GNU/Linux 5.0
4. What is the victim's IP address?
Since the targeted server runs Linux Debian, we can check the existing dhclient leases:
cat /mnt/Linux/var/lib/dhcp3/dhclient.eth0.leases | grep 'fixed-address'
Given that this is the only address, we can assume it’s the victim’s. We can also check the dhclient logs in syslog.
grep dhclient /mnt/Linux/var/log/syslog
Since we know the bruteforce attack was run on February 6th, the dhclient was bound to 192.168.56.102, the same adddress from the leases.
Answer: 192.168.56.102
5. What are the attacker's two IP addresses?
In Question two, we found that there were 32 invalid login attempts, all from the same IP address: 192.168.56.1. To find what other logs are associated with this IP address, we can do a quick search:
sudo grep -r -F -l '192.168.56.1' /mnt/Linux/var/log
Of the two files returned, rejectlog and mainlog at /var/log/exim4 are quite sus.
cat /mnt/Linux/var/log/exim4/rejectlog
Its content is endless, but it gives us an overview of what the attack entails. It’s a buffer overflow on the exim4 service. The attack is delivered through mail headers. This is a (partial) excerpt of the log:
All the rejected logs are associated with IP address 192.168.56.101. And all the rejected messages are because of the message being too big.
We can also check for these addresses in the memory dump:
vol.py --profile=LinuxDebian5_26x86 -f victoria-v8.memdump.img linux_netstat
As we can see, connections were established between the victim and these two IP addresses.
Answer: 192.168.56.1,192.168.56.101
6. What is the "nc" service PID number that was running on the server?
Using the linux_pslist plugin:
vol.py --profile=LinuxDebian5_26x86 -f victoria-v8.memdump.img linux_pslist
nc (PID 2169) is the last process returned by the plugin, and its parent process is Bash (PID 2042).
Answer: 2169
7. What service was exploited to gain access to the system?
(one word)
The Exim4 log files showed that the attack was a heap buffer overflow that is delivered through headers. We can check the memory dump to see if more information can be found.
Using the linux_bash plugin:
vol.py --profile=LinuxDebian5_26x86 -f victoria-v8.memdump.img linux_bash
Although the timestamp appears to be ?wrong, there is clear evidence of exim4 being exploited.
Answer: Exim4
9. During this attack, the attacker downloaded two files to the server.
Provide the name of the compressed file.
Again, in the rejectlog file, there are many ‘wget’ commands being passed. The last message contains a wget command for file ‘rk.tar’:
We can look into the memory dump and the disk to see if it was actually downloaded:
vol.py --profile=LinuxDebian5_26x86 -f victoria-v8.memdump.img linux_enumerate_files
The files were downloaded into the /tmp directory:
We can check the tmp directory of the mounted image:
ls -lah /mnt/Linux/tmp
And it’s there!
Answer: rk.tar
10. Two ports were involved in the process of data exfiltration.
Provide the port number of the highest one.
In the linux_netstat’s plugin output, we saw that the connections established were to port 4444 and 8888.
The linux_bash plugin demonstrates that these ports were involved in exfiltrating data:
vol.py --profile=LinuxDebian5_26x86 -f victoria-v8.memdump.img linux_bash
The attacker dd’d the disk and transfered it over netcat.
Answer: 8888
11. Which port did the attacker try to block on the firewall?
Provide the port number of the highest one.
First of all, it’s worth noting that rk.tar is flagged by virus total as a Linux Rootkit – Backdoor Agent. There is also a reddit thread discussing the dropped file. We can see the contents of the archive with tar:
sudo tar -tvf /mnt/Linux/tmp/rk.tar
We can extract the .sh files to look at the variables set:
sudo tar -xvf /mnt/Linux/tmp/rk.tar 'rk/install.sh'
sudo tar -xvf /mnt/Linux/tmp/rk.tar 'rk/vars.sh'
sudo cat rk/*.sh
The file vars.sh contains the line ‘rk_port=44965’.
In the install.sh file, all the configurations try to block port 45295 with the same line of code:
Answer: 45295
TLDR
– Ulysses is a Linux Forensics Challenge with both a disk image and a memory dump as evidence files.
– The attacker brute-forced SSH, and compromised the system through an exim4 buffer overflow.
– Data was exfiltrated over NetCat.
