Volatility 3 Advanced Analysis: Symbol Tables, Namespaced Plugins and Cross-Layer Memory Correlation

network_forensics_pcap Difficulté 1–5 30 min certifiable

Théorie

Why This Matters

Volatility 3, released in 2019 and now the actively maintained branch of the framework, addresses the most persistent pain point of Volatility 2: the dependency on pre-built profile files that required a matching VM for every OS version and service pack. Volatility 3 replaces profiles with symbol tables derived from Microsoft's public PDB (Program Database) symbol server, enabling automatic symbol resolution for any Windows version that has public symbols — which is essentially every version of Windows 10, 11, and Server from 2015 onward. In enterprise incident response and CTF competitions alike, Volatility 3 is now the baseline expectation. Analysts who understand the plugin naming conventions, symbol table system, and advanced analysis capabilities of Volatility 3 work faster and produce more reliable results than those still relying on Volatility 2 habits.

Core Concept

Volatility 3 architecture is built around three concepts that differ significantly from Volatility 2:

Symbol tables replace profiles. A symbol table is a JSON file (or a compressed .json.xz file) containing the names, types, and offsets of kernel data structures for a specific OS build. Volatility 3 downloads these automatically from Microsoft's symbol server or from the Volatility 3 symbol pack. Symbol files are stored in volatility3/framework/symbols/. The windows.info plugin reports which symbol table was matched.
Plugin naming convention: Volatility 3 uses namespaced plugin names in the format os.category.PluginName. For Windows: windows.pslist.PsList, windows.netscan.NetScan, windows.malfind.Malfind. At the command line, the dot-separated name is used: python3 vol.py windows.pslist. This is a breaking change from Volatility 2's flat plugin names.
Cross-layer consistency: Volatility 3 is built on a layered translation system that separates physical memory, virtual memory, and file format layers. This enables cross-layer analysis — verifying that a kernel data structure visible in virtual memory corresponds to the expected content in physical memory. Discrepancies indicate DKOM (Direct Kernel Object Manipulation) or memory corruption.

Key plugin renames and equivalents (Volatility 2 → Volatility 3): - pslist → windows.pslist - psscan → windows.psscan - cmdline → windows.cmdline - netscan → windows.netscan - malfind → windows.malfind - dumpfiles → windows.dumpfiles - hashdump → windows.hashdump - filescan → windows.filescan - envars → windows.envars

Memory carving in Volatility 3 is enhanced through the windows.strings plugin (maps string offsets to process owners) and windows.memmap (produces a physical-to-virtual address map for full process memory dumps).

Technical Deep-Dive

# Volatility 3: verify installation and list available plugins
python3 vol.py --help
python3 vol.py --help | grep windows

# Step 1: identify OS and confirm symbol table match
python3 vol.py -f memdump.raw windows.info

# Step 2: process list
python3 vol.py -f memdump.raw windows.pslist

# Step 2b: pool-tag scan for hidden processes
python3 vol.py -f memdump.raw windows.psscan

# Step 3: process tree
python3 vol.py -f memdump.raw windows.pstree

# Step 4: command-line arguments
python3 vol.py -f memdump.raw windows.cmdline

# Step 5: network connections
python3 vol.py -f memdump.raw windows.netscan

# Step 6: injection detection
python3 vol.py -f memdump.raw windows.malfind

# Step 7: dump malfind regions to files
python3 vol.py -f memdump.raw windows.malfind --dump

# Step 8: file objects in memory
python3 vol.py -f memdump.raw windows.filescan

# Step 9: extract a file by virtual offset (from filescan output)
python3 vol.py -f memdump.raw windows.dumpfiles --virtaddr 0xfa8001a3b060

# Volatility 3: provide symbol table manually (when auto-download is unavailable)
# Download ISF (Intermediate Symbol Format) pack from:
# https://downloads.volatilityfoundation.org/volatility3/symbols/
# Then specify via environment or place in symbols directory:
export VOLATILITY_SYMBOL_DIRS=/path/to/symbols/
python3 vol.py -f memdump.raw windows.pslist

# Volatility 3: render output as JSON for programmatic processing
python3 vol.py -f memdump.raw -r json windows.pslist > pslist.json

# Volatility 3: render as CSV
python3 vol.py -f memdump.raw -r csv windows.netscan > netscan.csv

# Programmatic Volatility 3 usage via Python API
# Framework-level access for custom plugin development
import volatility3.framework as framework
from volatility3.framework import contexts, automagic, interfaces
from volatility3.plugins.windows import pslist

# Create a context (holds configuration and layer state)
ctx = contexts.Context()
framework.require_interface_version(2, 0, 0)

# Configure the image source
single_location = "file:///path/to/memdump.raw"
ctx.config["automagic.LayerStacker.single_location"] = single_location

# Run automagic to determine OS and load symbol tables automatically
available_automagics = automagic.available(ctx)
automagics = automagic.choose_automagic(available_automagics, pslist.PsList)
automagic.run(automagics, ctx, pslist.PsList, "plugins")

# Instantiate and run the plugin
plugin = pslist.PsList(ctx, "plugins")
for proc in plugin.run():
    pid  = proc.UniqueProcessId
    name = proc.ImageFileName.cast("string", max_length=15, errors="replace")
    print(f"PID {pid:6d}  {name}")

Analytical Methodology

Run python3 vol.py -f memdump.raw windows.info as the first command. This confirms that Volatility 3 successfully matched a symbol table to the image and displays OS version, architecture, and kernel base address. If symbol matching fails, manually provide the ISF pack.
Run windows.pslist and windows.psscan in parallel. Compare PIDs: entries in psscan but not pslist indicate DKOM-based process hiding. Save both outputs to CSV using -r csv.
Run windows.pstree to visualise the process hierarchy. Specifically examine: children of lsass.exe, winlogon.exe, svchost.exe, and explorer.exe. Document any unexpected child processes.
Run windows.cmdline for all processes. Pipe output through grep for Base64 patterns, encoded commands, unusual binary paths, and network-related arguments.
Run windows.netscan. Export to CSV and filter for ESTABLISHED state connections. For each external connection, note the PID, local port, remote IP, and remote port. Cross-reference remote IPs with threat intelligence.
Run windows.malfind --dump to detect injection. Review the hex header of each dumped region; filter for MZ headers. Run YARA against dumped regions.
Run windows.envars for high-value processes (web servers, scripting engines, database clients) to extract environment variable credentials.
Run windows.filescan and filter output for recently modified or suspicious file paths. Use windows.dumpfiles with the --virtaddr of any files of interest.
For any new findings not covered by standard plugins, develop a custom plugin using the Volatility 3 Python API, leveraging the contexts.Context and layer/symbol infrastructure demonstrated in the Technical Deep-Dive.

Common Analytical Errors

Using Volatility 2 plugin names with Volatility 3: The most frequent beginner error. vol.py pslist in Volatility 3 will fail or produce no output; the correct form is vol.py windows.pslist. Check the Volatility version before running any command.
Not verifying symbol table resolution: If windows.info cannot find a matching symbol table, all subsequent plugins will fail silently or produce errors. Always verify symbol resolution before proceeding. Manually providing an ISF pack resolves most cases.
Ignoring the -r json output mode: Volatility 3's JSON renderer produces structured, machine-parseable output ideal for scripting. Analysts who rely only on text output write brittle grep pipelines where JSON parsing would be more reliable.
Conflating windows.malfind false positives with confirmed injections: Same caution as Volatility 2 — JIT-compiled code produces malfind hits. The MZ header check is mandatory.
Not using windows.psscan alongside windows.pslist: The cross-layer advantage of Volatility 3 makes this comparison even more powerful; physical-layer pool scanning (psscan) is independent of any virtual-layer manipulation, making DKOM detection more reliable in V3 than V2.

NICE Framework Alignment

Code	Knowledge/Skill/Task Statement	How This Card Develops It
K0017	Knowledge of concepts and practices of processing digital forensic data	Understanding Volatility 3 symbol table architecture and plugin namespace as the operational memory forensics platform
K0042	Knowledge of incident response and handling methodologies	Executing a complete Volatility 3 triage workflow with structured output formats for incident timelines
K0187	Knowledge of file type abuse by adversaries for data exfiltration	Applying advanced malfind analysis and custom plugin development to detect novel evasion techniques
S0047	Skill in preserving evidence integrity according to standard operating procedures	Using JSON and CSV output renderers to produce reproducible, timestamped forensic records
T0049	Decrypt seized data using technical means	Leveraging Volatility 3 cross-layer analysis to verify kernel structure integrity and detect DKOM manipulation