Memory Forensics: What’s Really Running Under the Hood

Category: Digital Forensics

Tags: memory-forensics, volatility, ram-analysis, malware-analysis, process-injection

Disk forensics tells you what was saved. Memory forensics tells you what was running. The distinction matters because modern malware increasingly operates entirely in memory -- fileless attacks, reflective DLL injection, process hollowing -- leaving minimal traces on disk. If the only forensic evidence you collect is the hard drive, you are examining the crime scene with the lights off.

This article covers the practical workflow for memory forensics using Volatility 3 -- from acquisition through process analysis, injection detection, and rootkit hunting. The goal is to find what the disk cannot tell you: active network connections, running code that was never written to a file, and processes that are actively hiding from the operating system.

Memory Acquisition

Before you can analyse memory, you need to capture it. The methods vary by platform, and timing matters -- memory is volatile by definition.

Windows

# WinPmem (command line)
winpmem_mini_x64.exe output.raw

# DumpIt (just run it)
DumpIt.exe

Linux

# LiME (Linux Memory Extractor) -- kernel module
sudo insmod lime.ko "path=/tmp/mem.lime format=lime"

Virtual Machines

For VMs, memory acquisition is often trivial:

• VMware -- suspend the VM and grab the .vmem file. The .vmss (suspended state) and .vmsn (snapshot) files also contain memory.
• Hyper-V -- checkpoint the VM; the .bin file contains memory.
• Proxmox/QEMU -- use virsh dump or the monitor command dump-guest-memory.

The golden rule: acquire memory before shutting down or rebooting the system. Every reboot destroys volatile evidence that no amount of disk forensics can recover.

Volatility 3 -- The Framework

Volatility 3 is a complete rewrite of the original Volatility framework. It auto-detects the operating system (no more profile guessing), uses a cleaner plugin architecture, and handles Windows, Linux, and macOS memory images.

First Steps

# System information -- confirms the image is valid
vol -f mem.raw windows.info

# Quick triage -- what's running?
vol -f mem.raw windows.pslist
vol -f mem.raw windows.pstree

Process Analysis

Process analysis is the foundation of memory forensics. The goal is to identify processes that should not exist, processes that are hiding, and processes that have been tampered with.

Listing Processes

# Standard process list (walks the EPROCESS linked list)
vol -f mem.raw windows.pslist

# Process tree (shows parent-child relationships)
vol -f mem.raw windows.pstree

# Pool scan (finds processes NOT in the linked list -- hidden or terminated)
vol -f mem.raw windows.psscan

The critical technique: compare pslist with psscan. Anything that appears in psscan but not in pslist has been unlinked from the process list -- it is either terminated or actively hiding. Both are interesting.

Process Red Flags

Command Line Analysis

# What arguments were passed to each process?
vol -f mem.raw windows.cmdline

This reveals the full command line for every running process. PowerShell with -EncodedCommand and a long base64 string is not something the IT department scheduled. cmd.exe /c whoami && net user && ipconfig /all running as a child of an Office application is the signature of an attacker's first minutes on a system.

Code Injection Detection

Process injection -- inserting code into a legitimate process to execute under its identity -- is one of the most common malware techniques. Memory forensics is often the only way to detect it.

Malfind

# Find injected code sections
vol -f mem.raw windows.malfind

Malfind identifies memory sections with suspicious characteristics:

• PAGE_EXECUTE_READWRITE (RWX) protection on regions not backed by a file on disk
• MZ headers in injected sections -- a full PE file injected into another process
• Shellcode patterns -- 0xfc (CLD instruction), 0xe8 (CALL), NOP sleds

When malfind flags a process, dump the suspicious region and scan it:

# Dump flagged sections
vol -f mem.raw windows.malfind --dump

# Scan with YARA rules
yara -r malware_rules.yar pid.*.dmp

Common Injection Techniques

Network Analysis

Memory contains the state of all network connections at the time of acquisition -- including connections that have since closed and would not appear in a live netstat.

# All network connections and listening ports
vol -f mem.raw windows.netscan

# Cross-reference with process list
vol -f mem.raw windows.netscan | grep ESTABLISHED

For each suspicious connection, note the PID and cross-reference it with pslist and cmdline. A svchost.exe instance with an established connection to an IP address in a country where the organisation has no business is worth investigating further.

DLLs and Handles

Loaded DLLs

# DLLs loaded by a specific process
vol -f mem.raw windows.dlllist --pid 1234

Look for DLLs loaded from unusual paths -- legitimate system DLLs live in C:\Windows\System32\. A DLL loaded from C:\Users\Public\ or C:\ProgramData\ warrants immediate attention.

Open Handles

# All handles for a process
vol -f mem.raw windows.handles --pid 1234

# Filter by type
vol -f mem.raw windows.handles --pid 1234 -t File
vol -f mem.raw windows.handles --pid 1234 -t Key
vol -f mem.raw windows.handles --pid 1234 -t Mutant

Mutex (Mutant) handles are particularly useful -- many malware families use hardcoded mutex names to prevent multiple infections. A known-malware mutex name is a definitive indicator.

Registry in Memory

The registry is loaded into memory and can be examined without the on-disk hive files.

# List loaded registry hives
vol -f mem.raw windows.registry.hivelist

# Check Run keys (persistence)
vol -f mem.raw windows.registry.printkey \
    --key "Software\Microsoft\Windows\CurrentVersion\Run"

vol -f mem.raw windows.registry.printkey \
    --key "Software\Microsoft\Windows\CurrentVersion\RunOnce"

Services and Drivers

# Enumerate services
vol -f mem.raw windows.svcscan

# Kernel drivers (rootkit detection)
vol -f mem.raw windows.driverscan

# SSDT hooks (System Service Descriptor Table)
vol -f mem.raw windows.ssdt

Rootkits that hook the SSDT redirect system calls through their own code. If ssdt shows entries pointing outside ntoskrnl.exe or win32k.sys, something has modified the kernel's system call table.

File Extraction

# Scan for file objects in memory
vol -f mem.raw windows.filescan

# Dump a specific file by virtual address
vol -f mem.raw windows.dumpfiles --virtaddr 0xfa8001234567

This can recover files that were opened and then deleted -- the file object persists in memory even after the disk entry is removed.

Investigation Playbook

A structured approach to memory forensics ensures consistent, thorough analysis:

Step 1: Identify Rogue Processes

vol -f mem.raw windows.pstree      # visual hierarchy
vol -f mem.raw windows.psscan      # find hidden processes
# Diff: anything in psscan but not pslist is hiding

Step 2: Check for Injection

vol -f mem.raw windows.malfind     # RWX regions without file backing
vol -f mem.raw windows.malfind --dump

Step 3: Examine Network Connections

vol -f mem.raw windows.netscan     # active and closed connections
# Cross-reference suspicious PIDs with pslist and cmdline

Step 4: Check Persistence

vol -f mem.raw windows.registry.printkey --key "Software\Microsoft\Windows\CurrentVersion\Run"
vol -f mem.raw windows.svcscan     # installed services

Step 5: Extract Evidence

vol -f mem.raw windows.cmdline     # command history
vol -f mem.raw windows.dlllist --pid <suspicious>
vol -f mem.raw windows.dumpfiles --virtaddr <offset>

Volatility 2 vs 3

Use Volatility 3 for all new analysis. Volatility 2 remains useful for older memory images or when specific Vol2-only plugins are needed (some community plugins have not been ported).

What's Next in the Series

• Malware Analysis 101: The Workflow -- analyse the extracted malware samples
• Windows Forensics 102: Execution Artifacts -- correlate disk artifacts with memory findings
• Incident Response 102: Evidence Preservation -- proper acquisition procedures
• Timeline Analysis -- integrate memory findings into the incident timeline