Analyzing volatile memory (RAM) for evidence
Introduction
If you work in incident response you understand how critical it is to pull
forensically sound evidence from compromised devices as soon as possible.
This is often in the form of logs or hard disk images.
Both can present challenges and be time-consuming, if you pull the logs
from a device then you could be presented with millions of lines of logs and
need to spend time understanding the content, ingesting it into a platform
that makes the analysis easier, or manually querying the data using the
Linux command-line.
Hard disk images can be time-consuming to capture and transfer due to the
size of the disks, this is before any analysis has even taken place. For these
reasons, this is why one of my first questions on an incident is always ‘Can
we capture the memory?’.
The reason being is that the memory, or RAM, of a device, will be smaller
than the size of a hard disk and can be easy to capture. Once you have athe
captured RAM you can then quickly analyze the output using one of my
favorite incident response tools, Volatility.
Digital memory forensics is an analysis of volatile data that is stored in the
computer’s memory dump. Many memory forensics are evaluated to
investigate and find the attacks or any malicious activities that do not
ignore an easily identifiable way in the hard drive. The data which is stored
temporarily in the computer is volatile. When the computer is switched off
then the volatile data will be erased. Examples of volatile data are browsing
history, chat messages, etc. memory dump capturing a snapshot of memory
data from the incident. It contains valuable forensic data where it can be
used to identify the reason for the incident
Processes
If the system is in an active state then it will perform multiple processes and
there will be a volatile memory. This presence can be parsed out in the
memory dump. The process which is terminated before the reboot can be
stored an analyzed in the memory dump. Some plugins such as Pslist,
Psscan, Pstree, DLLlist,DLLDump, LDRmodules, hashdump can be used for
collecting the digital evidence .
Volatility 3 is a open-source memory forensics framework for incident
response and malware analysis. It provides tools for analyzing and
extracting data from volatile memory (RAM) snapshots of live systems,
allowing security professionals and incident responders to collect and
analyze evidence from a running system without interrupting it. Volatility 3
supports various operating systems and file formats, and its modular design
allows for the addition of plugins for custom analysis and support for new
memory artifacts.
Here are the general steps to use Volatility 3 as a memory forensics tool:
Obtain a memory dump: The first step is to obtain a memory dump of the
system you want to analyze. This can be done using a variety of tools, such
as Windows Task Manager, the dd command in Linux, or commercial
memory acquisition tools.
Install Volatility 3: The next step is to install Volatility 3 on a system that is
capable of analyzing the memory dump. You can download the latest
version from the Volatility Github page.
Identify the profile: Once you have the memory dump, you will need to
identify the profile that corresponds to the operating system and
architecture of the system you’re analyzing. Volatility 3 includes a wide
range of profiles for different operating systems and versions.
Run Volatility 3 commands: With the memory dump and profile identified,
you can now run Volatility 3 commands to analyze the memory dump. Some
common commands include imageinfo, pslist, pstree, and dlllist to gather
information about the system and processes.
Analyze the results: Finally, you can use the results of the Volatility 3
analysis to identify any potential security threats or incidents, such as
malware infections, suspicious process behavior, or unauthorized access.
What to Know Before Getting Started
Due to the size of Volatility this will not be a comprehensive list of the
functionality of the tool, instead it will serve as an introduction to the tool
and give you a strong foundation of knowledge of which to build on.
Before diving into using a tool like Volatility there are some key topics that
you will need to understand:
What is volatile data?
What is a memory dump?
How to capture RAM in a forensically sound manner
How to capture RAM from a physical device
How to capture RAM from a virtual machine
Luckily I have already covered this in a helpful guide that can be found
here.
If you are already comfortable with the above topics then let's get started
with Volatility!
How to Install Volatility
Before we start you need to be aware that there is more than one version of
Volatility available, the latest version is Volatility 3 which when I refer to
Volatility in this article I will be referencing Volatility 3.
Previous to Volatility 3, when using the tool to analyze a RAM dump you had
to specify the OS of the machine that the RAM dump had been taken from in
order for Volatility to work. This could often be time-consuming depending
on the architecture of the device and whether a certain service pack had
been installed or not.
With Volatility 3 it will automatically work out the OS for you and means
you can get started analyzing the RAM you have captured straight away.
To download the latest version of Volatility use the following command:
git clone https://github.com/volatilityfoundation/volatility3.git
A folder called ‘volatility3 will now have been created, navigate to this
location and a number of files will be listed.
Install the required dependencies so that Volatility will run without any
issues.
pip3 install -r requirements.txt
Volatility should now be successfully installed, to check the tool is installed
correctly use the following syntax to launch the help file:
python3 vol.py -h
You’re now ready to begin using Volatility!
Identifying Malicious Processes
The first thing I like to do when I have received a RAM dump from a
potentially compromised device is look at what processes were running on
the device when the RAM dump was captured.
I’ve mentioned this in previous articles, but one saying that has always
stuck with me is “malware can hide but it must run”. Looking at the running
processes of a device is always a great way to try and identify any malware
that may be running on the device.
pslist
There are a few commands in Volatility that can be used for analyzing
running processes, the first one I use is ‘pslist’.
python3 vol.py -f <filename> windows.pslist
The above command will produce the following output:
In the above image, we can see the output delivered from using pslist, when
running these commands there may be a large amount of data produced so
it may be worth using the following syntax to tab through the output or
dump it into a text file, this can be done for any command in Volatility.
python3 vol.py -f <filename> windows.pslist | less
python3 vol.py -f <filename> windows.pslist > output.txt
Below are the keys headers from ‘pslist’ that you will need to understand
when you begin using the tool:
PID - Process ID number
PPID - Parent process ID number
ImageFileName - Name of the running process
Offset - Hexadecimal value representing the location in memory the
process is running
CreateTime - Time process started
ExitTime - Time process ended
Using this function I like to just take a look at the process names and see if
there is anything that jumps out at me. If there is anything that catches
your attention then simply google the name, you should be able to quickly
understand if it is something that looks legitimate or requires further
attention.
pstree
Once I have taken a look at the process names I then like to get an idea of
what process spawned another process. This makes it easier to spot
suspicious process activity as you can see what process launched ‘cmd.exe’
or ‘powershell.exe’ for example and see if this looks like legitimate activity
or not.
Another reason I like using ‘pstree’ is that attackers will often name the
running process of their malware after legitimate Windows processes such
as ‘svchost.exe’. This allows the malware to hide in plain sight as it doesn't
stand out amongst the numerous other Windows processes
Using ‘pstree’ is a great way to spot these malicious processes
masquerading as legitimate Windows processes. Windows processes will
always run from set locations on disk and their parent process tends to be a
set process. For example ‘taskhostw’ will always run from ‘%systemroot%\
system32\taskhostw.exe’ and its parent process will always be ‘svchost.exe’.
So if you spot ‘taskhostw’ running from any other location or with a
different parent process then it is definitely something you want to take a
closer look at.
python3 vol.py -f <filename> windows.pstree
The image below shows the output of ‘pstree’, note that the output of the
‘PID’ has column has changed slightly.
The order of the ‘PID’ column is now sorted by a process and its associated
child processes. However to make the visualization clearer for the user,
each child process is assigned a ‘* before its PID’, each subsequent child
process receives an additional ‘*’ prefixed to the PID.
The image below shows that the ‘System’ process has spawned ‘smss.exe’,
which has spawned another ‘smss.exe’, which has spawned ‘winlogon.exe’
and so on.
This is great for an incident responder as it makes it easier to see what
process activity was occurring on the box and identify any process activity
that could be potentially malicious.
Identifying Malicious Network Connections
When a RAM dump is captured any network connections at the time the
capture was taken will also be stored within the captured memory. This is is
great for incident responders as any malicious network connections can be
identified such as the source port, destination IP, destination port, and the
process that the network activity relates to.
netscan
To view the network connections associated with the RAM dump that is
being analyzed use the following command:
python3 vol.py -f <filename> windows.netscan
The following information will be displayed from running this command:
The output of netscan is made up of 10 columns:
oOffset - Location in memory
oProto - Network protocol used by process
oLocalAddr - Source address of network connection
oLocalPort - Source port of network connection
ForeignAddr - Destination address of network connection
ForeignPort - Destination address of network connection
State - State of network connection i.e. established, closed or
listening
PID - Process ID of associated process
Owner - Account associated with process
Created - Time network connection has initiated
The image below shows some network connections that have been
generated by a process called ‘smsfwder.exe’.
Volatility has identified three connections to three different IP addresses
communicating over ports 443 and 8080.
Reviewing each IP using Symantec Site Review confirms that this activity is
related to a known malware command and control server.
These IOC’s can now be used to search for other devices that may be
compromised and need isolating from the rest of the network as part of a
company’s incident response plan.
Identifying Injected Code
Malware is often packed so that the code written by the malware author is
obfuscated, the bad guys have taken time to write some malicious code and
don’t want it to be an easy task for somebody to take a quick look at the
malware and in a short space of time identify what it does and how to stop
it.
Packed malware is essentially ‘wrapped’ with a layer of code, this additional
layer hides the code the malware author has written and it’s this
obfuscation technique that is known as malware ‘packing’.
Because of this when a piece of malware is packed it will need to unpack
itself, it does this in memory which is great for Volatility as that is exactly
what the tool is designed to analyze!
If this is a new concept then I recommend reading this article I have
previously published which is all about unpacking malware. The key details
you need to know is that in order to unpack itself, the malware will create a
child process and inject the unpacked executable/unpacked malware into
this new process.
malfind
Using Volatility to look for injected code is done by using the ‘malfind’
feature. This displays a list of processes that Volatility suspects may
contain injected code based on the header information displayed in hex, the
permissions, and some extracted assembly code, just because a process is
listed in the output it doesn't mean the process is 100% 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. If you have read
any of my previous articles, I have used tools such as x64dbg and PeStudio
to display the header of a Windows executable which is a common file type
used for malware.
The header of a Windows executable in hex will always start with ‘4D 5A’
which represented in ASCII is ‘MZ’. Below is a piece of malware that I have
opened in HxD which is a hex editor, by using this tool I can display the file
header that contains this information.
As an incident responder when using ‘malfind’ if you see these values within
a process then it is very likely you have identified a piece of malware that
has injected itself into another process.
procdump
Using the commands covered in this article should put you in a good
position to start identifying potential malware running in memory on a
device. Using ‘netscan’ I was able to identify a process named
‘smsfwder.exe’ that was making some malicious network connections to
known C2 infrastructure. As part of my investigation using Volatility, I can
extract this process for further analysis using a feature called ‘procdump’.
python3 vol.py -f <filename> -o <location to dump process>
windows.dumpfiles –pid <PID>
This will extract the executable and all of the associated DLLs. In the image
below I have extracted the process to a folder named ’procdump’.
This is useful as you can then try and extract additional information from
the dumped process by performing some simple checks such as running the
‘strings’ command against the dumped process to see if you can identify any
additional IOC’s such as IP addresses, filenames, persistence locations etc.
