Disk forensics tells you what a file looked like. Memory forensics tells you what the machine was actually doing — decrypted payloads, injected code, network sockets, command lines, and credentials that never touch the disk. That is where modern intrusions live, and Volatility 3 is the open-source framework that reads it.
This guide takes you from a blank workstation to a working investigation: three install methods (native pip, Docker, and Windows/from-source), how to acquire a memory image safely, and a plugin-by-plugin hunting workflow with real, copy-pasteable commands. Every command was written for the Volatility 3 2.x line and its namespaced windows.* / linux.* plugin scheme.
◈ Table of Contents
01 — WHAT MEMORY FORENSICS IS & WHY DEFENDERS NEED IT
Phase 1 / 11Random-access memory is the working scratchpad of a running system. When malware runs, it must eventually be decrypted, unpacked and mapped into memory to execute — even if the on-disk copy is packed, fileless, or already deleted. A memory image (a byte-for-byte copy of physical RAM) captures that state. Volatility 3 walks the operating system's kernel structures inside that image and reconstructs processes, threads, open handles, network connections, loaded modules, registry hives and more.
Volatility 3 is a full rewrite of the classic Volatility 2 framework. The two changes that matter most day to day: profiles are gone (the framework auto-identifies the OS build using symbol tables instead of a hand-picked --profile), and every plugin is namespaced by OS — windows.pslist, linux.pslist, mac.pslist. If you learned Volatility 2, unlearn the profile habit; almost everything else transfers.
Fileless & In-Memory Malware
PowerShell downloaders, reflective DLL injection and process hollowing often leave nothing meaningful on disk. malfind and ldrmodules surface them.
Live Network State
Beacon destinations, listening backdoors and C2 sockets that were active at capture time appear in netscan even if logs were cleared.
Credential Theft Response
Cached hashes, LSA secrets and Kerberos material sit in LSASS memory. Memory forensics confirms what an attacker could have harvested.
Rootkits & Process Hiding
Unlinked processes vanish from pslist but are still found by pool scanning with psscan — a classic hidden-process check.
Command Reconstruction
cmdline and consoles recover the exact arguments an attacker typed, including staged payload URLs and flags.
Ransomware Triage
Recover the encryptor's process tree, injected regions and, occasionally, key material that only ever existed in RAM.
ORDER OF VOLATILITY: RAM is the most perishable evidence you have. If a suspect host is still running, capture memory before you pull the plug, isolate the NIC, or shut down. A reboot destroys everything in this guide.
02 — PREREQUISITES & REQUIREMENTS
Phase 2 / 11Volatility 3 is pure Python and light on the analysis host — the heavy resource is disk and RAM headroom to hold and parse the image. Plan for a workstation with at least as much free disk as your largest memory image, plus temporary space for dumped processes.
| Requirement | Minimum | Recommended |
|---|---|---|
| Python | 3.8min | 3.11 or 3.12rec |
| Analysis RAM | 4 GB | 16 GB (parsing large images is memory-hungry) |
| Free disk | 2× image size | 3× image size (image + dumps + symbol cache) |
| OS (analysis host) | Linux / Windows / macOS | Kali or Ubuntu VM, isolated from production |
| Internet access | First run only (symbol download) | Or pre-staged offline symbol packs |
| Optional | — | yara-python for YARA scanning, capstone for disassembly |
You also need Python's build tooling (pip, venv) and Git if you install from source. On a fresh Debian/Ubuntu/Kali host:
NEVER analyse on the victim. Copy the memory image to a dedicated, offline analysis VM. Running unknown-origin tooling or dumping malware executables onto a production endpoint risks re-infection and evidence contamination.
03 — METHOD 1: NATIVE INSTALL (pip + venv)
Phase 3 / 11The cleanest install on Linux or macOS is a dedicated virtual environment. This isolates Volatility's dependencies from your system Python and makes upgrades painless. This is the recommended path for most analysts.
A venv keeps yara-python, capstone and pefile pinned to versions Volatility expects, without polluting the OS. Create and activate it first.
The PyPI package pulls in the framework and its core dependencies. Add the optional extras to enable YARA scanning and disassembly — you will want both.
Installing via pip gives you the vol and volshell entry points on your PATH, so you can run vol -f image.raw windows.pslist from anywhere inside the venv — no need to call python3 vol.py.
Confirm the binary is on PATH and list the plugins it discovered. A healthy install prints its version and a long list of windows.*, linux.* and mac.* plugins.
04 — METHOD 2: DOCKER
Phase 4 / 11Docker gives you a disposable, reproducible analysis environment that can be destroyed after each case — a strong hygiene property when you are handling malware-laden images. Mount your evidence folder read-only and cache symbols in a named volume so they persist between runs.
Create a slim image based on the official Python base. This pins Volatility inside the container and keeps your host clean.
Mount your evidence directory read-only (:ro) so nothing can modify the image, and mount a named volume for the downloaded symbols so they are not re-fetched every run.
For recurring work, a compose file removes the long docker run line. Drop images in ./evidence, dumps land in ./output, and symbols persist in the named volume.
Because the entrypoint is vol, everything after the service name is passed straight through as Volatility arguments — the container behaves exactly like a local install.
05 — METHOD 3: WINDOWS & FROM SOURCE
Phase 5 / 11Many analysts acquire and triage on Windows. Volatility 3 runs natively there, and installing from the Git repository (on any OS) gets you the latest plugins and bug fixes before they hit PyPI.
Install Python 3.11+ from python.org (tick "Add python.exe to PATH"), then use a venv exactly as on Linux. Commands run from PowerShell.
If PowerShell blocks the activation script, run Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass in that session only — do not weaken the machine-wide policy.
The development tree carries plugins and fixes not yet released to PyPI. Clone it and install in editable mode so a git pull updates your install instantly.
If you only want the command-line tool and never import Volatility as a library, pipx installs it into its own isolated environment and exposes vol globally.
vol --helpprints a version banner and plugin list- The plugin list includes
windows.*,linux.*andmac.*entries - Optional extras loaded: yara-python and capstone import without error
windows.infoagainst a test image returns a build number
06 — FIRST RUN & SYMBOL TABLES
Phase 6 / 11Volatility 3 does not use profiles. Instead it identifies the OS build and locates matching ISF (Intermediate Symbol Format) tables. For Windows, it reads the kernel's PDB GUID from the image and downloads the matching symbols from Microsoft's public symbol server automatically on first run. Linux and macOS are different — you must supply symbols built from the exact kernel, covered in Phase 9.
Every invocation follows the same shape: global options, then -f and the image path, then the plugin name, then any plugin-specific options. The classic form using the bundled script is python3 vol.py -f <image> plugin.name --option.
Always start here. windows.info confirms Volatility can read the image, identifies the OS build and architecture, and triggers the symbol download. If this succeeds, every other Windows plugin will work.
The first run for a given build downloads a symbol pack (typically a few MB) and caches it. Later runs against the same OS build are offline and instant.
On an air-gapped analysis host, download the official Windows/Mac/Linux symbol packs ahead of time and drop them in the framework's symbols/ directory. Point Volatility at extra symbol locations with -s.
Symbol download uses outbound HTTPS to Microsoft's symbol server. On a truly isolated host with no pre-staged packs, Windows plugins will fail with a symbol-not-found error — see Phase 10.
07 — ACQUIRING A MEMORY IMAGE
Phase 7 / 11Volatility analyses an image; it does not capture one. Acquisition is a separate step, done on the live victim with a dedicated tool, ideally writing to external, forensically-sound storage. Volatility 3 reads raw/padded dumps, Microsoft crash dumps, LiME format, VMware saved state, and hibernation files (support varies by format).
| Platform | Tool | Output | Notes |
|---|---|---|---|
| Windows | WinPmem | .raw / .aff4 | Open-source, driver-based, widely used |
| Windows | Magnet RAM Capture / DumpIt / FTK Imager | .raw / .dmp | Free GUI/CLI options |
| Linux | AVML (Microsoft) | .lime | Static binary, no build step |
| Linux | LiME kernel module | .lime / raw | Requires matching kernel headers to build |
| Any VM | Hypervisor snapshot | .vmem / core | Cleanest capture — no agent on guest |
WinPmem is a single portable executable. Run it elevated and write the image to external media, never to the disk under investigation.
Writing the image to the same disk you are investigating overwrites unallocated space and can destroy deleted-file evidence. Always capture to separate storage.
AVML is a self-contained static binary that captures physical memory on most modern Linux kernels without building a module. Ideal for cloud VMs and containers' hosts.
The forensically cleanest capture touches nothing inside the guest. VMware writes a .vmem alongside a suspended VM; VirtualBox can dump a running VM's core to disk.
Record the acquisition tool, version, operator, timestamp and the image hash in your case notes at capture time. Chain of custody starts the moment RAM is copied — not when analysis begins.
08 — CORE INVESTIGATION WORKFLOW
Phase 8 / 11This is the heart of the tutorial: the plugin sequence a responder actually runs, in order, to go from "here is an image" to "here is the malicious process, its parent, its command line, its network sockets and its injected code." Run these against a triage image and pivot on whatever looks wrong.
| Order | Plugin | What it answers |
|---|---|---|
| 1 | windows.info | What OS/build is this, and can I read it? |
| 2 | windows.pslist / pstree | What was running, and who spawned it? |
| 3 | windows.psscan | Is anything hidden from the active list? |
| 4 | windows.cmdline | How was each process launched? |
| 5 | windows.netscan | What was it talking to? |
| 6 | windows.malfind | Is there injected/unbacked executable code? |
| 7 | windows.hashdump / lsadump | What credentials were exposed? |
Walks the active EPROCESS linked list — the same list Task Manager shows. Your baseline of "what was running." Look for odd parents, misspelled system names, and processes running from user or temp directories.
Renders the same processes as an indented tree so parent-child anomalies jump out — the classic winword.exe → cmd.exe → powershell.exe chain, or a services.exe child that should never exist.
Memorise the legitimate parents: services.exe and svchost.exe descend from wininit.exe; explorer.exe is spawned by a now-exited userinit. A svchost.exe whose parent is not services.exe is a red flag.
Scans memory pools for EPROCESS structures directly instead of trusting the linked list. Rootkits that unlink themselves disappear from pslist but still appear here. Diff the two outputs.
Extracts the full command line each process was launched with. This is often where the smoking gun lives: encoded PowerShell, staged download URLs, or LOLBins invoked with attacker flags.
dlllist shows every DLL a process loaded. ldrmodules cross-checks the three loader lists — a module present in memory but missing from one of them is a hallmark of reflective/unlinked DLL injection.
Reveal what a process could touch. getsids shows the account and groups it runs as; privileges lists enabled tokens (like SeDebugPrivilege); handles exposes files, keys and mutexes it held open.
Malware frequently creates a named mutex to avoid double-infection. A distinctive mutant name in handles output is a reusable IOC you can hunt for across the fleet.
Reconstruct sockets and connections that were live at capture. netscan pool-scans for network objects (finding closed/hidden ones too); netstat walks the tracked structures. Map foreign IPs to the owning PID.
A signed system binary or a browser talking to a strange host may be legitimate. Correlate the foreign IP against threat-intel and check whether the owning process is one that has any business making that connection.
The single most valuable hunting plugin. malfind finds memory regions that are executable, writable and not backed by a file on disk — the signature of shellcode, process hollowing and reflective loaders. An MZ header in a private RWX region is a strong hit.
Assess credential exposure. hashdump extracts local SAM NTLM hashes; lsadump pulls LSA secrets; cachedump recovers cached domain logons. These tell you what an attacker with the same access could have harvested.
Recovered hashes and secrets are live credentials. Treat the output as sensitive: store it encrypted, and force resets on any exposed account as part of eradication.
- The malicious PID(s), their parent chain and full command lines
- Any process hidden from the active list (pslist vs psscan diff)
- Injected/unlinked code regions dumped for further analysis
- Live C2 or backdoor sockets mapped to an owning process
- A credential-exposure assessment for scoped account resets
09 — ADVANCED ANALYSIS
Phase 9 / 11Once triage flags a target, dig deeper: dump artifacts for reverse engineering, scan memory with YARA, mine the in-memory registry, build a timeline, and — on Linux/macOS — supply custom symbols.
Carve artifacts out of the image for sandboxing or static analysis. pslist --dump writes the process executable; memmap --dump writes all its mapped pages; dumpfiles recovers cached files.
Sweep memory for known-bad byte patterns. windows.vadyarascan scans each process's virtual address space; the OS-agnostic yarascan scans the whole image. Pass a rule inline or a rules file.
The registry hives are mapped in memory. hivelist enumerates them; printkey reads a key — perfect for pulling persistence values like Run keys straight from RAM.
timeliner collects timestamped artifacts (process creation, handles, registry keys, network) into one chronological body you can sort to reconstruct the intrusion sequence.
For questions no plugin answers, volshell drops you into a Python REPL bound to the image, where you can inspect structures and read arbitrary memory. Select the layer with -w (Windows), -l (Linux) or -m (Mac).
Unlike Windows, Linux/macOS symbols are not on a public server. Build an ISF from the target kernel's debug info with dwarf2json, drop it in the symbols directory, then run the linux.* / mac.* plugins.
The linux.bash plugin carves command history straight from bash process memory — often recovering commands an attacker ran even after they cleared ~/.bash_history.
| Goal | Windows Plugin | Linux Equivalent |
|---|---|---|
| Process list | windows.pslist | linux.pslist |
| Process tree | windows.pstree | linux.pstree |
| Injected code | windows.malfind | linux.malfind |
| Network sockets | windows.netscan | linux.sockstat |
| Command history | windows.cmdline | linux.bash |
| Loaded modules | windows.dlllist | linux.lsmod |
10 — MAINTENANCE & TROUBLESHOOTING
Phase 10 / 11Most Volatility 3 problems are symbol, path or environment issues, not framework bugs. Keep the tool current and know the classic errors.
| Symptom | Likely Cause | Fix |
|---|---|---|
| "symbol table requirement ... not fulfilled" | No matching ISF for the OS build | Allow outbound HTTPS on first run, or pre-stage the symbol pack; for Linux, build ISF with dwarf2json |
| "unsatisfied requirement ... LayerRequirement" | Wrong/unsupported image format | Confirm the dump format; convert hibernation/crash dumps or re-acquire as raw |
| command not found: vol | venv not activated / pip scripts not on PATH | Re-activate the venv, or call python3 vol.py from the repo |
| Plugin runs but returns nothing | Wrong OS namespace (e.g. windows.* on a Linux image) | Run windows.info or banners to confirm the OS, then use the right namespace |
| MemoryError / killed on large image | Insufficient analysis RAM | Add RAM/swap to the analysis VM; scope plugins with --pid |
| yarascan errors on load | yara-python not installed | pip install yara-python inside the venv |
When you do not even know the OS, the OS-agnostic banners plugin scans for kernel version strings, telling you exactly which distro/build to source symbols for.
Save every command you run to a case log with script or shell history. Reproducibility is part of defensible forensics — a reviewer should be able to re-run your exact sequence against the same hash.
Volatility 2 is end-of-life and its Python 2 base is unsupported. New investigations should standardise on Volatility 3; only reach for v2 for a legacy plugin with no v3 port, and even then run it in an isolated container.
11 — SOURCES & REFERENCES
Phase 11 / 11Primary documentation and tooling referenced in this guide:
Turn a memory image into a verdict.
Pair this workflow with CyberHawk's incident-response SOPs and the IOC Scanner to validate hashes, mutexes and C2 addresses you recover from RAM. Explore the SOP library for step-by-step response playbooks, the IOC Scanner to triage indicators, and the blog for more hands-on DFIR tutorials.
◈ Stay Connected
Follow CyberHawk Threat Intel for threat intelligence, deployment guides and hands-on SOC tooling content.
"They can't exploit you if you are the Exploit."