Disk forensics tells you what an attacker left behind; memory forensics tells you what they were doing. Process injection, fileless loaders, in-memory-only beacons, plaintext credentials, TLS session keys — none of it reliably touches disk, and all of it lives in RAM. For a growing share of intrusions, the memory image is the primary evidence source, not a supplement.
Yet many teams treat memory capture as an afterthought, pulled hours into an incident after reboots and remediation have already destroyed the most valuable artifacts. Getting value from memory forensics is mostly about doing unglamorous things early and in the right order.
Acquisition: The Step You Cannot Redo
Order of volatility is not academic. Every minute a compromised host keeps running, process pages get reallocated, network connections close, and injected code may unload itself. The practical rules:
- ▸Capture before containment where possible: network isolation is usually safe to do first, but do not reboot, do not run antivirus scans, and do not let helpdesk clean the machine before imaging.
- ▸Use a tested tool per platform: WinPmem or your EDR's acquisition capability on Windows, AVML on Linux; for virtual machines prefer hypervisor-level capture — a VMware .vmem file or a paused KVM domain gives a consistent image with zero footprint on the guest.
- ▸Hash and record immediately: SHA-256 of the image, hostname, acquisition time in UTC, tool and version, and who ran it. Chain of custody starts at capture, not at the lab.
- ▸Grab the pagefile and hibernation file too: on Windows, pagefile.sys and hiberfil.sys extend your view of memory considerably and cost little to collect alongside.
Expect smear on busy systems: a software acquisition reads memory over seconds while the kernel keeps mutating it, so some structures will be internally inconsistent. That is normal — and it argues for corroborating findings across multiple plugins rather than trusting any single artifact.
Analysis with Volatility 3
Volatility 3 resolved the biggest operational pain of version 2 — profile guessing — by moving to symbol tables, which makes it far more dependable against modern Windows builds. A workable first-pass sequence:
1. Enumerate processes two ways: the pslist view of the active process list, and the psscan view that carves process structures from raw memory. Discrepancies between them are your first lead — unlinked or exited processes that scanning still finds. 2. Review network artifacts with netscan and correlate listening sockets and established connections against what the host should be doing. 3. Run malfind to flag memory regions with execute permissions and no backing file — the classic signature of injected code — and dump candidates for static analysis. 4. Check command-line history and console buffers; attackers' typed commands survive in memory long after logs are cleared. 5. Sweep the whole image with your YARA rule set. In-memory scanning catches unpacked payloads that never exist on disk in decrypted form.
Treat malfind output with skepticism: JIT compilers, some copy-protection schemes, and .NET runtimes produce legitimate executable regions without file backing. False positives are the tax; corroboration across process, network, and code artifacts is how you pay it down.
When Memory Beats Everything Else
Certain questions are answerable only in RAM. Credential exposure — what LSASS held when the attacker ran their dumper — determines the true scope of your password reset. Full-disk encryption keys, container secrets injected as environment variables, and decrypted command-and-control traffic all live in memory. And for fileless attacks staged entirely through PowerShell or living-off-the-land binaries, memory plus the event logs is frequently the entire evidentiary record.
That makes a standing capability worth building before you need it: acquisition binaries staged on a read-only share, per-platform runbooks tested quarterly, and enough storage to hold images from your largest hosts. A database server with 256 GB of RAM produces a 256 GB file, and discovering mid-incident that you have nowhere to put it is a bad way to learn.
The investment pays back well beyond the forensics lab. Teams that can answer what exactly the attacker accessed with memory-backed evidence make better-scoped disclosure decisions, avoid over-rotating on resets and rebuilds, and cut the duration of the most expensive phase of any incident: uncertainty. In regulated environments where you must justify why a breach was or was not reportable, an evidence trail that starts with a properly hashed memory image is the difference between a defensible position and an educated guess.