Memory Forensics for Incident Response
Introduction
Historically, criminal or corporate investigations involving computer
equipment began by immediately disconnecting any compromised machines
from the network, powering them down, and securing them in a proper
environment where they would be imaged and analyzed. The rationale for
this approach as the first step in the response process originates in the idea
of preserving the state of the hard disk at the time of response at all costs.
Thus, the thought was that if the system was allowed to continue running,
valuable evidence may be inadvertently or intentionally overwritten.
This investigative model worked very well for several years, but times have
changed. Knowing that an investigator’s first action would be to “pull-the-
plug” on a compromised system before performing any analysis, malware
authors began reducing their footprint on the victim’s hard disk and instead
storing as much as possible within the machine’s volatile Random Access
Memory (RAM). Since the contents of RAM are cleared when the computer
is powered down, once the investigator ”pulls the plug,” all traces of
potential malicious code, including its capabilities, any commands given to
it by the attacker, and data it may have exfiltrated from your network, have
vanished.
When responding to a cybersecurity incident I’ve always found memory
forensics to be a great skill to have. By capturing the memory of a
compromised device you can quickly perform some analysis to identify
potential malware and gather IOC’s which can then be used to identify
other compromised devices.
In this article, I will cover the following topics:
Provide an overview of what memory forensics is
Explain what volatile data is and why it is relevant to memory
forensics
Explain what a memory/RAM dump is1
Outline the benefits of memory analysis
Give an overview of some popular tools that can be used for
memory analysis
Memory Forensics Overview
Memory forensics is the process of capturing the running memory of a
device and then analyzing the captured output for evidence of malicious
software. Unlike hard-disk forensics where the file system of a device is
cloned and every file on the disk can be recovered and analyzed, memory
forensics focuses on the actual programs that were running on a device
when the memory dump was captured.
The memory of a device is known as Random Access Memory (RAM), so
when purchasing a new laptop, as part of the specification you will see the
size of the hard disk i.e. 1TB, and the amount of RAM i.e. 16GB. When an
application is opened on a device,1 a certain amount of RAM will be
allocated to that application so it can run, if applications are opened then
more RAM will need to be allocated by the device. This is why devices with
larger RAM are faster as they can run more applications at the same time.
What is Volatile Data?
Volatile data is something that any incident responder needs to be aware of,
the reason being is that when dealing with a compromised device one of the
first reactions may be to turn the device off to contain the threat. The
problem with this approach is that any malware that is running on the
device will be running in memory. So any network connections and running
processes will be lost, this is because the malware has been running in
memory and this data is now lost. This volatile data is not written to disk
and is changing constantly in memory, so powering down the device means
valuable evidence has been destroyed.1
Network containment (isolating the device from the rest of the network) is
the preferred option when isolating a compromised device. This method will
securely contain the incident and also preserve valuable evidence and not
destroy the volatile data in memory.
What is a Memory Dump?
A memory dump or RAM dump is a snapshot of memory that has been
captured for memory analysis. When a RAM dump is captured it will contain
data relating to any running processes at the time the capture was taken.1
Benefits of Using Memory Forensics for Incident Response
Responding to a cybersecurity incident isn’t always a straightforward affair.
Perhaps the server that has been compromised may not be feeding logs into
a SIEM, there may even be no logging at all! So as part of an incident
response plan how can you begin to investigate the device and start
gathering evidence in a timely manner? You need to first confirm that there
is malware on the device before you can capture a sample and begin
reverse-engineering the malware with specialist tools.
Taking an image of a device can be time-consuming, and you then have the
issue of transferring the image which could be 100GB in size, to a location
where it can be analyzed. Then you have to take into consideration how long
the analysis will take by the IR team.
This is where memory analysis can be a big win for the IR team. Whereas a
server hard drive may be over 100GB in size, the RAM of the device will be
a lot smaller, typically 16GB – 32GB. This means that capturing a RAM
dump from a device will be a lot quicker and smaller in size when
transferring the output. By prioritizing RAM over a hard disk image when
triaging an incident you can begin analysing the RAM dump for IOCs
(Indicators of Compromise) while you begin working on getting an image of
the hard drive.
How to capture RAM for analysis
If you are responding to an incident and require a RAM dump then how you
will go about capturing that data will differ depending on if the device is a
physical or virtual machine
Capturing RAM from a physical device
Capturing the RAM from a physical device can be done using several tools,
however, one I have often used in the past which I have found very reliable
and easy to use is WinPmem.
From the link above you can download either a 64-bit or 32-bit version of
WinPmem. Once the correct version has been downloaded open up a
command prompt with admin privileges and navigate to the location on the
disk where the executable has been downloaded.
Capturing RAM from a virtual machine
Capturing memory from a virtual machine is easy which is great news when
you are responding to an incident where time is a factor.
Taking a snapshot of a virtual machine will create a vmem file, these can
then be analyzed using a tool such as Volatility.
Volatility
Volatility is my tool of choice for memory analysis and is available for
Windows and Linux. Volatility is a command-line tool that allows you to
quickly pull out useful information such as what processes were running on
the device, network connections, and processes that contained injected
code. You can even dump DLL’s and processes for further analysis.
Volatility also supports the analysis of memory dumps from Unix devices
and a wide range of plugins have been designed by the forensic community.
One issue with Volatility was it required setting a ‘profile’ that matched the
operating system of the device it was captured from for the tool to work.
However, this has now been addressed in Volaitlity3 and the setting of a
profile is no longer required making using the tool even easier. The image
below shows how Volatility can be used to analyse a vmem file and also how
no operating system profile needs to be declared.
As a result of this shift in tactics by malicious software authors, it is now
widely recognized in the forensics and incident response communities that
an investigator cannot take the risk of immediately powering down
machines involved in a security incident. The new investigative approach
starts with an understanding of what resides in volatile memory by using
tools that quickly analyze Random Access Memory (RAM) and allow the
investigator to include volatile memory as part of the evidence.
Investigators that limit their analysis to the non-volatile data stored on the
hard drive not only leave vital evidence behind, but also completely destroy
it once the machine is shut down.
Additionally, advanced threats residing in volatile memory are typically
hidden from the administrator and Windows Application Programming
Interface (API). Therefore, rogue processes may execute without visibly
affecting the user experience or tripping host-based security mechanisms.
As the sophistication of malware continues to increase, capturing the
volatile data at the onset of an incident investigation is becoming critical to
identifying, tracking and remediating the threat. In fact, in some cases,
volatile memory analysis is the only way to identify, track and remediate the
threat.
Whether you are a law enforcement officer or a corporate security officer,
the analysis of memory within Windows systems should be a standard
procedure for all computer security incidents and digital investigations.
Without this analysis, you are leaving valuable evidence behind. Not only is
it important to quickly review the contents of memory structures, but it is
also important to be able to enumerate and export the malicious findings.
There are a number of tools on the market that allow you to acquire data,
but these tools do not necessarily allow you to analyze memory on the local
system, let alone remote systems across the network. Additionally, most of
them do not facilitate searching memory for specific artifacts. This paper
will discuss the importance of memory search and analysis with a focus on
Microsoft Windows hosts.
Volatile Memory Explained
Understanding how volatile memory operates is quite complex and cannot
be fully addressed in this white paper. However, a basic overview will help
the reader understand how Windows organizes its internal structures in
memory and how these structures can be manipulated to hide code and data
from both the user and the operating system.
Figure 1 shows how Windows represents the list of running processes. Each
process is represented by an _EPROCESS block. You will notice that
contained within each _EPROCESS block is both a pointer to the next
process (fLink – Forward Link) and a pointer to the previous process (bLink
– Back Link). When the operating system is operating normally, the
_EPROCESS blocks and their pointers come together to resemble a chain,
which is also known as a doubly-linked list. This chain is stored in kernel
memory and is updated every time a process is launched or terminated. The
Windows API walks this list from head to tail when enumerating processes
via Task Manager, for example.
Need versus Speed
As investigators, we now have established a need to acquire the entire RAM
image before the machine has been turned off. But oftentimes we run into
situations where there simply isn’t enough time to image the entire file
system. Memory analysis can solve both problems. Since acquiring memory
is far quicker than imaging the entire file system, taking a snapshot of
volatile data will provide an instant determination whether a full acquisition
is necessary. This leads into a discussion about having an entire image of
the file system as it existed compared to having a snapshot of the volatile
memory. This is an important conversation and certainly helps us determine
Need vs. Speed. Regardless of your position on this subject, we can all
agree that having access to the volatile data would without a doubt help out
in the investigation rather than not having the data from volatile memory.
Using AccessData Enterprise for Memory Search and Analysis
Building a functional and thoughtful workflow around memory acquisition
and memory analysis is critical to quickly and accurately resolving an
investigation or security breach. AccessData has developed a best practices
approach to acquiring live or dumped physical memory by parsing the
_EPROCESS blocks and enumerating all contents within volatile memory.
Recall the _EPROCESS block described above. Contained within each
process’ _EPROCESS block are several important items that describe the
process: its Process Identifier (PID), its Parent Process Identifier (PPID), the
list of loaded modules, etc. One of the most important parts of this structure
is the process’ Directory Table Base (DTB). This item helps the operating
system manage which physical memory pages belong to which process’
virtual memory space. AccessData technology uses the full memory image
and each process’ DTB to create a physical to virtual mapping, allowing
further analysis of the memory image to identify which process owns which
page of memory. Furthermore, the technology is also able to determine
whether that virtual address corresponds to the executable itself, a loaded
dll, or some other virtual address in the process’ virtual memory space—
likely a heap or stack. The workflow is captured in Figure 3 below. This
approach allows our technology to find\locate\capture rogue processes that
you would not otherwise be aware of.
Using the memory analysis feature makes AccessData’s hidden process
detection capabilities some of the strongest in the industry. By brute force
searching for _EPROCESS blocks, the kernel-level driver is able to identify
all processes running on the system regardless of whether they are included
in the _EPROCESS block chain. Then the results are compared against
Windows API and those processes that Windows is not aware of are labeled
as suspicious and highlighted, so the investigator can see what processes
are hidden from Windows. Additionally, the user has the ability to set up a
differential view of what is running in RAM, compared to an analysis taken
earlier in time.
An additional function of AccessData’s memory analysis capabilities is the
capability to search through all of memory for specific artifacts. This is also
an important aspect of the examination process since you can now search
through the binaries looking for artifacts that are not accessible through
other means. When performing incident response types of investigations,
this is important since more and more attacks are taking place in RAM only,
and without this capability an investigator would not normally find what
they are looking for.
The following key capabilities are critical when analyzing memory, and they
are all available in AccessData’s digital investigations technology:
· Memory capture and analysis of Windows operating systems, from
Windows 2000 to Vista SP1.
· Memory analysis is performed on the agent itself.
· The agent holds strings of data provided by the examiner, will find
responsive items, and then send them back to the examiner machine for
further analysis.
· The examiner can investigate the responsive items, and if the event is
found to be real, the examiner is given the ability to then fully acquire
memory from said target.
· The examiner can carve out individual files from volatile memory for
further analysis.
· Once the memory file is acquired, the investigator is given an easy-to-use
workflow, allowing for the easy entry of search criteria.
Conclusion
Since malware authors and other adversaries are no longer relying on the
file system to store and execute their data, the “pull-the-plug” procedure is
no longer an acceptable approach. Too much valuable data is lost that can
assist the investigator or incident responder in resolving a case.
Investigators are always being challenged to provide additional evidence
that would directly affect the results of the case or security incident. With
this said, the job of the investigator is becoming more and more complex,
and the industry requires tools that are feature rich, respond quickly to
complex tasks, and are easy to deploy and use. AccessData’s digital
investigations technology delivers a best practices approach to acquiring
live or dumped physical memory by finding and parsing the _EPROCESS
blocks and enumerating all content within volatile memory. With the release
of FTK 3 and AD Enterprise, AccessData is firmly at the forefront of
addressing these issues. The memory search and analysis capabilities now
available to FTK and AD Enterprise users have surpassed most other tools
on the market today.
