You have been called to analyze a compromised Linux web server. Figure out how the threat actor gained access, what modifications were applied to the system, and what persistent techniques were utilized. (e.g. backdoors, users, sessions, etc).
Information
Category Name: Hacked
Files:Â c53-Hacked.zip 1.1 GB
–> Contains Webserver.E01 1.1GB
My Recommendations
This is my personal preference, I like being organized and deleting a folder when I’m done with it.
mkdir Documents/CyberDefenders/Hacked && cd Documents/CyberDefenders/HackedDownload it from the Cyber Defenders and verify the file with sha1sum:
sha1sum /path/to/c53-Hacked.zipSHA1: 28a0faa275dcb36d7a65bef0f3f8e61b396f8c86.
Then extract it with the provided the password
sudo ewfmount Webserver.E01 /mnt/ewf sudo losetup -r -o 256901120 /dev/loop26 /mnt/ewf/ewf1 sudo mount -o ro,noload /dev/VulnOSv2-vg/root /mnt/Linux
Walkthrough
1. What is the system timezone?
We can find this information in the etc/timezone file:
cat /mnt/Linux/etc/timezone
Answer: Europe/Brussels
2. Who was the last user to log in to the system?
We can check the authentication log, and look at the last record:
cat /mnt/Linux/var/log/auth.log | grep -F 'Accepted password'
The last user to log in was mail.
Answer: mail
3. What was the source port the user 'mail' connected from?
From the authentication log above, mail connected from port 57708.
Answer: 57708
4. How long was the last session for user 'mail'? (Minutes only)
We can grep for the exact string of mail’s last login and look at the following lines:
cat /mnt/Linux/var/log/auth.log | grep -F 'Accepted password for mail from 192.168.210.131 port 57708 ssh2' -A 20
The session openned at 13:23:34 and closed at 13:24:11. The session time was technically less than a minute, but the answer is one.
Answer: 1
5. Which server service did the last user use to log in to the system?
The logs indicate that sshd was used to log in to the system.
Answer: sshd
Â
6. What type of authentication attack was performed against the target machine?
We can check for a bruteforce attack by looking at the number of Failed attempts.
cat /mnt/Linux/var/log/auth.log | grep -F 'Failed password'
There are 451 failed attempts starting from October 5th. All these attempts have a very small lag time. It confirms that it was a bruteforce attack.
Answer: bruteforce
7. How many IP addresses are listed in the '/var/log/lastlog' file?
We can check the file and format it properly with grep and strings:
strings /mnt/Linux/var/log/lastlog | grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" | sort | uniq
Answer: 2
8. How many users have a login shell?
We can check the contents of /etc/passwd and look for bash, which indicates a login shell:
cat /mnt/Linux/etc/passwd | grep bash
Answer: 5
9. What is the password of the mail user?
To crack the mail users’ hash, we need to:
– unshadow the shadow and passwd file
– save mail‘s hash
– crack it with John The Ripper
sudo unshadow /mnt/Linux/etc/passwd /mnt/Linux/etc/shadow > unshadowed
grep 'mail' unshadowed > mail_hash
john --wordlist=/usr/share/wordlists/rockyou.txt mail_hash
Mail’s password is forensics.
Answer: forensics
10. Which user account was created by the attacker?
To find evidence of user accounts creation, we need to check the auth.log for the service useradd:
cat /mnt/Linux/var/log/auth.log | grep useradd
Given that the bruteforce attack started on October 5th, we can ignore the previous logs. The attacker created and added the user php to sudoers.
Answer: php
11. How many user groups exist on the machine?
This is a straightforward process, just need to count the lines of the /etc/group file:
sudo cat /mnt/Linux/etc/group | wc -l
#returns 58
Answer: 58
12. How many users have sudo access?
The users with sudo access should be listed in the /etc/group file:
cat /mnt/Linux/etc/group | grep sudo
The victim user account and the attacker-created user account both have sudo access.
Answer: 2
13. What is the home directory of the PHP user?
When the attacker created the user PHP, its home directory was assigned to /usr/php (see figure in Question 10).
Answer: /usr/phpÂ
14. What command did the attacker use to gain root privilege? (Answer contains two spaces).
Mail’s bash_history, shows several ‘sudo su – ‘ commands being executed:
Answer: sudo su –
15. Which file did the user 'root' delete?
We can check root’s bash history and grep for the command ‘rm’:
sudo cat /mnt/Linux/root/.bash_history | grep 'rm'
#returns rm 37292.c
Answer: 37292.c
16. Recover the deleted file, open it and extract the exploit author name.
I wasn’t able to recover the file, however the exploit is on github. The author name is rebel.
Answer: rebelÂ
17. What is the content management system (CMS) installed on the machine?
Listing the /etc/ directory, there is a folder named drupal:
ls -la /mnt/Linux/etc
Drupal is a popular open-source CMS.
Answer: drupal
18. What is the version of the CMS installed on the machine?
We can find the version currently running and installed in the /var/log/dpkg.log file:
cat /mnt/Linux/var/log/dpkg.log | grep drupal
Answer: 7.26
19. Which port was listening to receive the attacker's reverse shell?
In the /var/log/auth.log file we identified a bruteforce attack. All connections were being made from IP address 192.168.210.131. We can search the filesystem for the IP address:
sudo grep -r -s -l -F '192.168.210.131' /mnt/Linux
The auth.log, lastlog, btmp and wtmp files are system logs, in that they record logins/logouts, boot times etc of the machine. They are unlikely to contain relevant information.
The ibdata1 and ib_logfile0 are relevant, but their filetype is mysql dependent, meaning not the easiest to read/parse.
Our best option is to check the apache2 logs:
sudo cat /mnt/Linux/var/log/apache2/*.log | grep -F '192.168.210.131'
And there we have it! A super suspicious base64 encoded POST method.
We can decoded directly in bash:
echo -n '#base64encoded string' | base64 -d
Bash has a little issue decoding it fully, but we can clearly see that the IP is the attacker’s and the listening port is 4444 – the default listening port of Metasploit.
Answer: 4444
TLDR
– Linux Forensics Challenge focusing on a PHP injection on a Linux Web Server.
