Memory Forensics with Volatility 3: Analyzing Dumps in a Reproducible Lab

Three in the morning, SIEM alert, PowerShell process killed before the EDR could harvest artifacts. With no useful disk, all that remains is RAM. Memory forensics stopped being an academic luxury and became frontline work, especially against fileless malware and living-off-the-land tradecraft that never touches NTFS. In this lab we will reproduce a real scenario with Volatility 3.2, 8GB and 16GB dumps captured from Windows 11 23H2 and Ubuntu 22.04, validating findings against Rekall and MemProcFS. The premise: everything reproducible, no hand-waving. Anyone who has wrestled with profile mismatch knows that trusting a single tool is a recipe for a wrong conclusion in court.

Standing up the lab takes an afternoon. Use VirtualBox 7.0 or QEMU/KVM with 16GB of RAM dedicated to the target VM, a clean snapshot before each run, and capture via vboxmanage debugvm dumpvmcore or virsh dump --memory-only. For Windows, winpmem 4.0 still works; for Linux, Microsoft AVML delivers consistent dumps across kernels 5.x and 6.x. The lab from Web Pentesting From Scratch: Building a Safe Lab with DVWA, Juice Shop and Burp Suite doubles as a pre-incident traffic generator, and to detonate controlled payloads lean on the pipeline from Malware Analysis in an Isolated Lab: Safe Setup with FlareVM and REMnux. Record the SHA-256 hash of every dump at capture time, otherwise your chain of custody evaporates.

Volatility 3 dropped profiles in favor of symbol tables fetched on demand. Mandatory first command: vol -f dump.raw windows.info, which confirms kernel build, DTB and timestamp. Then run windows.pslist, windows.psscan and windows.pstree in parallel, always comparing them. A process that shows up in psscan but not in pslist is classic DKOM or unlinking via _EPROCESS. For the Linux case, linux.pslist.PsList and linux.bash are the entry points; bash recovers history from the heap, handy when the attacker scrubbed .bash_history but forgot about RAM. Note suspicious PIDs and move on to handles, dlls and malfind.

The real game-changer is windows.malfind. It sweeps VADs with PAGE_EXECUTE_READWRITE and a missing MZ header, catching classic injection. In one of my test dumps, malfind flagged explorer.exe PID 4820 with an RWX region holding 3.2KB of shellcode, hash matching a Sliver stager, tying directly into Building C2 Infra with Sliver in an Isolated Lab for Defensive Research. Cross-reference with windows.netscan to pull active sockets, even TCP in CLOSE_WAIT shows up. If the suspect talks to a non-RFC1918 IP, dump the process with windows.dumpfiles and feed Remnux for static analysis. For the offensive side of injection tradecraft, EDR Evasion for Research: Direct Syscalls Explained Without the Hype covers the other side of the table.

Linux cases demand a different vocabulary. linux.check_modules spots LKM rootkits via mismatches between /proc/modules and the kernel list, while linux.check_syscall identifies sys_call_table hooks by comparing addresses against System.map. In a dump infected with Diamorphine 1.0.7, check_syscall flagged 11 modified entries within seconds. For containers, the challenge doubles: the dump captures every namespace, but you still need to correlate PIDs with cgroups, a tedious process detailed in Container Forensics: Investigating Kubernetes Compromises Like a Pro. Pair it with host timelines built using Timeline Forensics on Windows: Plaso, Log2Timeline and KAPE in Practice to align disk and RAM events on the same temporal axis.

Cross-validation is not optional. Run the same dumps through MemProcFS, which mounts memory as a virtual filesystem under /mnt/memprocfs, letting you grep and find across kernel structures. Discrepancies between Volatility and MemProcFS usually trace back to stale symbol tables, refresh them with pdbparse. Document everything in a Jupyter notebook versioned in private Git, with cells reproducing each command, input hash and expected output. That discipline ties into OPSEC for Security Researchers: Building a Personal Threat Model: a forensic report leaks as much as an exploit. Practical takeaway: keep three gold-standard dumps in your lab, one clean, one with resident Mimikatz, one with an LKM rootkit, and test every new Volatility release against them before touching a real case.