Nineteen years after its debut at Black Hat 2007 as VolaTools, Volatility is still the default answer when someone hands you a RAM dump and asks what happened on the box. The current release, Volatility 3 v2.27.0, shipped in January 2026 — maintained by the non-profit Volatility Foundation and underwritten by Volexity as sustaining sponsor. Volatility 2 is officially deprecated. If you’re still running it on a forensic workstation in 2026, you’re out of support.
This guide covers what Volatility does, how the Volatility 3 rewrite changed the workflow, the plugins you’ll actually use on casework, the ones that hurt to lose, and a practical cheatsheet you can keep open during an investigation.
What Volatility Actually Does
Volatility parses memory dumps — files produced by tools like WinPmem, DumpIt, LiME, or hypervisor snapshots — and reconstructs the runtime state of the system they were taken from. Running processes, network connections, loaded kernel modules, registry hives still in memory, injected code, unhooked syscalls, command-line history, cached credentials. It works across Windows (XP through 11), Linux (kernel 2.6.18 and later), and macOS, all from the same CLI.
The value proposition hasn’t changed: disk forensics tells you what was written, memory forensics tells you what was running. That includes fileless malware that never touched the filesystem, injected shellcode, encryption keys sitting in RAM for BitLocker or TrueCrypt volumes, active C2 connections, clipboard buffers, and anything the attacker cleaned up on disk but forgot lives in memory until the box powers down.
For incident responders, this is often where patient-zero lives. For malware analysts, it’s where unpacked payloads surface. For law enforcement, it’s often the only place where evidence exists at all on a machine that was seized while running.
The Volatility 3 Rewrite: What Actually Changed
The jump from Volatility 2 to Volatility 3 wasn’t a point release. Led by Mike Auty (@ikelos), it was a ground-up rewrite in Python 3 with a new architecture designed as a library first and a CLI second. Every assumption from the 2007 codebase got revisited.
Profiles are gone. Volatility 2 required you to feed --profile=Win10x64_18362 or similar on every invocation, guessing the exact build after running imageinfo. Volatility 3 reads the PDB GUID embedded in the memory image, pulls the matching symbol table from Microsoft’s symbol server, and moves on. For Windows this is a meaningful workflow change — no more profile-guessing games on unfamiliar builds. For Linux and macOS you still need to supply or generate symbol tables, but the Windows path is genuinely faster.
Plugin namespacing is sane. Commands now read as windows.pslist.PsList, linux.netfilter.Netfilter, mac.pslist.PsList. The old flat namespace is gone, which makes the CLI more verbose but far easier to script against and filter through tools like grep and awk.
The architecture is a library now. Volatility 3 is designed so that state required to run a plugin is self-contained in a ContextInterface object — layers of data plus available symbols. This makes it genuinely usable as a Python library inside other tools, not just a CLI wrapper around internal APIs. The reference web GUI Volumetric is built on this, and it’s what makes integrations with SOAR platforms practical.
Speed improvements are real. Volatility 2 re-read memory on every object access to support live analysis — a feature almost nobody used. Volatility 3 reads once at construction time, which translates to noticeably faster runs on most plugins against identical dumps.
New plugins you didn’t have before. Recent releases added windows.hollowprocesses, windows.processghosting, windows.unhooked_system_calls, windows.suspicious_threads, windows.scheduled_tasks, windows.direct_system_calls, linux.ebpf, linux.hidden_modules, linux.pagecache, and a long list covering modern attack techniques that didn’t exist when Volatility 2 was designed.
Installing and Getting Oriented
Installation is straightforward on any Linux or macOS box with Python 3.8+:
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
python3 -m pip install -r requirements.txtOr via pip: pip install volatility3. Use a virtual environment — Volatility pulls in enough dependencies that polluting system Python is a bad idea.
Two dependencies are listed as optional but are effectively mandatory for real casework: yara-python and pefile. Without yara-python, the yarascan, vadyarascan, and mftscan plugins silently disappear from the plugin list. Without pefile, verinfo, netscan, netstat, and skeleton_key_check fail at import time with no obvious hint that they ever existed. Install both. Also install capstone if you want disassembly output from plugins like windows.direct_system_calls.
For Windows users who don’t want to mess with Python: Volatility Workbench from PassMark wraps the framework in a Windows GUI, currently built on Volatility 3 Framework v2.27.0. It bundles the CLI binary alongside, caches process lists in a .CFG file next to the dump to speed up re-analysis, and is free. For one-off cases or GUI-preferring analysts it’s fine; for repeatable scripted investigation work stay on the CLI.
The Investigation Workflow
A useful memory investigation follows a consistent triage sequence. The specific plugins vary, but the order of questions rarely does: what OS is this, what was running, what was it doing over the network, what looks wrong, and what evidence can I carve out of it?
The six-step SANS memory forensics process formalizes this, but the working shorthand most analysts use is: identify → enumerate → triage → dump → hunt.
Identify the image. windows.info (or banners for Linux) tells you the OS, build, architecture, and whether Volatility can actually parse this dump. If symbol resolution fails here, nothing downstream works.
Enumerate processes three ways. windows.pslist.PsList walks the doubly-linked _EPROCESS list the same way Task Manager does — fast, but vulnerable to DKOM unlinking by rootkits. windows.psscan.PsScan carves memory for pool tags matching _EPROCESS structures, which catches hidden processes and exited processes whose structures haven’t been reclaimed. windows.pstree.PsTree shows parent-child relationships, which is usually where suspicious processes reveal themselves — cmd.exe under iexplore.exe is the classic example. Running all three and comparing the outputs is the poor man’s psxview (which doesn’t exist in Volatility 3 as a direct equivalent).
Triage the network side. windows.netscan.NetScan and windows.netstat.NetStat surface active and residual connections. Look for connections to unexpected IPs, unusual ports, or processes that have no business doing network I/O.
Dump anything that looks wrong. windows.dumpfiles.DumpFiles --pid <PID> extracts the executable and loaded DLLs for a process. windows.memmap.Memmap --pid <PID> --dump pulls all mapped pages into a single file for offline analysis. Feed both into YARA scanners, string extraction, or a disassembler.
Hunt for injection and hooks. windows.malfind.Malfind is the workhorse — it looks for memory regions marked executable with content that doesn’t match any backing file on disk, which catches most injected shellcode and process hollowing. windows.hollowprocesses specifically targets process hollowing. windows.unhooked_system_calls detects syscall table tampering. windows.ssdt.SSDT and windows.driverirp.DriverIrp cover kernel-level hooks.
The Cheatsheet
These are the Volatility 3 commands that cover 90% of real casework. Keep them within reach.
A pattern worth memorizing: list plugins like pslist walk kernel data structures the way the OS itself does — fast but trivially manipulated by malware that unlinks itself. Scan plugins like psscan carve memory for pool-tagged structures, catching hidden and exited processes at the cost of speed and occasional false positives. Run both. If the outputs disagree, that disagreement is your lead.
Where Volatility 3 Still Hurts
The rewrite is architecturally justified but the migration path is not smooth, and some pain is permanent. Andrea Fortuna’s March 2026 writeup on migration friction catalogs the patterns most experienced analysts hit in roughly the same order.
Missing plugins from Volatility 2. notepad and clipboard are gone. Issue #710 on the Volatility 3 repo has been open since April 2022, still labeled low-priority. The Foundation’s position is that modern Windows heap structures make these plugins fundamentally unreliable, which is defensible engineering but unhelpful when a case needs clipboard content. psxview, which aggregated multiple process-detection techniques in one shot, has no direct equivalent — you correlate pslist / psscan / pstree outputs yourself. apihooks is also gone, and windows.strings with an offset-tagged strings file is an imperfect substitute for some Volatility 2 workflows (see the long-running issue #876 for the limitations).
Offline analysis takes setup. Volatility 3 downloads PDB symbols from Microsoft’s server at runtime, which breaks immediately on air-gapped DFIR workstations. A JPCERT/CC blog post documents the workaround: extract the PDB GUID from the target binary, run pdbconv.py on a connected machine, place the resulting .json.xz in the symbols directory. It works, but it’s friction Volatility 2 didn’t have.
macOS is the hardest target. You need a Kernel Debug Kit matching the exact OS build, dwarf2json to convert the DWARF bundle, and manual population of constant_data with a base64-encoded Darwin banner extracted from the memory image. Miss any step and you get a generic “symbol table requirement not fulfilled” error with no automatic recovery.
Performance regressions on specific plugins. Some Volatility 3 plugins run dramatically slower than their Volatility 2 counterparts — not a general speed problem, but localized hotspots that haven’t been optimized.
Frequently Asked Questions
Is Volatility 2 still usable in 2026? It runs, but it’s deprecated and unsupported. Volatility 3 has reached official parity and surpassed it on modern Windows attack techniques. New plugins and bug fixes land in Volatility 3 only. Stay on Volatility 2 only if you have casework involving notepad, clipboard, or psxview functionality that Volatility 3 hasn’t replaced.
Is Volatility free? Yes. It’s released under the Volatility Software License (VSL), a custom open-source license the Foundation wrote to better fit the project’s goals than GPL did.
What’s the learning curve? Plan a weekend to get comfortable with the core plugins against practice dumps — the Art of Memory Forensics book ships with sample images and the Volatility Foundation maintains a repository of additional test dumps. A few weeks of casework to internalize output formats. Ongoing education to keep up with plugin releases and new attack techniques.
What’s the best book? The Art of Memory Forensics by Ligh, Case, Levy, and Walters is still the definitive reference even though it predates the Volatility 3 rewrite. Concepts transfer completely; specific commands don’t — pair it with the online migration guides.
The Verdict
Volatility 3 has reached feature parity with Volatility 2 and surpassed it on modern Windows attack techniques. The rewrite was worth it. The migration friction is real but finite, and the Foundation has committed to long-term support.
For any analyst still leaning on Volatility 2 muscle memory, the switch is overdue. For anyone new to memory forensics in 2026, start with Volatility 3 directly and don’t look back — you’ll skip a decade of accumulated quirks that Volatility 2 veterans are still unlearning. The tool isn’t perfect. It’s just the one every other memory forensics tool is measured against, the one the research community builds against, and the one the SANS FOR508 and FOR532 tracks teach. That isn’t changing this year.
If you’re doing DFIR work and don’t have Volatility installed on your analyst workstation, install it before your next case lands.
