Insights Blog

Windows Memory Forensics

As part of out newest 2016 R1 release, BlackLight now has support for performing Windows memory analysis. In light of this arguably underutilized type of analysis, we thought it would be a splendid idea to share some background info on memory forensics in general, as well as how to utilize it within BlackLight. This blog entry will serve as the first in a series, as we plan to publish additional posts on memory forensics in the near future.


Forensic Benefits of Memory Files

First, let’s examine the purpose and benefits of memory forensics. Why would an examiner want to use it? There are many reasons why examiners should be leveraging memory forensics in any cases where they have access to memory images. Below are just a few of them. [It was in composing this section that one of our resident memory experts, Vico, literally began by writing, “O memory forensics, how do I love thee? Let me count the ways…” While this line was deleted, it speaks to his – and our – level of passion for the subject matter. – Ed.]

1) Every bit of data being created, viewed, or destroyed goes through RAM. This includes all web-browsing activity, document edits, images, sending and receiving of network data, execution of applications, and essentially anything that appears on the monitor.
2) Because the OS and applications use RAM as a cache, or staging ground for data, some artifacts in RAM are newer than their disk-based versions. Recent document edits, updates to the NTFS MFT and Windows Registry, and any other current application-specific data being used are all updated in RAM first, and then sometime later, flushed to disk. A recent example of this behavior is the operation of the Windows “shimcache,” which is an application compatibility layer that, importantly from a forensics perspective, records when applications are executed. These shimcache artifacts are only flushed from RAM on system reboot, so traditional disk-based tools can present information that is wildly outdated if the machine under investigation is being live-imaged and hasn’t been rebooted recently. (See this excellent article for more details.) A plugin for the Volatility Memory Forensics Framework that parses shimcache data from memory recently won the Volatility Foundation’s annual plugin contest.
3) Some types of artifacts only exist in RAM. Many types of ephemeral OS artifacts are never stored to disk, like what applications are currently running, what files and network connections are currently open, or what drivers (e.g., modules, DLLs, etc.) are loaded. These artifacts can tell us if malware, anti-forensics tools, or encryption software was running, if the machine had open network connections to known bad websites, or what picture files a viewer application had open. Also important is a strengthening trend in malware development that focuses on memory-resident-only malware. These malicious programs infect a machine in memory, often over a network connection, and never write any information to disk, making them invisible to standard disk-based forensics.
4) Many types of memory-resident-only data can be acquired with tools run on a live system, e.g., the Sysinternals suite for Windows systems. Malware authors, however, know that these types of tools exist and that they can detect malicious behavior. For this reason, modern malware can corrupt data structures in the OS kernel to make the tools lie about what’s actually happening on the machine. For example, a common technique called Direct Kernel Object Manipulation (DKOM) can be used to hide specific processes that are running. It works like this: the Windows kernel keeps track of running processes in a list in memory. When Task Manager (or another application that lists running processes) executes, it consults this list to display running processes. Malware exploits the trust in the list by simply reaching into OS memory and removing applications from the list that it doesn’t want reported to the user – and yes, the hidden program can continue to execute normally.
5) For a user to access encrypted content, it must be decrypted in RAM. This is true for HTTPS/SSL/TLS web transactions, OTR chat sessions, and built-in and third-party file and full disk encryption (FileVault, BitLocker, TrueCrypt, .zip, .rar, etc.). In most cases the encryption keys themselves are also loaded into RAM in a usable format.
6) RAM is effectively a “disk,” so why wouldn’t you preserve and investigate?

Memory Files in BlackLight

Hopefully now you’re convinced of the benefits, but how does all of this work in practice? Let’s take a look using BlackLight.

First off, open a new case and select the green Add button in the ‘Component List,’ choose [Add Memory (Dump, Image, File)…] and select a memory image. If you don’t have a sample image to use, there are a number of tools listed here that can help you obtain one. We also plan to discuss memory image acquisition further in a forthcoming post. Most of the screenshots below were taken using the memory image publicly available here.


Once a memory image is selected, the examiner is presented with the same ‘Evidence Selection’ window as when adding other types of evidence into BlackLight. Activate the checkbox for Advanced Processing Options, and then select the Settings… button. A separate window opens.


Here the examiner has the option to run a content search on the memory file with either the Quick Scan option, which is faster and searches the most likely locations, or the Deep Scan option, which takes more processing time and searches in additional locations less likely to yield content. Choose the desired option and select the OK button.

Note: BlackLight requires Microsoft symbols in order to process Windows memory files. For more details on the various options for accessing these symbols, please refer to the ‘Adding a Memory File’ subsection of Chapter 3 in the BlackLight User Guide.

After selecting the desired options, the memory image is added to the case and processed. BlackLight parses and displays several interesting types of data about the state of the system when the memory image was captured. To analyze them, go to the ‘System’ view and select the Memory button.

First, we’ll look at a hierarchical listing of the processes running on the system. The hierarchy is based on the parent-child relationships of the processes, that is, what processes spawned or were spawned by which other processes. We can see the name of each process, its process identifier (PID), the time the process started executing, and the full path to the process executable.


Scrolling to the right, we see even more data about each process, including the current working directory of the process, the actual command line invocation of the process with the arguments used, the user that owns the process, and whether or not BlackLight detected any process-hiding attempts (e.g., DKOM as discussed above).


Next we take a look at the libraries loaded on the system at the time of the memory image capture. Select the Libraries button. For every DLL loaded we see its name, the process it was loaded into, the full on-disk path to the library, and sometimes a description string.


Changing focus a bit, we can then take a look at all of the network connections on the machine. Select the Sockets button. For each network connection, we can see the owning process name and identifier, the local and remote IP address and port, the network protocol the connection is using and the state of the connection.


Another incredibly interesting artifact we can analyze is the list of open handles on the system. Select the Handles button. “Handle” is a generic term for some type of object that has been opened on the system. This can be a file, network connection, thread, or one of a few dozen other types. For each handle we can see the owning process, the type of handle (e.g., “Key” means this handle is for a Registry key), a description of the handle and the owner (user) of the handle. Because there are so many types, it often helps to filter the output in BlackLight to a specific type at a time.


In the following screenshot we can see the list of handles filtered to just those of the type “File.” This listing contains entries for every file opened by every process on the system.


We can similarly filter for Registry key handles, or, as in the next screenshot, Windows mutants, which are often used by malware to signal that a machine has already been infected.


There are many, many handle types, some being more useful than others from a forensic standpoint. The full list of types is shown in the following screenshot.


Let’s move on to system drivers, both loaded and unloaded. Select the Drivers button. For each driver found in the memory image we see its name, the time it was unloaded (if it was in fact unloaded), the full path to the driver on disk, and its current state, loaded or unloaded.


Now that we’ve completed a whirlwind tour of why you should be using memory forensics in investigations, and the basics of what types of artifacts are available for exploration in BlackLight, we hope you’re hungry for more. For the next blog entry in this series, we’ll take a deep dive into memory image acquisition tools, techniques and image file formats. Until then, carpe datum!

BlackBag Training Team
Latest posts by BlackBag Training Team (see all)