Volatility 3 — Memory Forensics

Memory forensics reveals what disk-based tools cannot see — injected code, in-memory beacons, credential material, and network connections from processes that never touched the filesystem.

Volatility 3 — Memory Forensics

The tool that sees what disk forensics cannot

The attacker used process injection. Their code is running inside a legitimate Windows process — no file on disk, no Prefetch entry, no AmCache record. Disk forensics sees a clean system. Memory forensics sees the injected code, the C2 connection, the stolen credentials, and the encryption keys. If your toolkit does not include memory analysis, you are blind to an entire category of attack. Volatility 3 is how you gain that visibility.

Memory forensics analyzes the contents of a system's RAM at a specific point in time. Where disk forensics examines persistent artifacts — files, registry hives, event logs — that survive a reboot, memory forensics examines volatile state: the information that exists only while the system is powered on and disappears permanently when the system shuts down.

Modern attacker tooling has made memory forensics essential rather than optional. The most widely used commercial penetration testing and red team frameworks — Cobalt Strike, Sliver, Brute Ratel C4, Havoc — operate primarily in memory. The standard attack pattern is reflective DLL injection (T1055.001): the attacker's implant is loaded directly into the memory space of a legitimate process (svchost.exe, rundll32.exe, explorer.exe) without writing a file to disk. The implant executes in memory, communicates with the attacker's command-and-control server, exfiltrates data, and provides remote access — all without creating any persistent disk artifact that KAPE, EZTools, or event log analysis would detect.

This is not theoretical. The majority of sophisticated intrusions investigated by professional IR firms in 2024-2025 involve memory-resident implants. Ransomware operators use Cobalt Strike beacons for initial access and lateral movement before deploying the encryption payload. APT groups use custom in-memory implants that persist only in RAM. Even commodity malware increasingly uses process injection to evade antivirus and endpoint detection.

The evidence that proves these attacks exists only in memory:

Running processes with their full command lines. The process list shows what was executing at the time of capture. PsList reveals the process hierarchy. PsTree shows parent-child relationships. CmdLine shows the exact arguments. A svchost.exe process with an unusual parent (PowerShell instead of services.exe) or unusual command-line arguments is immediately suspicious — but this information exists only in the live process state.

Active network connections with owning process. NetScan maps every network connection to the process that owns it. A svchost.exe process maintaining an outbound HTTPS connection to an IP address in an unexpected geography — that is the C2 channel. This mapping between process and connection exists only in memory. Disk-based network logs (if they exist) show the connection but often cannot attribute it to a specific process.

Injected code. Malfind identifies memory regions that have suspicious characteristics: memory pages marked as both writable and executable (PAGE_EXECUTE_READWRITE) that were not loaded from a legitimate file on disk. In a normal Windows process, executable code comes from DLLs loaded from disk — those memory pages are read-only and executable, not writable. When Malfind finds writable+executable memory that does not correspond to a legitimate DLL, it has likely found injected malicious code.

Encryption keys and credentials. LSASS (Local Security Authority Subsystem Service) holds cached credentials, Kerberos tickets, and NTLM hashes in memory. The attacker's tools (Mimikatz, Rubeus, pypykatz) extract these from LSASS memory. Volatility 3 can recover the same artifacts — meaning the investigator can determine what credentials the attacker obtained, which informs the scope of the compromise and the containment strategy.

Volatility 3: the framework

Volatility 3 is the most widely used open-source memory forensics framework. It was created by the Volatility Foundation and is maintained as a community-driven project with contributions from DFIR practitioners worldwide. Volatility 3 is a complete rewrite in Python 3 of the original Volatility Framework (Volatility 2, which used Python 2 and is now end-of-life). The rewrite brought significant improvements in speed, usability, and cross-platform support.

The most important improvement for investigators is the elimination of profiles. Volatility 2 required the investigator to manually identify the exact Windows version and service pack of the memory dump before analysis could begin — selecting from hundreds of profiles, with analysis failing silently if the wrong profile was chosen. Volatility 3 uses ISF (Intermediate Symbol Format) symbol tables that are automatically downloaded from Microsoft's symbol servers based on the memory dump's kernel version. The investigator runs the command; Volatility 3 identifies the OS version and fetches the correct symbols automatically. This removes the most common source of error in memory forensics.

Volatility 3 supports memory dumps from Windows (XP through Windows 11 and Server 2022), Linux, and macOS. It accepts multiple dump formats: raw dumps (.raw, .dd, .mem), Windows crash dumps (.dmp), hibernation files (hiberfil.sys), and EWF compressed images (.E01). The plugin architecture is extensible — the community publishes plugins for new analysis techniques, and investigators can write custom plugins for case-specific analysis.

Installation

Volatility 3 requires Python 3.8 or later (Python 3.10+ recommended). Install in a dedicated virtual environment to isolate Volatility's dependencies from the system Python and from other tools.

# Step 1: Verify Python is installed (3.10+ recommended)
python --version
# If not installed: download from python.org
# During installation, CHECK "Add Python to PATH"

# Step 2: Create a dedicated directory and virtual environment
New-Item -ItemType Directory -Path "C:\IR\Tools\Volatility3" -Force
Set-Location "C:\IR\Tools\Volatility3"
python -m venv venv

# Step 3: Activate the virtual environment
.\venv\Scripts\Activate.ps1
# Prompt changes to (venv) indicating the virtual environment is active

# Step 4: Install Volatility 3
pip install volatility3
# This installs Volatility and all dependencies

# Step 5: Verify the installation
vol --help
# Expected: Volatility 3 Framework version and available commands
# The help output lists all available plugins organized by OS

# Alternative: install from GitHub source (for latest development version)
# git clone https://github.com/volatilityfoundation/volatility3.git
# cd volatility3
# pip install -e .

Symbol tables. Volatility 3 needs symbol tables (PDB files) to interpret the memory structures of the specific Windows build. On first use against a new OS version, Volatility 3 downloads the required symbols from Microsoft's symbol servers automatically. This requires an internet connection during the first analysis of each OS version. After download, symbols are cached locally and reused.

For air-gapped forensic workstations, pre-download the Windows symbol pack:

# Pre-download Windows symbol tables for offline analysis
# Download from: https://downloads.volatilityfoundation.org/volatility3/symbols/windows.zip
# Extract to the symbols directory:
# C:\IR\Tools\Volatility3\venv\Lib\site-packages\volatility3\symbols\

# Verify symbols are available
$symbolPath = "C:\IR\Tools\Volatility3\venv\Lib\site-packages\volatility3\symbols"
$winSymbols = Get-ChildItem $symbolPath -Recurse -Filter "*.json.xz" -ErrorAction SilentlyContinue
Write-Host "Symbol files available: $($winSymbols.Count)" -ForegroundColor $(if ($winSymbols.Count -gt 0) { 'Green' } else { 'Yellow' })
# The symbol pack is 200-400 MB and covers all Windows versions

Memory acquisition: capturing the dump

Volatility 3 analyzes memory dumps — it does not capture them. A separate acquisition tool creates the dump file from a live system. Memory acquisition must happen before any containment action that might cause evidence loss (system restart, network isolation that terminates processes, or attacker detection that triggers anti-forensic wipes).

WinPMem — recommended free acquisition tool. Developed by the Velocidex team (the same team that builds Velociraptor). Creates raw memory dumps from live Windows systems. Portable — runs from USB without installation. Requires Administrator privileges because memory acquisition requires kernel-level access.

# Download WinPMem from:
# https://github.com/Velocidex/WinPmem/releases
# Save to C:\IR\Tools\Volatility3\winpmem.exe
# Also copy to the jump bag USB (IR1.8)

# Capture memory from the local system (for testing/validation)
# Run as Administrator
Set-Location "C:\IR\Tools\Volatility3"
.\winpmem.exe "C:\IR\Evidence\TEST_memory.raw"

# Expected behavior:
# WinPMem loads a kernel driver to access physical memory
# Reads all physical RAM pages and writes to the output file
# Duration: 2-10 minutes depending on RAM size and disk speed
# Output size: equals physical RAM (16 GB RAM → 16 GB dump file)
# The dump file is a complete snapshot of RAM at capture time

Alternative acquisition tools:

DumpIt — a single-click memory dumper. Double-click the executable, press Y to confirm, and it creates a dump in the same directory. Useful for non-technical onsite contacts — the simplest possible acquisition workflow.

Belkasoft RAM Capturer — free GUI-based acquisition tool. Provides a graphical interface that shows acquisition progress. Useful when handing the tool to someone who is uncomfortable with command-line tools.

Velociraptor — can trigger memory acquisition on a remote endpoint through the agent (using the Windows.Memory.Acquisition artifact). The dump uploads to the Velociraptor server. This combines remote acquisition with the Velociraptor workflow from IR1.4 — no physical access to the endpoint required.

Defender XDR Live Response — can collect a memory dump from a managed endpoint remotely using the run memorydump command in a Live Response session. The dump downloads through the Defender portal.

The critical rule: capture memory FIRST. Memory is the most volatile evidence source. Every second that passes after detection, memory is being overwritten — processes terminate, network connections close, the attacker may detect investigation activity and wipe their implant. The evidence collection priority from the jump bag checklist (IR1.8) places memory capture before all other collection: Memory → Network connections → KAPE triage → M365 audit export → Full disk image.

The investigation workflow: how to analyze a memory dump

Memory analysis in Volatility 3 follows a structured workflow. This is the workflow taught in IR6 and used in every Phase 4 scenario that involves memory evidence.

Step 1: Image identification. Confirm the dump is valid and identify the OS version.

# Activate the Volatility 3 environment
Set-Location "C:\IR\Tools\Volatility3"
.\venv\Scripts\Activate.ps1

# Identify the memory image
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.info.Info

# Output: OS version, kernel build, system time at capture
# This confirms the dump is valid and Volatility can parse it
# If symbols are needed, they download automatically at this step

Step 2: Process analysis — what was running.

# List all processes (equivalent to Task Manager but forensic-grade)
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.pslist.PsList
# Output: PID, PPID, ImageFileName, Offset, Threads, Handles, CreateTime, ExitTime
# Look for: unexpected process names, unusual parent-child relationships,
# processes running from temp directories, processes with exit times (terminated)

# Show the process tree — parent-child hierarchy
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.pstree.PsTree
# The tree view reveals suspicious hierarchies:
# explorer.exe → powershell.exe → cmd.exe (normal admin activity)
# outlook.exe → powershell.exe → cmd.exe (phishing payload execution)
# svchost.exe → cmd.exe (unusual — svchost rarely spawns cmd)

# Scan for hidden processes (rootkit detection)
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.psscan.PsScan
# PsScan searches memory for process structures rather than walking
# the kernel's process linked list. A process that appears in PsScan
# but NOT in PsList has been hidden (unlinked from the list) — this
# is a strong indicator of rootkit activity (T1014)

# Show command-line arguments for every process
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.cmdline.CmdLine
# Reveals the exact commands used to launch each process
# A powershell.exe with "-nop -w hidden -enc <base64>" is
# almost certainly attacker activity — legitimate PowerShell
# rarely uses encoded commands with hidden windows

Step 3: Network analysis — what was communicating.

# List all network connections with owning process
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.netscan.NetScan
# Output: Protocol, LocalAddr:Port, ForeignAddr:Port, State, PID, Owner
#
# Investigation workflow:
# 1. Find connections to unexpected external IPs
# 2. Map each suspicious connection to its owning process (PID)
# 3. Look up that PID in the PsList output
# 4. If the process is svchost.exe connecting to a VPS IP on
#    port 443 — that is likely a C2 channel
# 5. Check the process's parent in PsTree
# 6. Check the process's command line in CmdLine
# 7. Run Malfind against the process to check for injection

Step 4: Malware detection — what was injected.

# Detect injected code in process memory
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.malfind.Malfind
# Malfind identifies memory regions with suspicious characteristics:
# - PAGE_EXECUTE_READWRITE protection (writable + executable)
# - Not backed by a legitimate file on disk
# - Contains executable code (identified by header bytes)
#
# Output: Process, PID, Start address, Protection, Hexdump
#
# Interpretation (critical — false positives are common):
# - Legitimate causes of RWX memory: .NET JIT compilation,
#   Java JIT, some AV products, GPU drivers, browser JIT
# - Suspicious indicators: MZ header (PE executable), shellcode
#   patterns (NOP sleds, API resolution stubs), large RWX regions
#   in system processes that should not have them
#
# On a clean system, Malfind typically produces 5-20 results,
# most of which are false positives from legitimate applications.
# On a compromised system, additional results from system
# processes (svchost.exe, rundll32.exe) with PE headers or
# shellcode patterns indicate injection.

# Dump the injected memory regions for further analysis
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.malfind.Malfind --dump -o "C:\IR\Output\malfind_dumps"
# The dumped regions can be scanned with YARA rules, submitted
# to VirusTotal, or analyzed with a disassembler to confirm
# whether they contain malicious code

Step 5: DLL and module analysis — what was loaded.

# List all loaded DLLs for a specific suspicious process
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.dlllist.DllList --pid 4532
# Compare against known-good DLL lists for the process type
# An svchost.exe loading a DLL from C:\Users\Public\ is suspicious
# A legitimate svchost.exe loads only system DLLs from System32

# Check for discrepancies in module lists (detect injection)
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.ldrmodules.LdrModules --pid 4532
# LdrModules compares three different module lists maintained by Windows
# A module that appears in one list but not others may be injected
# Output columns: InInit, InLoad, InMem — if any is False for a
# non-system DLL, investigate further

Step 6: Credential extraction — what the attacker obtained.

# Extract password hashes from the SAM hive in memory
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.hashdump.Hashdump
# Output: Username:RID:LM_hash:NTLM_hash
# These are the same hashes the attacker would extract with Mimikatz
# If the attacker had access to LSASS, they obtained these credentials
# This informs the containment scope: every account with a recovered
# hash must have its password reset

# List registry hives in memory
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.registry.hivelist.HiveList
# Shows which registry hives were loaded at capture time
# Useful for identifying the SAM, SYSTEM, SOFTWARE hives for
# targeted registry analysis within the memory dump

Step 7: YARA scanning — hunting with signatures.

# Scan process memory with YARA rules
# Requires: pip install yara-python

# Scan all processes for Cobalt Strike beacon signatures
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.yarascan.YaraScan --yara-rules "rule CobaltStrike { strings: $a = { 2e 2f 2e 2f 2e 2c } $b = \"beacon\" nocase condition: any of them }"

# Or use a YARA rule file (more practical for multiple signatures)
vol -f "C:\IR\Evidence\TEST_memory.raw" windows.yarascan.YaraScan --yara-file "C:\IR\Tools\yara\cobalt_strike.yar"

# YARA scanning is the most targeted detection method:
# Malfind identifies suspicious memory regions generically
# YARA scanning matches specific malware signatures within those regions
# Combine both: Malfind for broad detection, YARA for specific identification

YARA rules for common attack tools (Cobalt Strike, Sliver, Metasploit, Mimikatz) are publicly available from threat intelligence sources. The Volatility Foundation, SANS, and various IR teams publish rule sets. Download these before the investigation — having YARA rules ready in the jump bag (IR1.8) means you can scan for known threats immediately upon acquiring a memory dump, rather than writing rules during the investigation.

The PsList vs PsScan rootkit detection technique

One of the most powerful techniques in memory forensics is comparing the output of PsList and PsScan. These two plugins retrieve process information using entirely different methods:

PsList walks the kernel's doubly-linked list of EPROCESS structures. This is the same list that Task Manager uses to display running processes. If an attacker hides a process by unlinking it from this list (a technique called DKOM — Direct Kernel Object Manipulation, T1014), PsList will not show it. The process still exists in memory and still executes, but it is invisible to the standard process enumeration.

PsScan searches memory byte-by-byte for EPROCESS structures by scanning for the characteristic header pattern. This method does not rely on the linked list — it finds every process structure in memory, including those that have been unlinked (hidden) and those that have terminated but whose memory has not yet been reclaimed.

The detection technique: run both plugins and compare. A process that appears in PsScan but not in PsList has been deliberately hidden — this is strong evidence of rootkit activity or advanced attacker tools that use DKOM for concealment. IR6 teaches this comparison technique with worked examples, including how to extract the hidden process for further analysis.

Alternative memory evidence: hibernation files and crash dumps

Memory evidence is not limited to live captures. Windows creates memory images in other contexts that Volatility 3 can analyze:

Hibernation file (hiberfil.sys). When Windows hibernates (or uses Fast Startup, the default on Windows 10/11), it writes RAM contents to C:\hiberfil.sys in compressed format. This file is a memory image that Volatility 3 can decompress and analyze. If the target system was hibernated or powered down with Fast Startup enabled, hiberfil.sys may contain memory evidence from the most recent session — including running processes, network connections, and injected code that were present at the time of hibernation. KAPE's !SANS_Triage target collects hiberfil.sys automatically.

Crash dumps (MEMORY.DMP). When Windows encounters a critical error (blue screen/BSOD), it writes a memory dump to C:\Windows\MEMORY.DMP (full dump) or C:\Windows\Minidump\ (mini dumps). Full crash dumps contain the same data as a live memory capture and can be analyzed with Volatility 3. If the attacker's activity caused a system crash (kernel exploit, driver manipulation, memory corruption), the crash dump contains evidence of what was in memory when the crash occurred — potentially capturing the attacker's tools in action.

Page file (pagefile.sys). The Windows page file contains memory pages that have been swapped to disk. While not a complete memory dump, it may contain fragments of process memory that include network connection artifacts, command strings, and injected code. Volatility 3 can analyze page files for partial evidence recovery when a live memory capture is not available.

These alternative sources mean that memory evidence may be recoverable even after the system has been rebooted or powered off — a fact that many investigators overlook. KAPE collects hiberfil.sys and pagefile.sys as part of its standard triage, providing memory evidence alongside disk artifacts without requiring a separate memory acquisition step.

Troubleshooting

"No suitable symbol table found." Volatility 3 needs to download symbols for the specific Windows build in the memory dump. Ensure the forensic workstation has internet access (or pre-download the symbol pack). Check the symbols directory path. For very new Windows builds, symbols may not yet be available — check the Volatility 3 GitHub issues for updates.

Analysis is extremely slow. Memory analysis is I/O intensive — Volatility reads the entire dump file for each plugin. Use an SSD, not a spinning disk. With 16 GB RAM analyzing a 16 GB dump, the system may swap heavily. 32 GB RAM on the forensic workstation is recommended for analyzing dumps from systems with 16+ GB RAM. Save plugin output to files (vol -f dump.raw windows.pslist > pslist.txt) to avoid re-running slow plugins.

Malfind produces many results on a clean system. This is expected. Modern Windows has many legitimate sources of RWX (read-write-execute) memory: .NET JIT compilation, Java JIT, Windows Defender's real-time scanning engine, GPU drivers, browser JavaScript engines. The investigator's job is not to flag everything Malfind reports — it is to compare the compromised system's results against a known-clean baseline and identify the additional entries. IR6 teaches this comparison technique in depth with worked examples.

"Module not found" for a specific plugin. Some Volatility 3 plugins require additional Python packages (e.g., yara-python for YARA scanning, pycryptodome for encrypted credential extraction). Install missing dependencies: pip install yara-python pycryptodome.