CH8: Windows Memory Forensics

Learning Objectives

By the end of this chapter, students will be able to:

Explain how the Windows operating system manages memory, including the roles of physical RAM, virtual memory, and paging.
Define the Order of Volatility (OOV) and explain why memory must be captured before non-volatile storage.
Identify the challenges of live acquisition, including the risk of data "smearing."
Compare different memory file formats (Raw, Crash Dump, E01) and their compatibility with analysis tools.
Utilize industry-standard tools like FTK Imager, Magnet RAM Capture, and FireEye Redline to acquire memory.
Analyze memory dumps using the Volatility 3 Framework to identify rogue processes, network connections, and injected code.
Differentiate between linked-list process monitoring (pslist) and pool tag scanning (psscan) to detect rootkits.

8.1 Introduction: The Volatile Frontier

In Chapter 7, we explored browser forensics to uncover a suspect's intent and history. However, investigating a powered-off computer misses a crucial dimension of evidence. Modern cybercrime is increasingly "fileless"; sophisticated malware often resides solely in Random Access Memory (RAM), never writing a payload to the disk to avoid detection by traditional antivirus software.

Memory forensics is the art of analyzing the volatile data of a computer. It allows an investigator to see exactly what the computer was "thinking" at the moment of capture: open windows, typed passwords, encryption keys, and active network connections.

8.1.1 Windows Memory Management Fundamentals

To analyze memory, you must first understand how Windows manages it. Students often imagine RAM as a simple bucket of data, but the Operating System (OS) uses a complex system called Virtual Memory.

Virtual Addressing: Windows does not give applications direct access to physical hardware. Instead, every process is given a virtual address space (a "Sandbox"). The CPU and the Memory Management Unit (MMU) translate these virtual addresses into physical addresses in the RAM chips.
Paging (pagefile.sys): Physical RAM is expensive and finite. When the OS runs out of physical RAM, it moves the least active data chunks (pages) from RAM to the hard drive. This file acts as an extension of RAM. From a forensic standpoint, the pagefile is a goldmine; it contains artifacts that were once in memory but were swapped out to disk, persisting even after a reboot.
Hibernation (hiberfil.sys): When a laptop enters hibernation, it takes the entire contents of RAM, compresses it, and writes it to hiberfil.sys on the root of the C: drive. This is essentially a snapshot of RAM on disk, allowing investigators to perform memory forensics on a powered-off machine.

8.1.2 The Forensic Treasure Trove: Artifacts in RAM

Before diving into how we capture memory, it is critical to understand what we are capturing. RAM contains the runtime state of the system, offering artifacts that simply do not exist on the hard drive. As an investigator, you can expect to recover the following types of evidence from a memory dump:

Active Processes and Drivers: Unlike a static list of installed programs, RAM reveals exactly what was running at the time of capture. This includes the process hierarchy (Process Tree), which helps identify anomalies like a system service spawning a command shell.
Network Artifacts: One of the most valuable aspects of memory forensics is the visibility of the network stack. You can recover active connections, listening ports, and closed sockets. This allows you to identify "beaconing" malware communicating with a Command and Control (C2) server, even if the connection is encrypted.
Decrypted Keys and Passwords: Many encryption tools (like BitLocker or TrueCrypt) must store their decryption keys in RAM to function. Investigators can extract these "mount keys" from memory to decrypt the hard drive. Similarly, users' passwords or authentication tokens are often temporarily stored in cleartext within memory buffers.
Command Line Arguments: When a user or script launches a program, they often pass arguments (e.g., net use or psexec). These arguments are stored in the process memory and can reveal exactly what the attacker was trying to do, such as the specific IP address they were targeting or the password they typed into the console.
Malicious Code Injection: Advanced malware often "injects" itself into legitimate processes (like notepad.exe or svchost.exe) to hide from security tools. While the hard drive only shows the legitimate notepad.exe file, the memory dump reveals the malicious code running inside it, often marked by suspicious permissions (Read-Write-Execute).
Unsaved Data: Documents, clipboard contents, and chat messages that were open but never saved to disk can often be carved from memory.

8.2 Acquisition: Capturing the Ghost

The first rule of digital forensics is usually "pull the plug" to preserve the state of the disk. However, if encryption is active (e.g., BitLocker), pulling the plug destroys the decryption keys stored in RAM, rendering the data permanently inaccessible. Therefore, Volatile Data Analysis must occur first.

8.2.1 The Order of Volatility (OOV)

The Order of Volatility dictates the sequence in which evidence should be collected, moving from the most fleeting data to the most permanent.

CPU Cache & Registers: Nanoseconds (impossible to capture without specialized hardware).
RAM / Routing Tables / Arp Cache: Disappears immediately upon power loss.
Temporary Files / Swap Space: May persist briefly.
Disk (HDD/SSD): Persists for years.
Archival Media (CD/DVD/Tape): Persists for decades.

8.2.2 The Problem of "Smearing"

Unlike a hard drive, which can be frozen in time, a running computer is constantly changing. As you run a tool to copy RAM, the OS is simultaneously writing new data to RAM. This can result in smearing, where the data changes during the copy process, potentially corrupting the structural integrity of the forensic image. While unavoidable in software-based acquisition, modern tools attempt to minimize this impact by using kernel-level drivers to "lock" pages or copy them at high speeds.

8.2.3 Acquisition Tools

There are several standard tools used to capture memory. Note that running any tool on a live system alters the evidence (Heisenberg's Uncertainty Principle applied to forensics). You must document precisely which tool you ran.

FTK Imager: A staple in the industry. It can capture memory from a live system and save it as a raw dump (.mem) or an AD1 file.
DumpIt: A lightweight command-line utility (often carried on a USB drive) that quickly dumps physical memory to a raw file.
Magnet RAM Capture: A free standalone tool designed to run with minimal footprint, capturing physical RAM with high reliability.
FireEye Redline: While primarily an analysis tool, Redline allows you to create a "Collector"—a portable script you can run on a suspect machine to capture memory and comprehensive system data (processes, drivers, hooks) for later analysis.

8.2.4 Memory Capture Formats

When performing the acquisition, you will encounter different file formats. The format you choose dictates which analysis tools you can use later.

Raw Memory Dump (.raw, .mem, .dd): This is the "gold standard" for compatibility. A raw dump is a bit-for-bit copy of the physical RAM, containing no headers, metadata, or compression. Because it is unadulterated, it works seamlessly with almost every analysis tool, including Volatility and Rekall. The downside is the file size; if the computer has 32GB of RAM, the file will be exactly 32GB.
Windows Crash Dump (.dmp): Windows has a built-in mechanism to save memory during a system crash (Blue Screen of Death). Investigators can sometimes force a system crash (using keyboard commands or specialized tools) to generate a .dmp file. While useful for debugging, these files require specific conversion or valid symbol tables to be read by standard forensic tools.
Hibernation File (hiberfil.sys): As mentioned in section 8.1.1, this is a compressed file created by the OS. It is not a "capture" format in the traditional sense, but it is a valid source of memory evidence. However, you cannot feed a raw hiberfil.sys directly into most analysis tools. It must first be decompressed and converted to a Raw format using a utility (like Volatility's imagecopy plugin).
EnCase / Forensic Containers (.E01, .AD1): Commercial tools like FTK Imager or EnCase often wrap the memory dump in an evidence container. These formats are excellent for chain of custody because they include embedded metadata (Case Number, Examiner Name) and integrity hashes. However, open-source tools like Volatility often struggle to read the proprietary headers of .E01 files directly. If you acquire in this format, you may need to convert the image back to Raw for deep analysis.

8.3 Analysis Frameworks: Redline and Volatility

Once you have acquired a raw memory dump (e.g., memdump.raw), you cannot simply open it in a text editor. You need tools that understand the data structures of the Windows OS.

8.3.1 FireEye Redline

FireEye Redline is a user-friendly, GUI-based tool utilized for memory analysis and threat hunting. It is excellent for beginners because it visually reconstructs the system state.

MRI (Malware Risk Index): Redline scores processes based on suspicious behavior, helping investigators prioritize what to look at.
Timeline Analysis: It visualizes when processes started, aiding in the reconstruction of an infection timeline.
Hierarchical View: It automatically displays parent-child process relationships, making it easier to spot anomalies (e.g., cmd.exe spawned by calc.exe).

8.3.2 The Volatility Framework (Volatility 3)

While Redline is powerful, Volatility is the industry standard for deep-dive memory forensics. It is a command-line framework written in Python that allows forensic examiners to extract practically any artifact from a memory image.

We will focus on Volatility 3, the modern iteration of the framework. One of the major improvements in Volatility 3 is the elimination of manual profile selection.

How Volatility 3 Works (Symbol Tables): Instead of forcing the user to guess the operating system version, Volatility 3 uses "Symbol Tables." When you run a plugin against a memory dump, the framework automatically scans the image to identify the kernel version. It then downloads the appropriate symbol table (a map of the OS structures) from the Microsoft Symbol Server or uses a local cache. This allows for a much faster and more user-friendly workflow compared to previous versions.

Note on Legacy Volatility 2: In professional environments, you may still encounter the older "Volatility 2." The primary difference you will notice is the requirement for Profiles. In Volatility 2, you must first run a plugin called imageinfo to identify the specific Service Pack and Build number (e.g., Win7SP1x64). You must then manually type this profile into every subsequent command. If you choose the wrong profile, the output will be gibberish. Volatility 3 removes this friction entirely.

8.4 Investigating Processes

The most common goal in memory forensics is identifying malware running as a process.

8.4.1 The Process List (`windows.pslist`)

The OS tracks running programs using a doubly linked list. The windows.pslist plugin walks this list, showing every active process, its Process ID (PID), and its Parent Process ID (PPID).

What to look for:

Typosquatting: svch0st.exe vs svchost.exe.
Odd Paths: System binaries running from C:\Temp\ or C:\Users\.

8.4.2 Finding Hidden Processes (`windows.psscan`)

Advanced malware (Rootkits) can use DKOM (Direct Kernel Object Manipulation) to "unlink" themselves from the active process list. This makes them invisible to Task Manager and pslist.

However, the process data structure still exists in memory; it just isn't in the list. The windows.psscan plugin ignores the list and scans the entire memory range looking for "Pool Tags"—byte signatures that mark the start of a process object (like ProC or Proc).

The Discrepancy: If psscan finds a process that pslist does not, you have likely found a rootkit.

8.4.3 The Process Tree (`windows.pstree`)

Malware often creates a distinct "Process Tree" structure. The windows.pstree plugin visualizes the parent-child relationships.

Anomaly: services.exe should be the parent of svchost.exe. If you see explorer.exe (the user desktop) spawning svchost.exe, it is almost certainly malware.

8.5 Network and Code Artifacts

8.5.1 Network Connections (`windows.netscan`)

Since the capture is of a live system, the network stack is visible. The windows.netscan plugin recovers active connections, listening ports, and closed sockets.

Investigative Value: You can see exactly which IP address a suspect process is communicating with. This is crucial for attribution.

8.5.2 Code Injection (`windows.malfind`)

Malware often injects malicious code into legitimate processes (like notepad.exe) to hide. The windows.malfind plugin scans for memory pages with RWX (Read, Write, Execute) permissions.

Why it matters: Legitimate Windows memory pages are usually Read-Execute (for code) or Read-Write (for data). A page that is both Writable and Executable is highly suspicious, often indicating a hollowed process or shellcode injection.

8.5.3 The Command Line (`windows.cmdline`)

Finding the malware process is step one. Finding how it was launched is step two. The windows.cmdline plugin extracts the exact arguments passed to the executable.

Example: You might see nc.exe. Is it malicious? cmdline reveals: nc.exe -l -p 8080 -e cmd.exe. This confirms it is a listener (backdoor) offering a command shell to anyone who connects.

8.6 Reference: Volatility 3 Plugin Table

Below is a reference table for the most critical Volatility 3 plugins you will use in your labs.

Category	Plugin Name	Description	What to Look For
Info	`windows.info`	Identifies the OS version, architecture, and kernel base.	Used to verify the memory image was successfully recognized.
Processes	`windows.pslist`	Lists running processes by walking the active process links.	Standard process viewing. Look for known malware names.
Processes	`windows.psscan`	Scans memory for EPROCESS blocks (pool scanning).	Processes found here but missing in `pslist` are hidden (Rootkits).
Processes	`windows.pstree`	Displays processes in a parent-child tree format.	Anomalies in hierarchy (e.g., `cmd.exe` spawned by `winword.exe`).
Network	`windows.netscan`	Scans for network connections and sockets.	Connections to known C2 (Command & Control) IPs; listening ports on non-servers.
Malware	`windows.malfind`	Scans for injected code/shellcode (VADs with RWX permissions).	Any output here requires immediate investigation. Look for "MZ" headers in the hex dump.
Malware	`windows.ldrmodules`	Detects unlinked DLLs.	DLLs that are loaded but hidden from the process loader list.
Registry	`windows.registry.hivelist`	Lists registry hives present in memory.	locating `NTUSER.DAT` or `SAM` hives for password/hash extraction.
Files	`windows.filescan`	Scans for file objects in memory.	Can find open file handles, helping associate a process with a specific file on disk.
System	`windows.cmdline`	Lists process command-line arguments.	Malicious arguments (e.g., PowerShell encoded commands).
System	`windows.getsids`	Displays the SIDs (Security Identifiers) associated with a process.	identifying which user account is running a specific malicious process.

8.7 Chapter Summary

Memory forensics changes the game from "what happened?" to "what is happening?". By capturing RAM, we secure the most volatile and often the most valuable evidence available—encryption keys, network connections, and fileless malware. However, the investigator must be careful. The act of observing the memory changes it, and tools like Redline and Volatility are required to translate the raw binary of a memory dump into a coherent story of user activity and system compromise.

Key Terms Review

Order of Volatility: The sequence of capturing evidence from most fleeting to most permanent.
Smearing: Data corruption caused by the contents of RAM changing while it is being imaged.
DKOM: Direct Kernel Object Manipulation, a technique used by rootkits to hide processes.
RWX: Read-Write-Execute permissions, a primary indicator of code injection.
Pagefile: A file on the hard drive that serves as an extension of physical RAM.