Memory Forensics with Volatility 3
Disk forensics can tell you what was written to storage, but a lot of what matters in a modern intrusion — injected code, in-memory credentials, live network connections, decrypted payloads — only exists in RAM. Volatility 3 is the current generation of the open-source Volatility Framework, rewritten in Python 3 with automatic symbol resolution instead of the fixed profiles used in Volatility 2. This article covers the core plugin workflow investigators use to go from a raw memory image to actionable findings.
Why Memory Forensics Matters in Incident Response
Attackers increasingly favor techniques that leave little or no trace on disk: reflective DLL injection, process hollowing, fileless PowerShell payloads, and credentials cached only in process memory. A disk image alone can miss all of it. A memory capture taken while the compromised process is still running is often the only artifact that proves code injection occurred, reveals the command-and-control IP a process was actually talking to, or recovers an encryption key before it's discarded.
The trade-off is timing: memory is volatile, so capture has to happen early in the response, ideally before a host is powered off or rebooted, which is one reason containment decisions in the field involve weighing evidence preservation against stopping active damage.
Acquiring a Memory Image
Volatility analyzes a memory image after the fact — it does not capture memory itself. Acquisition is a separate step, typically performed with a dedicated tool run from external media to minimize the acquisition tool's own footprint on the system.
- •WinPmem — open-source, widely used for Windows physical memory acquisition
- •Magnet RAM Capture / FTK Imager — commercial and free GUI-based acquisition tools
- •LiME (Linux Memory Extractor) — kernel module for acquiring memory on Linux systems
- •Hypervisor-level snapshots — for virtualized hosts, a memory-inclusive snapshot can substitute for a live capture
Example acquisition with WinPmem
winpmem -o memory.rawVolatility 3 Basics: Symbols and Plugin Syntax
Volatility 3 commands follow the pattern vol -f <image> <plugin.name>. Unlike Volatility 2, there is no imageinfo step to select a fixed OS profile — Volatility 3 identifies the operating system and build automatically and downloads or builds the matching symbol table as needed. Running windows.info first is still good practice to confirm the image was parsed correctly and to record the OS build in your notes before running further plugins.
Confirm OS details before deeper analysis
vol -f memory.raw windows.infoProcess Analysis: pslist, pstree, and psscan
These three plugins answer the same basic question — what was running — using different techniques, and the differences matter. windows.pslist walks the OS's linked list of active processes, which is fast but can be blinded by direct kernel object manipulation (DKOM) techniques that unlink a malicious process from that list. windows.psscan instead scans memory pools for process object signatures, so it can surface hidden or terminated processes that pslist misses. windows.pstree shows parent-child relationships, which is often the fastest way to spot something like cmd.exe or powershell.exe spawned from a Word or Excel process.
Baseline process enumeration
vol -f memory.raw windows.pslist
vol -f memory.raw windows.pstree
vol -f memory.raw windows.psscanHunting Injected Code with malfind
windows.malfind looks for memory regions with characteristics typical of process injection: pages marked with PAGE_EXECUTE_READWRITE protection that don't correspond to a mapped file on disk, or that contain executable code where none should exist. This is one of the highest-signal plugins in the framework for catching techniques like reflective DLL injection, process hollowing, and shellcode injection that leave no trace on disk. Findings from malfind should be cross-referenced against the process's expected behavior — some legitimate software does use RWX memory, so triage each hit rather than treating every result as malicious.
Scan for injected code across all processes
vol -f memory.raw windows.malfindNetwork Artifacts: netscan and netstat
windows.netscan pool-scans memory for network connection structures, which means it can recover evidence of connections that have already closed by the time of capture — often the only way to find a C2 IP address that was only active briefly. windows.netstat reads active connection tables directly and is faster but, like pslist, can miss what's already been torn down or hidden.
Recover network connection artifacts
vol -f memory.raw windows.netscan
vol -f memory.raw windows.netstatRegistry, Command History, and Loaded Modules
Beyond processes and network state, Volatility 3 can pull registry hives, per-process command lines, and loaded DLLs directly out of memory — useful for confirming persistence mechanisms and spotting DLL side-loading without needing a parallel disk image.
Registry, command-line, and module inspection
vol -f memory.raw windows.registry.hivelist
vol -f memory.raw windows.cmdline
vol -f memory.raw windows.dlllist --pid <PID>Building the Investigation Workflow
In practice, plugins are chained into a workflow rather than run in isolation.
- •Run windows.info to confirm the image and record the OS build
- •Run windows.pslist and windows.pstree to build a baseline of what was running and how processes relate
- •Run windows.psscan to check for anything hidden from the standard process list
- •Run windows.malfind and windows.netscan to look for injection and C2 activity
- •Pull command lines and loaded modules for any suspect process identified above
- •Dump and hash suspect binaries or memory regions for further static analysis or threat intel matching
- •Correlate timestamps and findings against disk artifacts and log data to build a full timeline
References
Primary sources for the material above. Standards are cited by identifier so they stay findable as publishers reorganise their sites.
- Volatility Foundation — Volatility 3 Documentation