Why memory at all?

Disk forensics answers the question "what happened on this machine over time." Memory forensics answers a different one: "what is this machine doing right now." For a live intrusion, the second question is usually the one you care about.

Modern attackers know that EDR and disk imaging exist. So they increasingly avoid touching disk at all: PowerShell loaded reflectively, shellcode injected into a legitimate process, a Cobalt Strike beacon that only ever exists as pages in memory. Pull the plug on that machine and the evidence is gone. Not encrypted, not hidden. Gone.

That is the core argument for memory forensics: some evidence exists nowhere else.


What lives only in RAM

A surprising amount of investigative gold never touches disk:

Artifact Why it matters
Running process list Ground truth, including processes hidden from the API
Injected code and hollowed processes The main fileless malware technique
Active network connections Live C2 channels with PID attribution
Command line arguments The exact flags an attacker passed
Decrypted payloads Malware must decrypt itself to execute
Encryption keys TLS session keys, sometimes ransomware keys
Cleartext credentials LSASS holds password material on Windows
Console history and clipboard What the attacker typed and copied
Registry hives and cached files Faster to parse than a full disk image

Two of these deserve emphasis.

Decrypted payloads. Packers and crypters defeat static analysis on disk, but code has to be unpacked in memory to run. A sample that is unreadable as a file is often fully readable as a process memory region. This is why memory dumps are such productive YARA hunting grounds.

Network connections with context. Netflow tells you the machine talked to 198.51.100.23. Memory tells you it was svchost.exe with PID 4212, spawned by winword.exe, holding an established connection to port 443. That parent-child chain is the difference between an alert and a finding.


When memory beats disk imaging

You do not always need a memory image. You almost always need one when:

  • The alert suggests fileless or in-memory tradecraft (injection, reflective loading, LOLBin abuse).
  • The system is still running and possibly still compromised. Memory captures the live state; disk captures history.
  • Full-disk encryption is in play. The keys are in RAM while the system is up.
  • You need answers fast. A 16 GB memory image acquires and parses in minutes. A 2 TB disk image does not.
  • Ransomware is mid-execution. In rare but real cases, key material recovered from memory has enabled decryption.

The reverse holds too: for questions about persistence, timeline, or deleted files, disk wins. The two are complements, not rivals.


Acquisition: timing is everything

Memory is volatile by definition. Every second the machine runs, pages are recycled, processes exit, and connections close. Every action you take on the box overwrites evidence. The order of volatility from RFC 3227 still applies: capture memory before anything else, and before containment actions like rebooting or network isolation at the host level (pulling the network cable is usually fine; some malware detects isolation and self-terminates, which argues for capturing first regardless).

Practical options:

  • Software acquisition: WinPmem, DumpIt, or Magnet RAM Capture on Windows; AVML or LiME on Linux. Run from external media or a remote agent, write the image off-box.
  • EDR-based acquisition: most EDR platforms can pull a full memory dump or targeted process dumps remotely. Slower over WAN links, but no console access needed.
  • Hypervisor snapshots: for VMs, a snapshot with memory (.vmem plus .vmsn on VMware) is the cleanest capture available, with zero footprint on the guest.

Whatever the method, record the hostname, timestamp, tool, and hash of the image in your case notes. If you are coordinating a multi-host incident, tracking which systems have been captured is exactly the kind of task that belongs in a structured workflow like mlab IR rather than a chat thread.

One warning: acquisition itself perturbs memory. A 100 MB tool loading into RAM overwrites 100 MB of potential evidence. Use small, purpose-built tools and accept the trade.


A quick tour of Volatility 3

Volatility 3 is the standard open source framework for parsing memory images. It reads the raw image, reconstructs kernel structures using symbol tables, and exposes the results through plugins.


First pass: what is running

# List processes from the kernel's active process list
vol -f memory.raw windows.pslist

# Show the parent-child tree; orphaned or odd parents stand out
vol -f memory.raw windows.pstree

# Compare multiple process listing methods to spot hidden processes
vol -f memory.raw windows.psscan

Read pstree output the way you would read Sysmon logs: winword.exe spawning cmd.exe, svchost.exe with no services.exe parent, or two lsass.exe instances are all worth pulling on.


Command lines and network state

# Full command line for each process
vol -f memory.raw windows.cmdline

# Active and recently closed network connections with owning PID
vol -f memory.raw windows.netscan

netscan output pairs naturally with enrichment: feed the foreign addresses into mlab.sh to get reputation, passive DNS, and ASN context on each endpoint before you decide which connection is C2 and which is Windows Update.


Hunting injected code

# Find memory regions with execute permissions and no backing file
vol -f memory.raw windows.malfind

# Dump a suspicious process for deeper analysis
vol -f memory.raw windows.dumpfiles --pid 4212

malfind flags regions that are executable, writable, and not mapped to a file on disk, the classic signature of injected shellcode. Expect false positives from JIT compilers (browsers, .NET), so treat hits as leads, not verdicts. Dumped regions can be scanned with YARA rules or hashed and looked up like any other sample.


Credentials and history

# Cached registry hives
vol -f memory.raw windows.registry.hivelist

# Password hashes from the SAM (requires the right hives in memory)
vol -f memory.raw windows.hashdump

If credential theft is in scope, the presence of tools like Mimikatz in memory, or handles to LSASS from unexpected processes, is often the pivot point of the whole investigation.


Common beginner mistakes

  1. Rebooting before capture. The single most common way memory evidence dies. Put "capture RAM first" in your triage checklist.
  2. Trusting a single plugin. Rootkits unlink processes from lists. Cross-check pslist against psscan.
  3. Analyzing on the victim machine. Always move the image to a clean analysis workstation.
  4. Ignoring the pagefile. Pages swapped to disk extend the picture; grab pagefile.sys alongside the RAM image when you image the disk.
  5. No notes. Memory findings are dense. Log every command and its takeaway as you go, with timestamps.

Where to go next

Once the basics feel comfortable, the natural next steps are YARA scanning across process memory, timelining memory artifacts against EDR telemetry, and Linux memory analysis, which has its own acquisition quirks. Practice on public images: the Volatility Foundation and various DFIR challenge archives publish memory captures with known answers.

Disk tells you what happened. Memory tells you what is happening. Capture it first, before the evidence recycles itself out of existence.