You belong to a company specializing in hosting web applications through KVM-based Virtual Machines. Over the weekend, one VM went down, and the site administrators fear this might be the result of malicious activity. They extracted a few logs from the environment in hopes that you might be able to determine what happened.
This challenge is a combination of several entry to intermediate-level tasks of increasing difficulty focusing on authentication, information hiding, and cryptography. Participants will benefit from entry-level knowledge in these fields, as well as knowledge of general Linux operations, kernel modules, a scripting language, and reverse engineering. Not everything may be as it seems. Innocuous files may turn out to be malicious so take precautions when dealing with any files from this challenge.
Download it from CyberDefenders and verify it with:
sha1sum /path/to/c23-EscapeRoom.zip
SHA1SUM: 4dd5e257c4bef0f950a37bb1e401f3dd990929bf
Walkthrough
1. What service did the attacker use to gain access to the system?
With a simple glance at the pcap, the first part consists mostly of ssh protocol. Then, it switches to http. To have a closer look, we can look into Protocol Hierarchy:
It makes most sense for the attacker to have used SSH to gain access to the system.
Answer:Â SSH
2. What attack type was used to gain access to the system?
If we filter the pcap with ssh, and then look at the Conversations with that filter there is clear evidence that a bruteforce attack was used:
In the Screenshot above, the duration is very short, and has an approximate lag of 1.5 to 3 seconds. There is other evidence pointing to a bruteforce attack.
Answer: bruteforce
3. What was the tool the attacker possibly used to perform this attack?
The most common tool for bruteforcing SSH is Hydra. Given that the capture contains patterns similar to how hydra operates, it is likely to be behind the attack.
Answer: hydra
4. How many failed attempts were there?
In the Statistics -> Conversations, there are 54 packets. For a successful connection, the duration would be larger than the others. Sorting Duration by Descending order shows an outlier in the results:
The duration, number of Bytes Sent and Received is much larger than the others.
Another pattern occurring in the majority of the packets is that the total number of packets is 13 and total bytes is around 3782. If we sort by Packet count in Descending order, we will see that there is another outlier (both annotated in pink):
The connection time being very low, could mean a successful bruteforce attempt without actually connecting/interacting with the machine.
Answer: 52
5. What credentials (username:password) were used to gain access?
Refer to shadow.log and sudoers.log.
First, we can check the sudoers.log file to see which users have root privileges on the machine:
Next, we can extract the hashes of these users and bruteforce the hash with John The Ripper:
egrep 'root|guest|manager|sean|roger|pierce' shadow.log > hashes
john --wordlist=/usr/share/wordlists/rockyou.txt hashes
Only two hashes were cracked:
Â
Answer:Â manager:forgot
6. What other credentials (username:password) could have been used to gain access also have SUDO privileges?
Refer to shadow.log and sudoers.log.
The only other hashes cracked were for the user sean.
Answer: sean:spectre
7. What is the tool used to download malicious files on the system?
From Protocol Hierarchy, we saw that the protocols of the pcap are mainly http and ssh. The malware was most likely downloaded over http. We can filter the pcap with http.user_agent:
All the packets returned have the User-agent wget. Alternatively, we can use strings:
strings hp_challenge.pcap | grep 'User-Agent'
Answer: wget
8. How many files the attacker download to perform malware installation?
To see the files that were downloaded, we can check File –> Export Objects–> HTTP:
There are 12 files in total. We can save them all to a new directory ‘malware’ to further our analysis.
cd malware
file *
File 1, 2 and 3 are exectuables. The rest of the files are BMP images with different contents.
Here is a preview of the bmp-files:
On top of that, file 1, 2 and 3 were downloaded first, so they must have been used for installation.
Answer: 3
9. What is the main malware MD5 hash?
In the output of the file command, we saw that
– file 1 is a statically linked executable
– file 2 is a relocatable ELF
– file 3 is a shell script
A relocatable ELF is not linked yet, thus it cannot be executed. File 1 is the main malware.
10. What file has the script modified so the malware will start upon reboot?
We can see the contents of the script with cat:
cat 3
Â
On the 5th line, the script overwrote the file /etc/rc.local to execute the malware and print the kernel message to standard output.
Â
Answer: /etc/rc.local
Â
11. Where did the malware keep local files?
The malware was renamed as ‘mail’ in the /var/mail directory.
Answer: /var/mail
12. What is missing from ps.log?
If we look at ps.log, there is no record of mail, aka the malware.
Answer: /var/mail/mailÂ
13. What is the main file that used to remove this information from ps.log?
Looking at the bash script, file 2 was renamed to sysmod.ko. File 2 is the relocatable of the main malware.
Then, the command depmod -a was used to generate a list of the dependency for all modules. Sysmod was added to the /etc/modules file, meaning the malware would load at boot time. Finally, sysmod was added to the Linux Kernel.
These steps are synonymous to how Linux Rootkits operate. The file in that enabled hiding the process is sysmod.ko.
Answer: sysmod.ko
14. Inside the Main function, what is the function that causes requests to those servers?
The malware is UPX packed, we need to unpack it before analyzing it:
upx -d 1
r2 1
#in radare2 shell:
aaaa
pdf @main
The main function shows a reference to the IP address of the server, and then calls the function requestFile which is used to download the files.
Answer: requestFile
15. One of the IP's the malware contacted starts with 17. Provide the full IP.
Looking at the files downloaded over HTTP, two of those were from Host 174.129.57.253:
Â
Answer: 174.129.57.253
16. How many files the malware requested from external servers?
In total, 12 files were Downloaded over HTTP. Three of those were the initial malware, the rest were from external servers:
Answer: 9
17. What are the commands that the malware was receiving from attacker servers?
Format: comma-separated in alphabetical order
Â
In Radare2, we saw that the malware takes an optional argument. To process that argument, we can look for the instruction cmp which would compare the argument given.
#Inside radare2 shell
/ac cmp eax
There are three potential hex strings that could have been matched. Converting them from hex in CyberChef:
The first one is not a string, but the other two are NOP and RUN. These two instructions are located in the DecryptMessage and ProcessMessage functions.
