memory forensics with Volatility 3

why memory forensics even matters

your disk is a photo album. your memory (RAM) is the security camera footage of what's actually running right now. malware that's smart about hiding will scrub its traces off disk but it still has to run in memory to do anything, and running processes leave a mess you can find if you know where to look. that's the whole pitch behind memory forensics: catch the thing while it's live, or reconstruct exactly what happened after the fact using a memory dump.

volatility 3 is the open-source tool most DFIR folks reach for. no license, no paywall, just python and a memory image. if you're a defender who wants to understand what a compromise actually looks like at the memory level, this is the toolkit to learn.

getting a memory image in the first place

before you can analyze anything you need a capture. tools like winpmem, dumpit, or a hypervisor snapshot (if the box is a vm) will get you a raw memory image. treat that file like evidence: hash it, store it somewhere safe, and don't run it on the live box you're investigating. once you've got memory.img, volatility does the reading.

windows.pslist and pstree, spotting a bad parent

this is your starting point, basically "what's running."

vol.py -f memory.img windows.pslist

pslist walks the kernel's process list and shows you PIDs, parent PIDs, process names, and start times. pstree does the same thing but draws it as a tree so you can see who spawned who. the reason this matters: legitimate processes have predictable parents. svchost.exe should be a child of services.exe. word shouldn't be spawning powershell. explorer shouldn't be the parent of a process with a random hex name sitting in a temp folder. if you see a weird lineage, that's your lead. write down the PID and keep pulling threads on it.

windows.netscan, connections a rootkit tried to hide

vol.py -f memory.img windows.netscan

netscan reads the kernel's network structures directly out of memory instead of asking the OS "hey what connections do you have," which matters because a lot of malware hooks the normal APIs so tools like netstat just lie to you. netscan bypasses that by parsing the raw data structures, so it can surface connections that the compromised system is actively trying to hide. look for connections to unfamiliar external IPs, weird ports, or a process that has no business talking to the network at all (why is notepad.exe holding an open TCP connection?).

windows.malfind, executable memory means injection

vol.py -f memory.img windows.malfind

this one's about memory permissions. normal code lives in memory regions marked read and execute, but not usually writable and executable at the same time, that combo is a classic sign of code injection (process hollowing, reflective DLL loading, shellcode dropped into a legit process). malfind scans memory regions for pages with suspicious permission flags and no backing file on disk, which is exactly what injected code looks like since it didn't come from a normal file load. if malfind flags a region inside, say, explorer.exe, that's a strong signal something injected itself into a trusted process to hide.

windows.cmdline, exactly how it was launched

vol.py -f memory.img windows.cmdline

once you've got a suspicious PID from pslist or malfind, cmdline tells you the exact command line arguments that process was started with. this is huge for understanding intent. a plain powershell.exe entry is boring. a powershell process launched with -enc followed by a giant base64 blob is not boring, that's an obfuscated command and it's begging to be decoded and read.

the takeaway

you don't need volatility 3 to be a full time job, you need it as a habit. if you ever suspect a machine on your network got popped, capture memory before you reboot it, because rebooting throws away everything volatility can see. run pslist and pstree to check your process tree for weird parents, netscan to catch hidden connections, malfind to catch injected code, and cmdline to understand how something was actually launched. do this on your own test machines first so you know what "normal" looks like before you're staring at an incident trying to tell normal from malicious under pressure. the tool is free, the skill is what's valuable, and building it now means you're not learning memory forensics for the first time during an actual breach.