In the ever-evolving landscape of cybersecurity, the field of digital forensics plays a crucial role in investigating and analyzing cyber incidents. Digital forensics is the process of extracting and analyzing information from digital devices to uncover evidence of cybercrime, security breaches or other illegal activities, with the goal of understanding and mitigating cyber threats. This field encompasses various sub-disciplines, including disk forensics, network forensics, and memory forensics. Each sub-discipline focuses on a specific aspect of digital evidence to provide a comprehensive understanding of cyber incidents. In this article, we will focus on the field of memory forensics.
Understanding Memory Forensics
Memory forensics involves the analysis of a computer’s volatile memory (RAM) to extract valuable information related to ongoing or past cyber incidents. Unlike traditional forensics methods that examine stored data on disks, memory forensics provides real-time insights into a system’s state during an active cyber event. Security analysts and researchers leverage this technique to uncover hidden or sophisticated threats that may escape detection by other means.
To dive deeper into the significance of memory forensics as a method of investigation, consider the following points:
- Real-Time Analysis: Memory forensics allows security analysts to investigate cyber incidents as they happen, providing real-time insights into the state of a system during an active attack. This immediacy is crucial for effectively responding to and mitigating ongoing threats.
- Detection of Advanced Threats: Sophisticated cyber threats often employ stealthy techniques to evade traditional security measures. Memory forensics is particularly effective in detecting and analyzing these advanced threats, such as rootkits, kernel-level malware, and fileless attacks that leave minimal traces on storage.
- Recovery of Volatile Data: RAM holds a wealth of volatile data that may not be stored on disk. Memory forensics allows investigators to recover information such as passwords, encryption keys, and running processes, providing a comprehensive view of the system’s activities at a specific point in time.
- Incident Response and Digital Forensics: Memory forensics is a valuable tool in incident response, aiding in the rapid identification, containment, and eradication of cyber threats. Its integration with overall digital forensics practices enhances the investigative process and contributes to a more effective response strategy.
- Forensic Timeline Reconstruction: By analyzing memory dumps, forensic experts can reconstruct a timeline of events leading up to and during a cyber incident. This chronological view is crucial for understanding the sequence of actions taken by an attacker and helps in attributing the incident to specific threat actors.
Acquiring a memory dump
The initial step in performing a memory analysis involves isolating the infected or suspicious machine, then capturing a sample of the current state of RAM. This can be accomplished using various tools. For instance, FTK Imager can be employed to capture a memory dump for both Windows and Linux computers. Additionally, there are other well-known tools such as WinPMem, specifically designed for the Windows Operating System, and AVML, dedicated to Linux.
Analyzing the memory dump
After successfully acquiring the memory dump, we are now ready to begin our investigation. Tools commonly used for this purpose include Volatility, Rekall and Sleuth Kit. These can also be combined with other types of tools, such as package analyzers and tools designed to search for file-specific metadata. This combination allows for a more comprehensive understanding of what happened. However, in this article, we will focus on Volatility, an open-source memory forensics framework written in the Python programming language. Volatility is capable of analyzing memory samples from Windows, Mac OS X, and Linux.
There are Volatility 2 and Volatility 3 tools available on GitHub. However, due to ongoing development and potential issues with Volatility 3, Volatility 2 is recommended for its stability and will be the focus of this presentation.
Capabilities of Volatility Framework
Image Profile
The initial critical step when using Volatility is to determine the profile of the memory dump. This essentially involves determining the machine’s operating system and service pack. That helps Volatility in better identifying locations that store artifacts and useful information. This can be achieved by first moving to the volatility directory and running the ‘vol.py’ file, specifying the location of the dump file. At the end we must use the ‘imageinfo’ plugin as shown below. Volatility uses Kernel Debugger (KDBG) in order to identify the profile of the system:
In the memory sample, within the ‘Suggested Profile(s)’ section, the primary profile listed is ‘WinXPSP2x86’. This indicates that the computer is operating on Windows XP with Service Pack 2, a 32-bit operating system. We will need this information for continuing our investigation. The next step involves finding the list of processes that were active in memory.
Find running processes
Since malware are programs they run in RAM, examining the active processes in RAM can help identify any suspicious activity and provide specific points of focus. For this step and so on, we will use the acquired knowledge gained for the previous step, and we will specify the profile of the sample using the ‘–profile=WinXPSP2x86’ plugin. We will then use the ‘pslist’ plugin to list the processes:
The result presented may seem somewhat complicated, especially for those new to forensic investigations. Let’s delve into the basic structure of the processes to clarify it. The column ‘Offset(V)’ indicates the memory segment where the registered process is executed, and the name of the process is provided in the ‘Name’ column. Each process running in memory has a unique identifier known as a ‘PID’ (Process ID). In many cases, processes are spawned from existing processes, referred to as Parent Processes, and their descendants are known as Child Processes. In many cases knowing this information can be vital for our investigation process and help us create a timeline of the events. Finally, the ‘Start’ and the ‘End’ columns, refer to when the process started and when finished.
Visualize parent-child relationships
Although, we can obtain a better visualization of the parent-child relationship, by using the ‘pstree’ plugin. Child process are indicated using indention and periods:
Sophisticated malware aims to be as discreet as possible to avoid detection, keep infections in systems and thwart the efforts of cybersecurity analysts to understand its operation. This is done in order to prevent the discovery of potential remediation and recovery measures. In our case, when analyzing a memory dump to identify running processes, it is possible that certain processes are attempting to hide themselves.
Find hidden processes
While ‘pslist’ and ‘pstree’ may not effectively address this malware behavior, there are other plugins that can. The ‘psscan’ plugin can find processes that previously terminated (inactive) and processes that have been hidden or unlinked by a rootkit. The downside is that rootkits can still hide by overwriting the pool tag values (though not commonly seen in the wild).
Understand better which processes are trying to hide
To identify which process is hidden, it is important to correlate this result with the output from ‘pslist’ or ‘pstree’. However, a more efficient method for detecting processes attempting to hide themselves is to utilize the ‘psxview’ plugin, as it performs the same function for us. If you see that true statement is present under pslist column then assume that no processes are hidden. If you see it false, then its an indicator of malicious activity:
It’s crucial to note that identifying which processes are suspicious and may serve as Indicators of Compromise (IoC) requires a strong understanding of operating systems and their processes, along with a considerable investment of time in research.
Analyzing the DLLs of processes
In the Windows operating system, each process obtains specific task execution capabilities by loading smaller, specialized programs designed for specific functions. These smaller programs are known as DLLs or Dynamic Linked Libraries. The following step after categorizing specific processes as malicious is to further analyze which DLLs they are utilizing. Analyzing DLLs can offer a deeper understanding of the permissions associated with a process and its potential actions. This can be done by using the ‘dlllist’ plugin and specifying the PID of the processes using the ‘-p’ flag:
In the screenshot above, the analysis focuses on the ‘tasksche.exe’ process, which tries to mimic the legitimate Windows ‘Task Scheduler’ process. However, the legitimate executable is called ‘taskschd.msc’, indicating that the analyzed process is malicious. Some important DLLs listed are the following:
- ADVAPI32.dll: provides advanced API functions related to the registry (edit and query), applications, services, and user accounts.
- Secur32.dll: responsible for implementing security-related functions in the Windows operating system (e.x. encryption and decryption).
The above screenshot is preserving the DLLs used by the ‘@WannaDecryptor.exe’ process. It is also considered malicious as there is not legitimate Windows processes starting with the ‘@’ symbol. Some additionally important DLLs are listed below:
- urlmon.dll: handles various internet-related tasks in Windows.
- WS2_32.dll: used to handle network connections and creating sockets.
- WININET.dll: responsible for handling various internet-related functions, such as HTTP, FTP, and HTTPS protocols, as well as managing cookies and caching. It also deals with high speed network communication.
Check for Mutex
Another aspect that is usually investigated is handles which are special identifiers or references used to access specific resources or objects. Handles play a critical role in managing resources such as files, devices and various system objects in the Windows operating system. Each process in Windows operates within its own address space, and handles serve as a mechanism for a process to interact with objects or resources beyond the specified address space. A more specific type of handles that investigators seek is a mutex.
A mutex, short for mutual exclusion, is a synchronization primitive that allows exclusive access to a shared resource for only one thread at a time. When a thread acquires a mutex, any subsequent thread attempting to acquire the same mutex is suspended until the first thread releases it. It is common for malware, when communicating with a command and control (C2) server created by the threat actor, to maintain a mutex. This provides clarity to the C2 server, indicating the ongoing activity and operation of the malware without causing confusion. This can be achieved by using the ‘handles’ plugin and specifying the PID of the desired process. Then the ‘mutant’ filter can be applied by using the ‘-t’ flag:
In our example, the ‘MsWinZonesCacheCounterMutexA’ and ‘MsWinZonesCacheCounterMutexA0’ mutexes serve as examples of the previously mentioned functionality of processes.
Check for Registry Queries
In the dynamic area of cyber security, digital forensics, and in particular memory forensics, plays a key role in uncovering the complexity of cyber incidents. The ability to conduct real-time analysis, identify advanced threats, recover unstable data, and contribute to incident response efforts makes memory forensics an essential tool for security analysts and researchers. As cyber threats continue to evolve, the importance of memory forensics will grow, shaping the future of digital investigations and strengthening defenses against sophisticated adversaries.
Another frequently employed method in memory forensics investigations involves searching for registry queries conducted by the malware. These queries serve various purposes, such as maintaining a persistent presence on the infected system, executing autostart mechanisms during system startup, disabling security features, concealing their presence, escalating privileges, and establishing communication with a Command and Control (C2) server. This can be achieved by using again the ‘handles’ plugin but this time employ the ‘key’ filter:
In the screenshot above, the output indicates that the key ‘USER\S-1-5-21-602162358-764733703-1957994488-1003’ is affected.
Check for network connections
It is common for malware to establish communication with external IP addresses for purposes of data exfiltration and maintaining a connection with a Command and Control (C2) server. This network activity becomes visible during a memory dump investigation using plugins like ‘connections’, ‘connscan’, and ‘sockets’. While each of these plugins differs in the level of abstraction in presenting information, they collectively assist in identifying and analyzing the established connections:
It’s crucial to note that sophisticated malware typically attempts to cover their network communications, and as a result, these plugins may not provide clear evidence of network traffic. To enhance the investigation, it is recommended to employ additional tools such as bulk_extractor to extract more artifacts, along with specialized packet analyzer tools like Wireshark for a more in-depth analysis.
Dumping Processes and Memory Locations
After conducting a memory forensics investigation, additional investigation methods are applied to examine suspicious processes and executable files. A well-known approach is ‘reverse engineering’, which is used to analyze and understand the behavior of malware. Security researchers utilize reverse engineering to identify vulnerabilities, create antivirus signatures or develop effective countermeasures. Two useful commands, ‘procdump’ and ‘memdump’, serve different purposes.
The ‘procdump’ command captures the entire memory space associated with a specific process, offering a comprehensive view of its state:
On the other hand, the ‘memdump’ command targets memory locations of executables, allowing for more focused extraction on specific regions, such as the code segment of an executable:
