Memory Forensics with Volatility 3: A Field Guide for Defenders

When an endpoint is compromised, the most valuable evidence often never touches disk. Decryption keys, injected code, unpacked malware, network connections, command-line arguments and credentials frequently exist only in volatile memory, and they vanish the moment the machine powers off. Memory forensics is the discipline of capturing and analysing that RAM to reconstruct what a system was doing, and Volatility 3 is the open-source framework that most defenders reach for. This field guide takes the perspective of a blue-team analyst responding to an incident: how to acquire memory soundly, which plugins answer which questions, how to recognise the signals of code injection and rootkits, and how to avoid the mistakes that lead to wrong conclusions. The framing is understand in order to defend, so we focus on detection and triage rather than on writing malware, and every technique is presented as something you run to find an attacker who is already inside.

Why memory forensics matters#

Disk forensics tells you what was stored; memory forensics tells you what was running. Modern intrusions increasingly live off the land and operate in memory to evade file-based detection: fileless malware executes from PowerShell or WMI without a persistent binary, process injection hides code inside legitimate processes, and packed or encrypted payloads only reveal their true form once loaded into RAM. Memory also holds transient state that no log records, such as the exact command line of a now-exited process, open network sockets, loaded kernel modules and cached credentials. For a responder, a memory image is a frozen snapshot of the crime scene at the moment of capture. It lets you answer questions that logs alone cannot, and it can confirm or refute a hypothesis about how an attacker gained execution, what they touched and whether they are still resident.

Sound memory acquisition#

Analysis is only as trustworthy as the acquisition. The core principle is to disturb the system as little as possible and to record exactly what you did. On live Windows hosts, tools such as WinPmem, FTK Imager or Magnet RAM Capture produce a raw image; on Linux, AVML or a LiME kernel module capture physical memory; virtual machines can be snapshotted or their memory files copied, which is often the cleanest option because it is effectively atomic. Always hash the image immediately (for example SHA-256) and preserve that hash in your notes, capture memory before disk where feasible because it is the more volatile evidence, and document the host, time, tool, version and operator to maintain chain of custody. Avoid running acquisition from the suspect host's own untrusted binaries where possible, and be aware that a running rootkit can, in principle, interfere with acquisition, which is one reason to correlate memory findings with independent telemetry.

Volatility 3 essentials#

Volatility 3 is a rewrite of the classic framework with a symbol-driven approach. Instead of manually selecting an OS "profile" as in Volatility 2, version 3 automatically identifies the operating system and locates kernel structures using symbol tables, which for Windows are fetched from PDB information and for Linux and macOS come from banner-matched symbol packs you supply. You invoke it as vol -f memory.img plugins.Name, or python3 vol.py from source. The mental model is that each plugin walks specific kernel data structures to reconstruct an aspect of system state. Getting a correct Linux analysis running requires a matching ISF symbol pack for the exact kernel, which is a common early stumbling block. Once symbols resolve, the same investigative workflow applies across platforms: enumerate processes, inspect their relationships, examine network state, hunt for injection and dump artefacts for deeper study.

Core plugins and what they reveal#

A handful of plugins form the backbone of most investigations. windows.pslist walks the doubly linked process list, while windows.psscan scans memory for process structures directly and can reveal processes hidden from the list; comparing the two is a classic detection step. windows.pstree shows parent-child relationships, which exposes suspicious lineage such as a browser spawning a shell. windows.cmdline recovers process command lines, often the single most informative artefact. windows.netscan reconstructs network connections and listening ports. windows.dlllist and windows.handles show loaded modules and open objects. On Linux the analogues are linux.pslist, linux.pstree, linux.bash for shell history and linux.check_syscall for tampering. These plugins turn an opaque blob of bytes into an inventory of what the machine was doing, and disagreements between plugins that should agree are themselves strong signals.

Detecting process injection#

Process injection hides attacker code inside a trusted process, and memory forensics is one of the most reliable ways to catch it. The key defensive plugin is windows.malfind, which scans process memory for regions that are both executable and writable and that lack a backing file on disk, a combination that legitimate code rarely needs and that shellcode and reflectively loaded modules commonly exhibit. Analysts look for private memory pages marked PAGE_EXECUTE_READWRITE, for the tell-tale MZ header of a PE image mapped where no module should exist, and for injected regions inside processes that have no reason to host them. Complementary signals include a process whose loaded module list omits a DLL that is clearly present in memory, threads whose start address points into unbacked memory, and hollowed processes where the on-disk image and in-memory image diverge. None of these is proof by itself, but together they build a compelling case, and they should be corroborated with EDR and network telemetry.

Hunting rootkits and hidden artefacts#

Rootkits try to make themselves invisible to the running operating system, but they cannot easily hide from an external view of memory, which is precisely the advantage of forensic analysis. Cross-view detection compares two ways of enumerating the same thing and flags disagreements: a process visible to psscan but missing from pslist may be unlinked from the active process list, a classic hiding technique. On Linux, linux.check_syscall and module-integrity checks reveal hooked syscall tables or tampered function pointers. Analysts also inspect the SSDT and IDT on Windows, hidden kernel modules, and driver objects that do not correspond to any legitimate file. The defensive principle is triangulation: never trust a single enumeration path, because the whole purpose of a rootkit is to corrupt one view while leaving another intact. Memory forensics wins here because it reads structures the compromised OS was trying to hide behind.

Dumping and pivoting to deeper analysis#

Once memory analysis identifies something suspicious, the next step is extraction for closer study. windows.dumpfiles recovers files cached in memory, windows.memmap and process dump plugins extract a process's address space, and injected regions found by malfind can be carved out for static or dynamic analysis in a sandbox. Recovered command lines and network endpoints become indicators of compromise you can sweep across the rest of the estate. Registry hives resident in memory can be parsed for persistence keys and recently executed programs. The workflow is iterative: a finding in memory generates a hypothesis, the extracted artefact confirms or refines it, and the resulting indicators drive a hunt across other hosts. Throughout, keep the original image immutable and work on copies, so that your analysis remains reproducible and defensible if the case escalates.

Common pitfalls#

Several mistakes recur. The most damaging is a bad acquisition: a smeared image captured on a busy live system can contain inconsistent structures that make plugins fail or lie, so prefer atomic snapshots where possible and note the acquisition conditions. Using the wrong or missing symbols in Volatility 3, especially on Linux, produces empty or nonsensical output that analysts sometimes misread as "nothing found" rather than "tooling misconfigured". Treating a single plugin's output as ground truth ignores that rootkits target specific views; always cross-check. Analysts also over-interpret malfind hits, which have legitimate causes such as JIT compilers, so context matters. Finally, failing to preserve chain of custody and hashes can render sound technical findings useless in a formal proceeding. Every one of these is avoidable with discipline: acquire cleanly, verify symbols, corroborate across plugins and telemetry, and document relentlessly.

Investigation checklist#

Use this checklist to structure a memory investigation. 1) Acquire memory with a documented tool and hash the image immediately. 2) Confirm Volatility 3 resolves the correct symbols before trusting output. 3) Enumerate processes with pslist, psscan and pstree and diff the lists. 4) Recover command lines with cmdline and flag suspicious lineage. 5) Reconstruct network state with netscan and match against firewall logs. 6) Run malfind and triage executable-writable unbacked regions. 7) Perform cross-view checks for hidden processes, modules and syscall hooks. 8) Dump suspicious processes and injected regions for deeper analysis. 9) Extract IOCs and sweep the wider estate. 10) Corroborate every memory finding with EDR, network and disk evidence, and document the chain of custody throughout.

Frequently asked questions#

Can memory forensics detect fileless malware that never writes to disk? Yes, and this is one of its greatest strengths. Because fileless techniques execute in RAM, a memory image often captures the injected code, the interpreter's loaded scripts and the network connections that leave no file behind, which disk forensics would miss entirely. Is Volatility 3 reliable against an active rootkit that tries to hide? It is far more reliable than asking the compromised OS, because it reads raw kernel structures externally rather than trusting the operating system's own APIs. However, a sophisticated rootkit can attempt to corrupt those structures too, so best practice is cross-view analysis and corroboration with independent telemetry rather than trusting any single result.

Conclusion#

Memory forensics gives defenders visibility into the part of an intrusion that leaves no trace on disk, and Volatility 3 makes that visibility accessible with a consistent, plugin-driven workflow across Windows, Linux and macOS. The method is straightforward in principle: acquire memory soundly, resolve the right symbols, enumerate what the system was doing, hunt for the disagreements and unbacked executable regions that betray injection and rootkits, extract artefacts, and corroborate everything with independent evidence. The discipline that separates a reliable investigation from a misleading one is skepticism toward any single view and rigour in acquisition and documentation. Practised well, memory forensics turns a fleeting snapshot of RAM into a defensible reconstruction of an attack, and it frequently supplies the decisive evidence that logs and disk alone cannot.