Hello, World! In this article, I will be showing you how to setup Volatility3 on Linux (and technically on Windows as well if you’ve enabled Windows Subsystem for Linux!) and how to perform introductory memory forensics utilizing Volatility3, which is currently in beta mode. The Volatility3 version I am using for this tutorial is 1.2.1. The memory samples I will be utilizing can be downloaded from the TryHackMe room, Forensics, by Whiteheart (I chose this sample because it the only memory sample that I have found that works perfectly with Volatility3, as it is still in beta mode). Disclaimer: I literally began working with memory forensics about a week ago so I am by no means an expert in this area. But I guess you can still learn something useful from this article.
To make installation simpler, I created a Bash script to install and setup Volatility3. The script installs Python’s package manager, if it isn’t already installed, and also installs all the necessary Python packages for full functionality of the current version of Volatility3. Run the following commands to execute the installation script:
wget https://gist.githubusercontent.com/binexisHATT/2cbf50e6308140db4017a274fc1ce9ba/raw/e9f86718168876a3d5c42c9077933e71bf1ad4f4/volatility3_install.shchmod +x volatility3_install.shsudo ./volatility3_install.sh
The Contents of the Installation Script
Analyzing the Memory Dumps
Obtaining the OS
Obtaining the operating system (OS) of the memory dump is pretty straightforward. The plugin “info.Info” can be specified to enumerate information about the captured memory dump. In Figure 1.1, below, we see that the plugin also provides additional information about the memory dump such as the OS version, a timestamp representing the original install date, and the number of processors on the machine, etc. The output produced by the Info plugin tells us that the OS of the memory dump is Windows.
Listing Running Processes
Since we now know the OS of the memory dump is Windows, we can use the Volatility3 plugins that are specific to Windows-based memory dumps. The plugin we’ll use to dump all the running processes and their corresponding PIDs is conveniently named “windows.pslist.PsList”. This plugin will simply list the services that were running in memory while the memory dump was captured.
The windows.pslist.PsList plugin was not created to detect services running in memory that have been hidden by malware such as a rootkit, which can use advanced techniques to hide their malicious services. This type of detection requires a deeper analysis of each individual service and its memory structure which is provided by the plugin “windows.psscan.PsScan”. The PsScan plugin takes much longer to run than the PsList plugin because of the more elaborate scanning process it performs. Generally, most of the plugins that contain the word “scan” are going to take longer.
My favorite plugin for listing running processes is the “windows.pstree.PsTree” plugin. It provides a parent-child view of the running processes. This plugin could quickly reveal malicious running services, especially if you have a good understanding of the tree structure of Windows processes. Knowing what the normal Windows process tree looks like can help us spot running processes that do not seem to be residing in their normal locations within the process tree. For example, if the PsTree plugin discovers a “svchost.exe” process not running as a child process to the “services.exe” process, we can declare this an indicator of compromise (IOC).
Viewing Network Connections
Analyzing the network connections within a memory dump can help in the detection of malware. Dumping network connections can help us detect services that are establishing output network connections. This sort of behavior, especially from services that do not require network connections, should be marked as a red flag and can potentially mean that a backdoor is present on the machine. Viewing network connections can also reveal behavior such as C2 communications to malicious IP addresses or port numbers. The plugin for viewing the network connections within a memory dump is “windows.netscan.NetScan”.
Getting Command Line History
Another very lucrative plugin for detecting malicious activities is the “windows.cmdline.CmdLine” plugin. This plugin allows us to retrieve the commands that were executed by a process. The Windows OS doesn’t create a file within the user's home directory that contains the user’s command history like in Linux where the user's past commands are stored within a file named “.bash_history”.
Viewing Privilege Tokens
Every process is initiated by a user and inherits the user's access tokens, i.e. privileges. The access tokens provide the security context for the running service — they contain information regarding the identity of the user and the privileges linked to the user. A very well-known attack against Privilege token is Juicy Potato. Juicy Potato abuses the
SeAssignPrimaryToken privileges to escalate local privileges on a Windows machine. Running the plugin “windows.privileges.Privs” gives us a listing of the running processes and their corresponding privilege tokens.
strings command is a popular static malware analysis tool that can quickly assist in extracting human-readable pertaining to a malicious file, such as the DLL’s it imports, or malicious URL’s. We can use the Volatility3 “windows.strings.Strings” plugin to locate in which process(es) in memory a particular string resides in. To use the Strings plugin we first have to use the strings command (duh) to choose the strings we wish to search for in the memory dump. First, run:
Then, select a string from the output of the command above and grep for the string you chose. In my example below, I chose the string “SeImpersonateClient”. The “ — radix=x” tells the strings command to output the corresponding hexadecimal address of the string followed the string itself:
Lastly, let’s redirect the output to a file:
strings --radix=x victim.raw |grep "SeImpersonateClient" > strings_file.txt
Great, now we can use the file created from the command above to pass as an argument to the Strings plugin. NOTE: as mentioned before, Volatility3 is still early in its development and this plugin does necessarily run so smoothly, as you can tell from the output in Figure 1.9.
Getting Processes Environment Variables
Every process has a set of environment variables that it can use to query information about the system and thus influence the way it behaves when it runs on a system. For example, a process may want to write and store data into a user’s temporary folder thus it will need to obtain the value of the TEMP environment variable or if a program needs to interact with a programming language on a system, it will, for example, need to obtain the value of the GOPATH or PYTHONPATH environment variables. An adversary may maliciously modify or add an environment variable to compromise a system. A very ubiquitous technique involves the modification of the PATH environment variable which could deceive the search order mechanism of command-line programs like Cmd.exe and Bash into inadvertently running malicious executables. The retrieve the environment variables for each process we need to use the “windows.envars.Envars” plugin.
Applying Yara Rules
Yara rules are used for malware research and detection. These rules are used to define a signature that will identify a particular malware or malware variant on a computer. All malware leaves traces of its presence on the system it infects, whether it be a change in the Windows registry or a malicious executable in the file system; Yara rules allow us to detect malware by identifying these inescapable footprints left behind by the malware. The plugin for running a Yara rule on a memory dump is “yarascan.YaraScan”.
I created the simple Yara file, shown in Figure 1., which I called “detectexe.yar” and passed the name of the file as the value to the argument “ — yara-file” of the “yarascan.YaraScan” plugin.
The last plugin we will discuss, “windows.filescan.FileScan”, dumps the files that were loaded in memory during the time of the memory capture. This plugin will return the files offset in the memory dump and the name of the file. Volatility2 also provided the number of pointers to the file and the permissions of the file which I am assuming will also be incorporated into the plugin in a later version of Volatility3.
There are still a ton of other plugins that are currently available that I did not mention in this tutorial, like the “windows.malfind.MalFind” plugin, which was one of the most popular plugins of Volatility2, that was capable of detecting if a process contained injected code (Amazing!). In addition, the memory sample we were analyzing was a Windows memory dump, and thus we did not work with the different plugins that target the Linux and Mac operating systems. After Volatility3 is officially released, I will create an updated article demonstrating more Volatility3 plugins. I am confident there will be a ton of other plugins that will also be added to Volatility in the future and I hope to contribute to this wonderful tool in the near future. Thank you for your time! If you enjoyed this article, please share it!