Digging through memory can be an effective way to identify indicators of compromise.  Malware that leverages rootkit techniques can fool many tools that run within the OS.  Malware authors have ways of hiding their malicious code from various Windows data structures which can help them avoid detection.  A trivial example of this is when malware removes itself from the _EPROCESS doubly linked-list, this causes the process to not show up in Task Manager, but since the process still has threads in memory it will still run.

Memory forensics normally compliments my static/dynamic malware analysis to help me understand the malicious code.  I also find analyzing raw memory dumps useful to answer the question “Is this box pwnd?”  Throughout this blog post I hope to give you the knowledge necessary so you’ll be able to dive into memory dumps and pull out some evil.

By analyzing memory you can detect the following:
– Running Processes
– Passwords/Encryption Keys
– Unpacked/decrypted PEs
– Registry Hives
– File/web page artifacts
– Previously typed commands

Creating a Raw Memory Dump:

First a raw memory image must be created from the system. This involves taking what is running in RAM and saving it to a file called a memory dump. In Windows, memory is managed in both physical RAM and virtual memory through the use of a paging file. It’s important to note that you will only be dumping memory from physical memory (RAM). It is possible that some of the interesting memory segments will be in virtual memory (page file) and won’t be captured in your physical memory dump.

There are several methods you can leverage for memory dump acquisition:
– Monsools Win32dd/Win64dd
– FTK Imager
– VMware snapshots (.vmem file) = raw memory image.
VirtualBox (.sav file) = partial image
– Cuckoo Sandbox can be leveraged to automatically get a memory dump
– memdump for Linux systems

Below is a screen shot of using Monsools Win32dd:

Memory Analysis Techniques:

Now that we have acquired our memory dump we can go through some use cases for pulling out indicators of compromise and other interesting information.

Searching for Strings: strings, and yarascan

Running strings on the memory dump combined with Linux utilities like (grep/egrep) could yield some quick wins.  Leveraging Volatility’s yarascan module can be a more effective way to search for strings across a memory dump because it will tell you which process had the string match.  The yarascan module can be invoked with a string given as a CLI argument with switch “-Y” or pulled in from a YARA rule file with switch “-y”.  Below we are searching the memory to identify network activity by looking for ‘URL ‘ or ‘REDR’ or ‘LEAK’:

Traditionally YARA signatures are distributed and leveraged via YARA rule files.  They have a very simple syntax, but can increase in complexity depending on the type of rule.  YARA signatures can flag for specific strings or even hex values within a file.  Below is a simple example of some YARA signatures.  You can define what you want to look for under the “strings” heading and then the Boolean logic under the “condition” heading:

Now with this rule file created “y.yara” we can scan the memory image using the yarascan Volatility module:

Process Enumeration:  pslist, psscan, and psxview

Enumerating running processes is one of the first things I do when digging through a memory dump.  This can give you an idea of what was running on a system, but also can serve as a good reference as you continue to dig deeper into the memory sample.  There are a few ways to enumerate processes in a memory dump using Volatility: pslist, psscan, and psxview:

Pslist will walk the _EPROCESS data structure and list processes the same way task manager shows running processes.  Psscan will scan for _EPROCESS pool tags and not rely on the kernel data structure.  Psxview gives you a comparison of various process enumeration techniques to help you identify variances.

Pslist output (similar to Task Manager/tasklist within the OS):