Volatility 3 Memory Forensics Tutorial 2026 — Install, Configure & Hunt in RAM

·

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 02 Prerequisites & Requirements 03 Method 1 — Native Install (pip + venv) 04 Method 2 — Docker 05 Method 3 — Windows & From Source 06 First Run & Symbol Tables 07 Acquiring a Memory Image 08 Core Investigation Workflow 09 Advanced Analysis 10 Maintenance & Troubleshooting 11 Sources & References
🧠

01 — WHAT MEMORY FORENSICS IS & WHY DEFENDERS NEED IT

Phase 1 / 11

Random-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.

The five-stage loop this tutorial follows — acquire, identify, triage, hunt, extract.
📋

02 — PREREQUISITES & REQUIREMENTS

Phase 2 / 11

Volatility 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.

RequirementMinimumRecommended
Python3.8min3.11 or 3.12rec
Analysis RAM4 GB16 GB (parsing large images is memory-hungry)
Free disk2× image size3× image size (image + dumps + symbol cache)
OS (analysis host)Linux / Windows / macOSKali or Ubuntu VM, isolated from production
Internet accessFirst 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:

Bash — base tooling
# Install Python, pip, venv and git on Debian-based systems $ sudo apt update && sudo apt install -y python3 python3-pip python3-venv git # Confirm you have Python 3.8 or newer $ python3 --version Python 3.11.9

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 / 11

The 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.

01
Create an Isolated Virtual Environment
setup

A venv keeps yara-python, capstone and pefile pinned to versions Volatility expects, without polluting the OS. Create and activate it first.

# Create a project folder and a virtual environment inside it $ mkdir -p ~/dfir/volatility && cd ~/dfir/volatility $ python3 -m venv venv # Activate it (prompt changes to show (venv)) $ source venv/bin/activate (venv) $ python -m pip install --upgrade pip
02
Install Volatility 3 from PyPI
install

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.

# Core framework only (venv) $ pip install volatility3 # Or with YARA + disassembly + JSON schema extras (recommended) (venv) $ pip install "volatility3[full]" yara-python capstone

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.

03
Verify the Installation
verify

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.

# Print version and confirm the entry point works (venv) $ vol --help | head -n 5 # List every plugin Volatility can load (venv) $ vol --help | grep -E "windows\.|linux\.|mac\." | head
🐳

04 — METHOD 2: DOCKER

Phase 4 / 11

Docker 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.

04
Build a Volatility 3 Image
dockerfile

Create a slim image based on the official Python base. This pins Volatility inside the container and keeps your host clean.

Dockerfile
FROM python:3.12-slim RUN apt-get update \ && apt-get install -y --no-install-recommends git build-essential \ && rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir "volatility3[full]" yara-python capstone # Symbols cache lives here; mount a volume to persist it ENV XDG_CACHE_HOME=/symbols WORKDIR /cases ENTRYPOINT ["vol"] CMD ["--help"]
Bash — build it
$ docker build -t vol3:2026 .
05
Run Against a Mounted Image
run

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.

# Create a persistent symbol cache volume once $ docker volume create vol3-symbols # Run a plugin against ./evidence/mem.raw (read-only mount) $ docker run --rm -it \ -v "$PWD/evidence:/cases:ro" \ -v vol3-symbols:/symbols \ vol3:2026 -f /cases/mem.raw windows.pslist
06
docker-compose for Repeatable Cases
compose

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.

docker-compose.yml
services: volatility: build: . image: vol3:2026 volumes: - ./evidence:/cases:ro - ./output:/output - vol3-symbols:/symbols working_dir: /cases # override the entrypoint args at call time entrypoint: ["vol"] volumes: vol3-symbols:
Bash — invoke a plugin through compose
$ docker compose run --rm volatility -f /cases/mem.raw windows.info

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 / 11

Many 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.

07
Native Windows Install (PowerShell)
windows

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.

PS> python -m venv C:\dfir\vol\venv PS> C:\dfir\vol\venv\Scripts\Activate.ps1 (venv) PS> pip install "volatility3[full]" yara-python capstone # Run against an image (note Windows-style path) (venv) PS> vol -f C:\cases\mem.raw windows.pslist

If PowerShell blocks the activation script, run Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass in that session only — do not weaken the machine-wide policy.

08
Install from the Git Repository (Latest)
source

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.

# Clone the official Volatility Foundation repo $ git clone https://github.com/volatilityfoundation/volatility3.git $ cd volatility3 # Install dependencies (inside an active venv) (venv) $ pip install -e ".[full]" # The repo also ships vol.py directly — no install needed (venv) $ python3 vol.py -f mem.raw windows.info
09
Quick Install with pipx (Isolated CLI)
pipx

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.

$ sudo apt install -y pipx && pipx ensurepath $ pipx install volatility3 # Now vol is available system-wide without activating a venv $ vol --help | head -n 3
Installation verified when
  • vol --help prints a version banner and plugin list
  • The plugin list includes windows.*, linux.* and mac.* entries
  • Optional extras loaded: yara-python and capstone import without error
  • windows.info against a test image returns a build number
⚙️

06 — FIRST RUN & SYMBOL TABLES

Phase 6 / 11

Volatility 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.

10
Understand the Command Grammar
syntax

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.

# General grammar $ vol [global-opts] -f <image> <plugin> [plugin-opts] # Useful global options $ vol -r pretty -f mem.raw windows.pslist # -r pretty|json|csv|quick renderer $ vol -o ./output -f mem.raw windows.pslist # -o = output dir for dumps $ vol -vvv -f mem.raw windows.info # -v (repeatable) for verbose debug
11
Identify the Image with windows.info
identify

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.

$ vol -f mem.raw windows.info # Expected output (abridged): Variable Value Kernel Base 0xf80267a00000 DTB 0x1aa000 NTBuildLab 22621.1.amd64fre... IsPAE False Is64Bit True SystemTime 2026-09-25 14:02:11

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.

12
Manage & Pre-Stage Symbols
symbols

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.

# Symbols normally live inside the package's symbols/ folder $ python3 -c "import volatility3, os; print(os.path.dirname(volatility3.__file__))" # Add an alternate symbol directory for a case $ vol -s /opt/vol-symbols -f mem.raw windows.info

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 / 11

Volatility 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).

PlatformToolOutputNotes
WindowsWinPmem.raw / .aff4Open-source, driver-based, widely used
WindowsMagnet RAM Capture / DumpIt / FTK Imager.raw / .dmpFree GUI/CLI options
LinuxAVML (Microsoft).limeStatic binary, no build step
LinuxLiME kernel module.lime / rawRequires matching kernel headers to build
Any VMHypervisor snapshot.vmem / coreCleanest capture — no agent on guest
13
Windows — WinPmem
acquire

WinPmem is a single portable executable. Run it elevated and write the image to external media, never to the disk under investigation.

# Elevated command prompt on the victim; write to an attached E: drive C:\> winpmem_mini_x64.exe E:\evidence\HOST01-mem.raw

Writing the image to the same disk you are investigating overwrites unallocated space and can destroy deleted-file evidence. Always capture to separate storage.

14
Linux — AVML
acquire

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.

# Run as root; output is LiME format that Volatility reads directly $ sudo ./avml /mnt/evidence/host01-mem.lime # Hash immediately to establish integrity $ sha256sum /mnt/evidence/host01-mem.lime > host01-mem.lime.sha256
15
Virtual Machines — Snapshot the Guest
acquire

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.

# VMware: suspend the VM, then grab the .vmem from the VM folder # (the .vmem is a raw memory image Volatility reads directly) # VirtualBox: dump a running VM's memory to an ELF core $ VBoxManage debugvm "Victim-Win11" dumpvmcore --filename=host01.elf

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 / 11

This 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.

OrderPluginWhat it answers
1windows.infoWhat OS/build is this, and can I read it?
2windows.pslist / pstreeWhat was running, and who spawned it?
3windows.psscanIs anything hidden from the active list?
4windows.cmdlineHow was each process launched?
5windows.netscanWhat was it talking to?
6windows.malfindIs there injected/unbacked executable code?
7windows.hashdump / lsadumpWhat credentials were exposed?
16
List Processes — windows.pslist
triage

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.

$ vol -f mem.raw windows.pslist # PID PPID ImageFileName Offset Threads CreateTime 648 512 svchost.exe 0x... 12 2026-09-25 09:14:02 2044 648 rundll32.exe 0x... 3 2026-09-25 13:58:41
17
Visualise Parentage — windows.pstree
triage

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.

$ vol -f mem.raw windows.pstree # Filter to a suspicious subtree by PID $ vol -f mem.raw windows.pstree --pid 2044

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.

18
Find Hidden Processes — windows.psscan
rootkit

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.

$ vol -f mem.raw windows.psscan # Pull PIDs from both and compare — anything only in psscan is suspect $ vol -r csv -f mem.raw windows.pslist | cut -d, -f3 | sort > pslist.txt $ vol -r csv -f mem.raw windows.psscan | cut -d, -f3 | sort > psscan.txt $ comm -13 pslist.txt psscan.txt # processes hidden from pslist
19
Recover Command Lines — windows.cmdline
context

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.

$ vol -f mem.raw windows.cmdline # Focus on a single suspect PID $ vol -f mem.raw windows.cmdline --pid 3120 # 3120 powershell.exe "powershell -nop -w hidden -enc SQBFAF..."
20
Loaded Modules — dlllist & ldrmodules
injection

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.

$ vol -f mem.raw windows.dlllist --pid 2044 # ldrmodules flags injected DLLs (InLoad/InInit/InMem mismatch = False) $ vol -f mem.raw windows.ldrmodules --pid 2044
21
Tokens & Handles — privileges, getsids, handles
privesc

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.

$ vol -f mem.raw windows.getsids --pid 2044 $ vol -f mem.raw windows.privileges --pid 2044 $ vol -f mem.raw windows.handles --pid 2044 | grep -Ei "Mutant|File|Key"

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.

22
Network State — netscan & netstat
c2

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.

$ vol -f mem.raw windows.netscan # Proto LocalAddr:Port ForeignAddr:Port State PID Owner # TCPv4 10.0.0.5:52344 185.x.x.x:443 ESTABLISHED 2044 rundll32.exe $ vol -f mem.raw windows.netstat

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.

23
Detect Injected Code — windows.malfind
hunt

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.

$ vol -f mem.raw windows.malfind # Scope to a suspect PID and dump the offending regions to disk $ vol -o ./output -f mem.raw windows.malfind --pid 2044 --dump
24
Credential Material — hashdump & lsadump
creds

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.

$ vol -f mem.raw windows.hashdump $ vol -f mem.raw windows.lsadump $ vol -f mem.raw windows.cachedump

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.

After the core workflow you should have
  • 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 / 11

Once 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.

25
Dump Processes & Memory — pslist --dump, memmap, dumpfiles
extract

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.

# Dump a process's executable image $ vol -o ./output -f mem.raw windows.pslist --pid 2044 --dump # Dump the full mapped memory of that process $ vol -o ./output -f mem.raw windows.memmap --pid 2044 --dump # Recover cached files touched by the process $ vol -o ./output -f mem.raw windows.dumpfiles --pid 2044
26
YARA-Scan the Image — vadyarascan & yarascan
yara

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.

# Scan every process VAD for a string / rule file $ vol -f mem.raw windows.vadyarascan --yara-rules "cobaltstrike" $ vol -f mem.raw windows.vadyarascan --yara-file ./rules/apt.yar
Example YARA rule (apt.yar)
rule susp_reflective_loader { strings: $mz = "MZ" $s1 = "ReflectiveLoader" ascii wide $s2 = "This program cannot be run in DOS mode" condition: $mz at 0 and any of ($s*) }
27
Registry from RAM — hivelist & printkey
registry

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.

$ vol -f mem.raw windows.registry.hivelist # Read an autorun persistence key $ vol -f mem.raw windows.registry.printkey --key "Software\\Microsoft\\Windows\\CurrentVersion\\Run" # UserAssist — evidence of program execution $ vol -f mem.raw windows.registry.userassist
28
Build a Timeline — timeliner
timeline

timeliner collects timestamped artifacts (process creation, handles, registry keys, network) into one chronological body you can sort to reconstruct the intrusion sequence.

$ vol -r csv -f mem.raw timeliner > timeline.csv # Sort chronologically and eyeball the window around the alert $ sort -t, -k1 timeline.csv | less
29
Interactive Analysis — volshell
volshell

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).

$ volshell -w -f mem.raw # Inside the shell you can list processes, change context, and read memory: >>> ps() >>> display_bytes(0xf80267a00000, 64)
30
Linux & macOS — Custom Symbols
cross-os

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.

# Generate an ISF from the kernel's DWARF + System.map, then place it $ dwarf2json linux --elf vmlinux --system-map System.map > ubuntu.json $ cp ubuntu.json volatility3/symbols/linux/ # Now Linux plugins mirror the Windows ones $ vol -f host01-mem.lime linux.pslist $ vol -f host01-mem.lime linux.malfind $ vol -f host01-mem.lime linux.bash # recover shell history from RAM

The linux.bash plugin carves command history straight from bash process memory — often recovering commands an attacker ran even after they cleared ~/.bash_history.

GoalWindows PluginLinux Equivalent
Process listwindows.pslistlinux.pslist
Process treewindows.pstreelinux.pstree
Injected codewindows.malfindlinux.malfind
Network socketswindows.netscanlinux.sockstat
Command historywindows.cmdlinelinux.bash
Loaded moduleswindows.dlllistlinux.lsmod
🛠️

10 — MAINTENANCE & TROUBLESHOOTING

Phase 10 / 11

Most Volatility 3 problems are symbol, path or environment issues, not framework bugs. Keep the tool current and know the classic errors.

Bash — keep Volatility current
# PyPI install (venv) $ pip install --upgrade volatility3 # Source install — pull latest plugins and fixes (venv) $ cd volatility3 && git pull && pip install -e ".[full]" # Refresh cached symbol packs by clearing the cache $ rm -rf ~/.cache/volatility3
SymptomLikely CauseFix
"symbol table requirement ... not fulfilled"No matching ISF for the OS buildAllow outbound HTTPS on first run, or pre-stage the symbol pack; for Linux, build ISF with dwarf2json
"unsatisfied requirement ... LayerRequirement"Wrong/unsupported image formatConfirm the dump format; convert hibernation/crash dumps or re-acquire as raw
command not found: volvenv not activated / pip scripts not on PATHRe-activate the venv, or call python3 vol.py from the repo
Plugin runs but returns nothingWrong 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 imageInsufficient analysis RAMAdd RAM/swap to the analysis VM; scope plugins with --pid
yarascan errors on loadyara-python not installedpip install yara-python inside the venv
31
Identify an Unknown Image — banners
diagnose

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.

$ vol -f unknown-mem.raw banners # Reveals e.g. "Linux version 6.8.0-45-generic (Ubuntu ...)" to match symbols

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 / 11

Primary documentation and tooling referenced in this guide:

Volatility 3 Official Documentation — volatility3.readthedocs.io Volatility 3 — Windows Tutorial (getting started) Volatility Foundation — volatility3 (GitHub) dwarf2json — build Linux/Mac ISF symbol tables (GitHub) WinPmem — Windows memory acquisition (GitHub) AVML — Linux memory acquisition (Microsoft, GitHub) LiME — Linux Memory Extractor (GitHub) The Volatility Foundation

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.

🌐 Website ▶️ YouTube ▶️ YouTube (2) 𝕏 Twitter / X ♪ TikTok ✈️ Telegram
🔍 IOC Scanner 🛠️ Live Tools 📚 Courses 🚨 Threat Intel 📝 Blog 📋 SOPs

"They can't exploit you if you are the Exploit."