Memory Forensics on Windows and Linux
Introduction
To gather a broader range of opinions and statistics, I posed this question on Reddit to see what kind of responses and insights I would receive.
The majority of the answers emphasized that instead of shutting down the application immediately, it’s important to investigate the memory to understand the issue.
In this article, we will describe what information can actually be learned from memory, as well as the usefulness and challenges of analyzing memory dumps.
Why Investigate Memory Instead of Shutting Down?
1. Identifying the Root Cause:
Memory State Analysis: The state of memory at the time of the crash can provide critical insights into what went wrong. For instance, memory dumps can reveal patterns, such as which variables were in use and what data structures were corrupted.
Crash Logs: Examining logs generated at the time of failure can show the sequence of operations leading up to the crash.
2. Preventing Future Crashes:
Pattern Recognition: By analyzing memory and crash data, developers can identify recurring issues or vulnerabilities. This helps in developing more robust error-handling mechanisms.
Bug Fixing: Understanding the exact state and conditions leading to the crash allows for more precise bug fixes.
3. Improving Application Stability:
Graceful Degradation: Instead of a full shutdown, applications can be designed to handle errors gracefully, perhaps by restarting only the faulty module or component.
Error Resilience: Investigating crashes can lead to implementing better safeguards, making the application more resilient to similar issues in the future.
Memory Forensics
Forensic investigations are often carried out in response to security incidents and can be categorized into three types:
Disk Forensics: Focuses on analyzing storage devices like HDDs and SSDs.
Network Forensics: Examines communication data, including packet captures, NetFlow data, and logs from proxies and firewalls.
Memory Forensics: The focus of this article, it explores the state of system memory.
Memory forensics, in particular, allows for the examination of processes and network connections that are challenging to investigate through other forensic methods.
Memory Forensics Process
Memory forensics follows a similar approach to other investigative methods, where data is first preserved and then analyzed.
For memory forensics, this typically involves creating a memory dump of the system’s RAM, which is then examined using specialized tools.
Windows Memory Forensics
How to perform a memory dump
I’ve previously provided detailed instructions on using **WinPmem **for memory forensics on Windows, which you can refer to for guidance.
Capturing Memory Dump On Windows
Besides WinPmem, there are other tools available for creating memory dumps, such as DumpIt and Ram Capture, both of which offer simple and efficient ways to capture memory data.
For virtual machines, suspending the virtual machine will allow you to obtain a memory dump that can be examined later.
Examining the memory dumps
In this article, we will use Volatility3.
Below is an example of windows.pstree running to display the parent-child relationships of processes.
There is also psscan, which can display terminated processes. With psscan, you can also check Process 1 , which is hidden in the normal process list by malware.
You can also check the status of your network connections. The output is similar to the netstat command, but it includes the PID and process name.
Other operations include displaying handles and privileges, and extracting files from memory dumps.
There is also malfind 2 , which checks processes that have been injected with code by malware.
These are pieces of information that cannot be investigated or are difficult to obtain using disk forensics. If memory can be obtained, it is better to do so.
Linux Memory Forensics
Linux memory dump
I’ve previously provided detailed instructions on using **AVML **for memory forensics on Linux, which you can refer to for guidance.
Capturing Memory Dump On Linux
This time we will use a fresh installation of Debian to create a profile and examine the memory dump.
Download a kernel with debug symbols, making sure to specify the one that matches the kernel version you are investigating.
1 | apt install linux-image-6.1.0-21-amd64-dbg |
The above files are saved in:
/usr/lib/debug/vmlinux-6.1.0-21-amd64
Install golang to build dwarf2json.
1 | apt install golang git |
Download the source code and compile it.
1 | git clone https://github.com/volatilityfoundation/dwarf2json.git |
Now you can use dwarf2json.
Create a profile based on the debug kernel. This took about 78 secondes in my environment (with 32GB of virtual machine memory and 10 CPU cores).
1 | ./dwarf2json linux --elf /usr/lib/debug/vmlinux-6.1.0-21-amd64 > output.json |
Specify the created JSON file with the -s option of Volatility3.
In my case, I placed it in the same folder as the virtual machine suspend file, so I specified “.”.
1 | vol -s . -f Debian-1fbfd5c7.vmem linux.pslist |
Now to get the list of processes is displayed as follows:
The display of network connections that was previously displayed by netscan in Windows is now displayed by linux.sockstat.
Identifying Injected Code
Let’s imagine we have an injected code that was made by a Malware.
Malware is often “packed” to obfuscate the code written by its author. This means that the malicious creators use techniques to hide their code, making it difficult for analysts to quickly understand what the malware does or how to neutralize it.
Packed malware is essentially encased in an extra layer of code, concealing the original harmful code. This method of hiding the true nature of the malware is referred to as “packing.”
As a result, when the malware is executed, it must first unpack itself. This unpacking process occurs in the system’s memory, which is ideal for tools like Volatility that specialize in memory analysis.
To search for injected code using Volatility, utilize the ‘malfind’ feature.
This tool identifies processes that potentially contain injected code by analyzing their header information in hexadecimal format, examining permissions, and reviewing some extracted assembly code.
However, it’s important to note that just because a process appears in the ‘malfind’ output, it doesn’t automatically mean that the process is definitively malware.
The output of malfind is displayed below.
The key points you need to understand are the PID, the process name, the protection, and the area highlighted in red.
The PID and process name are self-explanatory, the Protection relates to the output PAGE_EXECUTE_READWRITE.
This means the process has execute, read and write permissions, this is common for malware as it needs to be able to execute itself or other executables it downloads/drops, it needs to read files on the device it has compromised and it needs to be able to write files to disk. So any processes captured that have these permissions will be displayed in the malfind output.
As this serves as an introduction the simplest way to get started with malfind is to focus on the process name and the area I have highlighted in red.
This displays the start of the data contained within the process represented in hexadecimal and next to that the same values in ASCII.
The Benefits And Challenges Of Acquiring Memory
As we’ve observed, acquiring memory data can yield crucial insights for investigating the causes and impacts of security incidents. However, memory data is volatile by nature and can be lost due to system shutdowns, restarts, or process terminations. Therefore, it’s crucial to collect memory data promptly upon discovering a security incident.
Regarding the initial decision of whether to keep the system powered on, it’s advisable to capture memory data if feasible, as it may provide additional critical information. Some malware operates solely in memory (fileless malware), underscoring the importance of capturing memory data. However, forensic investigations can still proceed with incomplete data, and in my experience, the absence of a memory dump rarely renders an investigation futile. Often, investigations begin after the system has already been shut down.
Up to this point, the discussion has been centered on forensic investigation.
From an incident response standpoint, the option to power off the system is generally a prudent choice. In cases involving ransomware, powering down might help protect some data if done before all files are encrypted, though timing is critical. Furthermore, disconnecting the network or shutting off power can sometimes thwart ongoing attacks and preserve evidence from destruction by attackers.
© 2022 - Sofiane Hamlaooui - Making the world a better place 🌎