Memory Forensics with Volatility

Step 1 — Capture first, think second

Before you do anything else, dump memory. Use a tool your incident response plan has pre-approved — winpmem, Velociraptor in offline collector mode, or DumpIt for Windows; AVML or LiME for Linux. Save the dump to an external, write-blocked target where the responder cannot accidentally touch it.

Compute and record hashes immediately. The dump's integrity is going to matter if this incident ever ends up in front of lawyers, insurers, or regulators. A hash at capture time costs nothing; a missing hash at deposition time costs the case.

Step 2 — Identify the profile

Launch Volatility and let it guess the profile with imageinfo in v2 or the automatic symbol search in v3. If your target is Windows 10 1903 or newer, Volatility 3 is the right tool — it uses symbols instead of profiles and handles modern memory layouts much more reliably.

A small tip: keep a mirror of Microsoft's public symbol server on a trusted internal host. Volatility 3 on an air-gapped forensics workstation without symbol access is painful.

Step 3 — Walk the processes

The first view I want is the process tree. windows.pslist gives me a flat list; windows.pstree shows the parent-child relationships. I am looking for:

Processes running from unusual paths — C:\Users\Public, %TEMP%, %APPDATA%.
Unexpected parent-child pairs: winword.exe spawning powershell.exe spawning cmd.exe is never legitimate.
Processes with no parent — orphans that the parent already exited from.
Duplicate system process names running from the wrong path — svchost.exe from Downloads is a red flag.

Each one of these is a 30-second lead to a concrete hypothesis.

Step 4 — Look at the network

windows.netscan surfaces active and historical TCP/UDP sockets from the memory dump. I correlate by PID with the suspicious processes from step three. An unexpected outbound connection from a process that has no business talking to the internet is one of the most reliable indicators of compromise I know.

Cross-reference the destinations against your threat intel feed. If the same indicator lit up your firewall last week and you ignored it, the root-cause analysis just got much faster.

Step 5 — Look for injected code

windows.malfind scans process memory for regions that are committed, executable, and have no backing file on disk — the signature of most process-injection techniques. Every hit gets triaged: which process, which address, how big, and does the memory look like shellcode or a mapped PE?

Not every malfind hit is malicious. JIT engines, .NET runtimes, and some packers create legitimate RWX regions. You learn the baseline of your environment through repetition.

Step 6 — Capture strings from suspicious regions

Once I have identified an injected region, I extract it with windows.vadinfo and windows.vaddump and run strings over the extracted bytes. I am looking for:

Command-and-control domains or IP addresses
HTTP User-Agent strings or URI paths
Hard-coded file paths, mutex names, registry keys
Known malware family markers

Even a handful of strings is enough to start pivoting — a domain you can block at the proxy, a User-Agent you can hunt for across EDR, a mutex you can search for on neighboring hosts.

Step 7 — Build the story

Everything above feeds one deliverable: a timeline. Who spawned what, when, with what arguments, talking to where. Timestamps come from windows.cmdline, windows.handles, process creation times in pslist, and the memory capture time itself.

A good memory-forensics report answers three questions in the first paragraph: what did the attacker do, how did they get in, and what should you do right now. Everything else is evidence supporting those three answers.

A word on triage mindset

Memory analysis is easy to rabbit-hole on. Set a time-box: "I have 30 minutes to either find a concrete lead or escalate for more resources." Stick to it. If you are two hours in and still wandering through process lists, the answer is more people, not more time.

The best forensic analysts I know are not the ones who can name every Volatility plugin from memory — they are the ones who know when to stop digging in one dump and pick up another data source.

Written by Sari Taher. Based on live enterprise DFIR engagements.