This challenge takes you into the world of virtual systems and confusing log data. In this challenge, figure out what happened to this webserver honeypot using the logs from a possibly compromised server.
Information
Category Name: Hammered
Files : c26-Hammered.zip 966 KB
My Recommendations
Download it from CyberDefenders and verify the file with sha1sum:
sha1sum /path/to/c26-Hammered.zip
SHA1: c5282824e485cbafe4b13a942759fd6720433929
This is my personal preference, I like being organized and deleting a folder when I’m done with it .
mkdir Documents/CyberDefenders/Hammered && cd Documents/CyberDefenders/Hammered
Walkthrough
1. Which service did the attackers use to gain access to the system?
The file auth.log is unsually large, its size is 9.9 MB. Grepping for ‘Failed’ shows that ssh was being bruteforced:
cat auth.log | grep -F 'Failed'
Answer: ssh
2. What is the operating system version of the targeted system?
We can check the dmesg log. Usually, the first few lines will contain the operating system version:
cat dmesg | head -n 10
Answer: 4.2.4-1ubuntu3
3. What is the name of the compromised account?
We can look into auth.log to see which account was successfully accessed:
cat auth.log | grep -F 'Accepted password'
On April 19th there is a connection to the root account. Looking at the logs preceding April 19th, there is no evidence of bruteforce attempts.
Root was the compromised account.
Answer: root
4. Consider that each unique IP represents a different attacker. How many attackers were able to get access to the system?
This is quite a complicated to figure out.
Given that ssh was being bruteforced, we need to filter out the auth.log for IP addresses by occurrence:
cat auth.log | grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" | sort | uniq -c > authips
Once that’s done, we need to filter out the IP Addresses that successfully accessed the system as root (the compromised account):
grep -F 'Accepted password for root' auth.log | grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" | sort | uniq > rootips
Now, we have a list of IPs that managed to access the system, and the occurrence of each IP in the system. We can use grep to see which IPs are matched:
grep -f rootips authips
The difference between the occurrences is large. We can conclude that six attackers managed to access the system.
Answer: 6
5. Which attacker's IP address successfully logged into the system the most number of times?
We need to apply the same logic as the previous question. Find the number of time each IP addresses successfully logged in, and then compare with the list of attackers.
grep -F 'Accepted password for root' auth.log | grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" | sort | uniq -c
The two IP addresses with the highest occurrences are 188.131.23.37 and 219.150.161.20. The first one appears only six times overall in auth.log, whereas the second appears 26097 times.
Answer: 219.150.161.20
6. How many requests were sent to the Apache Server?
The requests are logged in apache2/www-access.log. In the file, there are three types of requests sent: GET, CONNECT and POST. We can easily find the total number of requests with wc:
wc -l apache2/www-access.log
#returns 365
Answer: 365
How many rules have been added to the firewall?
Looking again in auth.log:
cat auth.log | grep iptables
The commands succeed with -A mean rules have been added. In total, there are six rules that have been added.
Answer: 6
8. One of the downloaded files to the target system is a scanning tool. Provide the tool name.
To look at files that were downloaded and installed, we need to look into the dpkg.log file. An easy way to filter out for filenames is to grep for configure:
cat dpkg.log | grep -F 'configure '
Answer: nmap
9. When was the last login from the attacker with IP 219.150.161.20?
Looking into auth.log for successful login attempts by this IP addess:
cat auth.log | grep -F 'Accepted password' | grep -F '219.150.161.20'
Answer: 04/19/2010 05:56:05 AM
10. The database displayed two warning messages, provide the most important and dangerous one.
Warning messages are formatted as WARNING in Linux logs.
grep -r WARNING *
The two messages in regards to a ‘database’ (mysql) are ‘mysql.user contains 2 root accounts without password!‘ and ‘mysqlcheck has found corrupt tables‘.
The more dangerous one is the first one. Mysql creates root users without passwords for each database upon creation. Unless the user assigns a password to these users, their passwords will always be empty.
Answer: mysql.user contains 2 root accounts without password!
11. Multiple accounts were created on the target system.
Which one was created on Apr 26 04:43:15?
Looking into auth.log:
cat auth.log | grep -F 'Apr 26 04:43:15'
Answer: wind3str0y
12. Few attackers were using a proxy to run their scans. What is the corresponding user-agent used by this proxy?
We need to filter the apache access log for the User-Agents.
Here’s a simple one liner to grep for User-agents in Apache’s access log:
cat apache2/www-access.log | sed 's/^.* "-" "//g' | sed 's/" .*//g' | sed '/HTTP/d' | sort | uniq
The only suspicious one is pxyscand, which is a Network proxy scanner.
Answer: pxyscand/2.1
TLDR
– The compromised webserver was exploited first over a brute-force SSH attack.
– Several files were downloaded, and the firewall‘s rules were edited.
– Most importantly, the attack happened because some of SQL‘s accounts’ root password was not set.
