Digital Forensics Write-up — Web Server Case by Ali Hadi

The article is a write-up for challenge number one — the Web Server Case — by Ali Hadi on his blog, ‘ashemery.com’. The premise is set to:

A company’s web server has been breached through their website.

Questions

For this investigation, we’re asked to answer the following questions:

1. What type of attacks has 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 shell code 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?

Tool-set

For the purpose of this write-up, I’m going to utilize the following set of tools:

1. AccessData FTK Imager
2. Autopsy (I prefer this for analysis)
3. Registry Explorer by Eric Zimmerman
4. Volatility
5. Mft2Csv
6. LogFileParser

Let’s Seek Some Solutions!

Focusing on the premise again — we know the box served as a server. Let’s analyze the system image in FTK Imager to see the filesystem and identify whether it’s a Windows or Linux-based machine.

NTFS formatted filesystem with Windows

Observe the ‘xampp’ folder at the bottom — this indicates the installation of XAMPP, a web-server solution pack, likely based on the LAMP stack. Let’s dig into the server’s folder and hunt for Apache logs.

Generally, on Windows-based Apache installations, you can find the location of the access or error logs at: [the location of the ‘xampp’ folder might differ on your web-server]

C:\xampp\apache\logs

Apache Logs

Let’s export these to the forensics workstation and see if we can dig into them for more insight into the attack. Exploring the install.log file, we can figure out the following information from it:

Installing Apache HTTP Server 2.x with
DomainName = example.com
ServerName = www.example.com
ServerAdmin = admin@example.com
ServerPort = 80
ServerSslPort = 443
ServerRoot = c:/Apache24

The web server is running on standard HTTP/HTTPS ports of 80/443.

The holy grail here is the access.log file. First thing’s first, let’s get a headcount of the total IP addresses which tried communicating with the server:

cat access.log | awk '{print $1}' | sort | uniq -c | sort -nr

IP addresses communicating with the server

In this dataset, the general outlier, 192.168.56.102, appears to be the most in touch with the server. Let’s grep the logs containing this IP address from the log file into a separate file to reduce the noise: (I’ve also separately analyzed logs from other IP addresses but they appear to be harmless. During an investigation, you might want to poke every bit of evidence for intelligible leads.)

 grep "192.168.56.102" access.log >> 192-168-56-102-access_log.log

Next, let’s check the user-agent field in these logs to see if we can get something useful:

cat 192-168-56-102-access_log.log | awk -F\" {print $6} | sort | uniq -c | sort -nr

Usage of SQLMAP

Judging my the top user-agent, it’s clear that the attackers used sqlmap, an automated tool to detect SQL injection in websites. Using that, we can map the Initial Access tactic to:

Exploit Public-Facing Application (T1190)

Since the rest of the user-agents seem pretty generic, I’ll pivot to the logs with the sqlmap useragent. After separating them from the main log file, we have an even smaller dataset to work on. By exploring the URI field in these logs, we can clearly see the injection attempts:

SQL Injection attempts

A file being sent over exploiting SQL injection vulnerabilities — /tmpukudk.php

If we run a scan on the access logs against ‘tmp’, we can retrieve more such files being referenced in the logs:

Four tmp files being created and then deleted via the command prompt

However, these files appear to have been deleted and you can verify that by checking the forensics image provided. Well, we’ll explore recovering them later.

Apart from that, the access logs also show attempts to exploit XSS vulnerabilities:

XSS Vulnerabilities

and unrestricted file upload vulnerabilities:

Unrestricted file upload vulnerabilities shows PHP based web shells

Commands executed

Proof the commands were executed by the attacker

Local File Inclusion

‘exec’ endpoint — POST requests show the attacker must’ve sent some input here

Sadly, we can’t see the data sent with POST requests in the access logs. We’ll get back to exploring this again — hopefully with the help of the memory sample.

Lastly, we see the attacker appears to have launched a command prompt window using the command cmd from the web-shell:

“cmd” spawned using the webshell

For better time-lining — let’s note the timestamp as well: 03/Sep/2015:00:21:37 -0700.

The windows event logging service was running at the bare minimum and has no logs. Therefore, it’s time to pivot to a different evidence source — most likely the memory image acquired. We’ll come back to the forensic image later.

Using Volatility, let’s retrieve more information about the memory image and the profile required using:

volatility -f memdump.mem imageinfo
...
 Suggested Profile(s) : VistaSP1x86, Win2008SP1x86, Win2008SP2x86
 Number of Processors : 1
 Image Type (Service Pack) : 1
 Image date and time : 2015–09–03 10:04:05 UTC+0000
 Image local date and time : 2015–09–03 03:04:05 -0700
...

Using the VistaSP1x86 profile, let’s start off with the processes:

volatility -f memdump.mem --profile=VistaSP1x86 pslist
volatility -f memdump.mem --profile=VistaSP1x86 psscan
volatility -f memdump.mem --profile=VistaSP1x86 pstree

‘cmd.exe’ processes under explorer.exe

Based on the output of the process scans, no malicious binary appears to be running on the system right now. Since we have two command prompt windows open [PID: 612, 1972], let’s explore them a bit more.

. 0x83e7b7f8:cmd.exe 612 816 1 72 2015–08–23 10:30:44 UTC+0000
. 0x84259100:cmd.exe 1972 816 1 19 2015–09–02 09:28:30 UTC+0000

Though you should note the dates for execution of the two consoles. The one on 23–08–2015 isn’t relevant to our case as the actual execution under the webshell was carried out on 03/Sep/2015:00:21:37 -0700 [UTC and GMT times are different here]. Let’s exclude the console window with the PID 612 from our analysis.

Let’s run scans for consoles, command prompt arguments, or command history:

volatility -f memdump.mem --profile=VistaSP1x86 cmdline
volatility -f memdump.mem --profile=VistaSP1x86 consoles
volatility -f memdump.mem --profile=VistaSP1x86 cmdscan

Here, ‘cmdline’ simply returns the command-line arguments for each process. ‘consoles’ and ‘cmdscan’ both return command history by scanning different structures. Once you run this, you’ll come across several commands the attacker tried to execute. If you’d like an output-less view of the commands, run “cmdscan”.

CommandProcess: csrss.exe Pid: 524
CommandHistory: 0x5a24708 Application: cmd.exe Flags: Allocated, Reset
CommandCount: 17 LastAdded: 16 LastDisplayed: 16
FirstCommand: 0 CommandCountMax: 50
ProcessHandle: 0x2d8
Cmd #0 @ 0xe907c8: ipconfig
Cmd #1 @ 0xe91af8: cls
Cmd #2 @ 0xe91db0: ipconfig
Cmd #3 @ 0x5a34bd0: net user user1 user1 /add
Cmd #4 @ 0x5a34eb8: net user user1 root@psut /add
Cmd #5 @ 0x5a34c10: net user user1 Root@psut /add
Cmd #6 @ 0x5a24800: cls
Cmd #7 @ 0x5a34c58: net /?
Cmd #8 @ 0x5a34d88: net localgroup /?
Cmd #9 @ 0x5a34f48: net localgroup “Remote Desktop Users” user1 /add
Cmd #10 @ 0x5a34c70: net /?
Cmd #11 @ 0xe911b0: netsh /?
Cmd #12 @ 0xe907e8: netsh firewall /?
Cmd #13 @ 0xe91218: netsh firewall set service type = remotedesktop /?
Cmd #14 @ 0xe91288: netsh firewall set service type = remotedesktop enable
Cmd #15 @ 0xe91300: netsh firewall set service type=remotedesktop mode=enable
Cmd #16 @ 0xe91380: netsh firewall set service type=remotedesktop mode=enable scope=subnet

A general overview of the commands is as follows:

• The attacker ran IP configuration commands to identify the source IP of the box
• The attacker added the user user1 to the Remtoe Desktop Users group using net
• The attacker configured the Firewall to allow Remote Desktop from within the same subnet

With this, we validated the following subset of TTPs and their relevant tactics

Command and Scripting Interpreter (T1059) — Execution

Account Creation (T1136) — Persistence

I’ve also extracted the registry hives from:

• %SystemRoot%\System32\config
• {Username}\Documents\NTUser.dat

From the SAM hive, we can recover the list of users on the system:

Shows two users added at the same time — ‘hacker and user1' — we have proof of the user ‘user1’

We didn’t see the hacker user being added to the system using the web-shell. Well, what else could’ve caused this to happen? Remember the exec endpoint exploitation we left behind. It could be a good pointer to pivot from here. But we didn’t have the POST data. How else can we explore that? Let’s jump back to our memory sample and see if we can find the process related to the Apache server.

httpd.exe   2796   2768     1     92 2015-08-23 10:32:21 UTC+0000
httpd.exe   2880   2796    155    483 2015-08-23 10:32:26 UTC+0000

So, the PIDs 2796 and 2880 belong to httpd.exe, the binary serving up the Apache server. Let’s dump their memory space by using Volatility again:

volatility -f mempdump.mem --profile=VistaSP1x86 memdump -p 2796 --dump-dir E:\
volatility -f mempdump.mem --profile=VistaSP1x86 memdump -p 2880 --dump-dir E:\

Running a simple strings search on these dumps, I’m going to save the results. Then, let’s see if the attacker tried to run the ‘net’ command via the command injection vulnerability to add the user ‘hacker’ to the system.

Same commands being executed for the second account — hacker

Output from the second process’ dump

If we review one of the commands, it has an IP field followed by an “%26%26”. If you run the URL Decode Cyber-chef recipe on it, you can retrieve the actual value — which is ‘&&’. This means, the attacker tried to send these two values and since the input wasn’t filtered — both the commands executed. One thing’s for sure — all command injections will then follow the same format. The actual IP followed by the ‘&&’ and then the attacker’s command. We can use this information to look for more such commands being run on the system.

Command Injection

Though we can safely conclude that the command injection exploitation was only used to perform reconnaissance on the system and administrator. Let’s pivot our focus from the ‘exec’ endpoint to the more important — web shells written to disk by SQL-map during the SQLi exploitation.

Exploitation of SQLi using SQLMAP

Two of these ‘tmp’ files appear to be droppers. After execution, we see GET requests to the ‘tmpukudk’ file, and after that, a completely new shell file ‘tmpbiwuc.php’. The actual shell commands are executed by tmpbiwuc file. After that, both the files are removed from the system.

Even parsing the MFT couldn’t help me trace these files back. Though I didn’t stop there. I further parsed the NTFS Journal LogFile for more information on the droppers. The LogFile captures changes to all entities in a volume. These changes — allocation, rename, deletions or similar actions — are recorded in the shape of transactions. These transactions are actually used to backtrack and resolve problems in the volume (if they’re not committed). Using LogFileParser by jschicht, I parsed the LogFile (retrieved from the forensics image). Though the timestamps don’t appear to be that clear, we can still find allocation and deletion for our droppers:

tmpukdk.php — the dropper

Let’s Summarize it All

Question Number 1:

Several attacks were performed on the server in question to exploit vulnerabilities. Some of these vulnerabilities are listed below:

1. SQL Injection
2. Command Injection
3. Local File Inclusion
4. Cross-site Scripting
5. Unrestricted file uploads
6. Web-shells
7. Brute-forcing (haven’t discussed it but you can review access logs for it)

Question Number 2:

Two — hacker and user1

Question Number 3:

From the MFT entries we parsed before (using Mft2Csv), we can identify the following files being stored to disk:

Output extracted from Mft2Csv

Question Number 4:

No software was installed on the system by the attacker. We can review Setup.evtx (from the Winevt log folder) for evidence. Normal installations include:

Question Number 5:

We’ve dumped memory from the httpd process to identify signs of shellcode. The answer is summarized in our discussion above.

Question Number 6:

Here’s the timeline I’ve gathered from this investigation:

• 02/09/2015 07:10:41 — Requests from the IP 192.168.56.102 start coming in from the browser IceWeasel (typically installed on Kali Linux as well)
• 02/09/2015 09:04:35 — ‘exec’ endpoint exploited by means of command injection attacks, followed by net commands to create the users ‘hacker’ and ‘user1’, then addition to the Remote Desktop Users group
• 02/09/2015 09:31:16 — LFI vulnerability being exploited to access administrator files, PHP configurations, and logs
• 02/09/2015 10:49 — SQLi attacks
• 02/09/2015 11:15:40 — SQLmap being used to automated SQLi attacks
• 02/09/2015 11:25 — Droppers ‘tmpukudk’ and ‘tmpbiwuc’ being dropped and then drop webshells on the endpoint
• 03/09/2015 07:14:41 — Creation of webshells.zip on the system which includes more command shells inside — including C99
• 03/09/2015 07:21:40 — Access and run commands via the webshell

Question Number 7:

DVWA is an intentionally vulnerable application used by researchers to practice on penetration testing capabilities. However, in this scenario, the application was hosted and exploited. We started off from the log sources, then pivoted to host logs, registries, and finally the memory for manifestation of attacks. The attacker used several exploits at the start to compromise the endpoint, gain persistence via creation of accounts, and dropping the webshells. The attackers could’ve achieved much more by utilizing RDP but didn’t do so.

Conclusion

The ‘Web Server Case’ was definitely interesting to learn and revise analysis strategies you’d normally equip during an investigation. Download the files, review a write-up if you will, or get started on your own. If you do stumble, it’s perfectly fine to seek help and remember the technique for future use!

Good luck and happy hunting!