Our critical web server exhibited signs of compromise (e.g., malicious process execution, anomalous network traffic, and unauthorized file system modifications). Memory forensics helped us piece together an attacker's playbook and reveal the full scope of the intrusion.
The Importance of Web Servers
Before we embark on our investigation, we must cover the importance of web servers. These computers are the foundation for accessing websites online, storing and delivering content like text, images, and videos to users when they request them through a browser. In our previous blog, Browser Breadcrumbs: Private Browsing Footprints Tell Their Tales, we focused on the browser—the software used to connect to websites hosted on web servers. This time, we are going to dive into web servers.
A server OS (operating system) is a server-based operating system for web servers that functions in a client/server relationship. Some examples include web, mail, and file database applications, which all rely on operating systems to assist users on the network. According to Fortune Business Insights, Linux holds the largest market share (63.1%) in operating systems. In our case, we are investigating a Windows web server—a small piece of the pie.
Global Server Operating System Market Share, By Operating System, 2024
Memory Never Lies: The Investigation Begins
We have been granted the memory dump for the compromised web server. With this single piece, we will unmask a full-fledged compromise primarily using the Volatility tool. Note: I utilized the command export image=PATH-to-MemoryImage to set a short path variable for the memory image. This saves time and space running the Volatility commands.
Let's find the web service name to determine the path for its web logs by enumerating the running processes at the time. I will utilize the command python3 vol.py -f $image windows.pslist.
At 2025-01-20 02:01:13.000000 UTC, you can see the executable nginx.exe running. This web server software is often used to serve web content and manage network traffic. Now that we have the web service name NGINX, we will utilize the following command to find its logs: python3 vol.py -f $image windows.filescan | grep -i "nginx".
Let's note the key log paths for NGINX below:
- Main domain:
\Users\web-server\nginx\logs\access.log - Login subdomain:
\Users\web-server\nginx\logs\login\access.log - Sysmonitor subdomain:
\Users\web-server\nginx\logs\sysmonitor\access.log
We will transition into log analysis by dumping the access.log for the main domain to extract the attacker's IP address. The command here can help us dump objects by their virtual address: python3 vol.py -f $image windows.dumpfile --virtaddr 0xe00166c8cb20.
Log Analysis: Web Server
Switching from the Windows Subsystem for Linux (WSL) terminal to our Windows host, we utilized Notepad++ to view the dumped file file.0xe00166c8cb20.0xe00169044bc0.DataSectionObject.access.log.dat.
From this output, we know the following:
- IP Address:
192.168.56.111 - Timestamp:
07/Feb/2025:07:06:44 - HTTP Method:
GET - Requested Resource:
/ - HTTP Status Code:
200 - Bytes Sent:
3180 - Referrer:
- - User-Agent:
Fuzz Faster U Fool v2.1.0
The IP address is likely to be the attacker's because of the timing of the requests (rapid succession). The user-agent, which is a software agent responsible for retrieving and facilitating end-user interaction with web content, is Fuzz Faster U Fool (FFUF). This is an open-source command-line tool that helps identify vulnerabilities in web applications.
In the file.0xe00166e7c770.0xe00169011ab0.DataSectionObject.access.log.dat logs, we see multiple failed login attempts. The attacker is using a username and password list to brute force.
In the file.0xe001680088f0.0xe001672132c0.DataSectionObject.access.log.dat logs, we see multiple failed authorized login attempts and SQL injection payloads. The attacker most likely dumped the database by exploiting a vulnerability in the following subdomain http://sysmonitor.dev-corp.com/. We will prove this soon in the following section.
Note: not all examples were highlighted in red.
SQL Injection Analysis: Web Server
As we found in the previous section, the SQL injection targeted /index.php. This is the default landing page for many websites built with PHP, making it a prime entry point for exploiting vulnerabilities like SQL injection, cross-site scripting (XSS), or code injection.
Let's gather the name(s) of the table discovered by the attacker by decoding the last payload of the SQL injection attack in CyberChef.
After copying the last payload, we will decode it using the following recipe: URL Decode → From HTML Entity.
The first arrow (to your left) is the database name admin_system, and the next arrow (to your right) is the table name administrator.
Network Analysis: External Services (FileZilla)
At this point, the vulnerable subdomain probably enabled the attacker to compromise additional accounts that were likely used to access external services. Note: Keep the constructed attack timeline in mind (the attacker got access to the sysmonitor domain and discovered that the system's information included detailed user data. Leveraging this information, the attacker brute-forced the SQL service to access the database).
We will utilize the following command in Volatility to examine the listening ports and determine the corresponding service name: python3 vol.py—f $image windows. nets can | grep—i "Listening".
Given the output, we must examine the FileZilla server logs using windows.filescan plugin. as we did with NGINX. FileZilla is a free, open-source program that allows users to transfer files between computers using the File Transfer Protocol (FTP). This analysis will help identify any suspicious activities related to FTP access, such as unauthorized file uploads or other anomalies that might indicate an attempted exploitation of the FTP service. python3 vol.py -f $image windows.filescan | grep -i "FileZilla".
After extracting the FileZilla server logs using the windows.dumpfile plugin, we need to conduct a thorough analysis of the data. This investigation should focus on identifying any indicators of compromise, such as:
- Suspicious Authentication Attempts: Look for repeated or failed login attempts that could indicate brute-force or unauthorized access.
- Unusual File Uploads/Downloads: Examine file transfer logs for anomalies that may suggest the presence of unauthorized shell uploads.
Log Analysis: FileZilla
As observed in the logs, the attacker's IP address, which is identical to the one detected during the web attack, was successfully authenticated. This confirms that the brute-force attack on the FTP service was indeed successful. Right below, you can view evidence of data transfers afterward.
Interestingly, the username is ftp-server, but how did the hacker get the password? Well, the settings.xml file in FileZilla is used to configure the server's administrator password; this file was located at the following path on the web server: Users\ftp-server\AppData\Local\filezilla-server-gui\settings.xml.
After viewing the file's contents, you can see the password in plaintext.
Deeper Analysis: Configuration File(s)
Let's retrieve the config.php file for further analysis. This is an important file for the web server that the attacker seemed to tamper with, given these logs below:
As usual, we are going to dump the file and view it within Notepad++
Shockingly, there is a function embedded within the file.
The script takes commands from a GET parameter named 'cmd' and executes them on the system using PHP's system() function. Now the images prior are making sense, the multiple GET /config.php?cmd=[INSERT COMMAND/PROGRAM].
I circled back to Volatility to run the command python3 vol.py—f $image windows.pstree. I wanted to see if the dwm.exe spawned any children, but sadly, I was disappointed that it was a fruitless process. No more leads... until I noticed this encoded PowerShell script.
PowerShell's PPID (Parent Process ID), the PID of dwm.exe, provides a critical clue about the attack methodology. Here are some hypotheses on why the dwm.exe process was not the evident parent (it sounds like a Maury episode, does it?).
- Execution & Disappearance:
- The malicious file (dwm.exe) is executed.
- Instead of persisting (deadbeat), it immediately spawns a PowerShell process.
- Once PowerShell runs, (dwm.exe) terminates itself, erasing its presence from active process listings.
- Evasion Technique:
- By terminating quickly, (dwm.exe) avoids detection by analysts relying on active process enumeration.
- Investigator might not see (dwm.exe) running (unhooked process), but its impact remains through the PowerShell process it launched.
Seeing the length of this blog, we will conclude the investigation. There is much more to do, however. We can decode the Based64-encoded PowerShell code from here to reveal the actual payload; we can also dump the dwm.exe process and dissect it with IDA or GHIDRA; or we can look for LOLBins (Living off the Land Binaries) to verify persistence or evasion techniques. And think about this: all this can come from a memory dump. Do you understand the power of memory forensics?
Conclusion
Memory forensics proved to be the cornerstone of this investigation, revealing what traditional disk forensics and log analysis might miss. Our analysis revealed that even sophisticated attackers leave traces in memory that can't be easily cleaned or modified. This case serves as a reminder that memory analysis should be a primary component of any incident response toolkit, not just an afterthought. Defenders, remember this before you shut down a machine during an event.
Logs and files can be cleared and deleted; memory holds the ultimate truth of system activity. Please keep that statement in your memory (i.e., brain).
About SBT
Security Blue Team is a leading online defensive cybersecurity training provider with over 100,000 students worldwide, and training security teams across governments, military units, law enforcement agencies, managed security providers, and many more industries.
