MF0.1 Why Memory Forensics Matters

The disk is not the evidence

This section reframes the default DFIR mental model. Take from it the specific claim you make every time you collect only the disk — and why that claim has gone stale.

The disk is one class of evidence. The memory is another.

If you collect only the disk, you're making an implicit claim — that everything you need to prove was written to the filesystem by a cooperating attacker. That claim was roughly true in 2010. It isn't true now.

Modern attackers design their tooling to avoid disk writes because they know disk is what gets investigated. They run loaders in memory. They inject into legitimate processes. They harvest credentials without copying the credential file. They execute through PowerShell reflection, WMI subscriptions, and scheduled tasks that pull their real payload from a remote host at runtime. If you collect only the disk, you collect only the evidence the attacker left for you.

The shift didn't happen overnight. As endpoint tools got better at catching disk-based malware, attackers adapted.

PowerSploit made reflective PE injection a commodity in 2014. Mimikatz commoditised in-memory credential theft in 2015. By 2018 living-off-the-land binaries were a tradecraft category of their own — why write a custom binary when certutil.exe and mshta.exe are signed by Microsoft and will happily load a remote payload?

Recent intrusion reports from Mandiant, CrowdStrike, and the NCSC consistently show in-memory techniques in 70%+ of cases. If you learned DFIR in 2015 and haven't updated, you're investigating a decade-old threat landscape.

Four attack categories where memory is the decisive evidence

The four categories below are the vocabulary for scoping a memory engagement. When management asks why memory forensics is needed for this case, you answer from these four.

Four categories of attacker tradecraft produce investigations where memory is the deciding evidence. Disk can show you fragments. Memory shows you the whole picture.

Fileless malware. Code that executes without being written to disk. The delivery vehicle — an email attachment, an exploited document, a malicious ad — exists on disk. The payload itself doesn't.

PowerShell loads a base64-encoded DLL straight into its own address space via Invoke-Expression. A Word macro resolves a reflective loader and runs it. Shellcode delivered through an Office exploit executes inside WINWORD's process.

The disk contains the delivery vehicle. The memory contains the payload, its configuration, what it's already done, and the C2 it's talking to.

Here's what that looks like in practice. A Northgate Engineering finance workstation gets an alert from Defender for Endpoint for anomalous PowerShell behaviour. The disk tells you the email arrived, the attachment opened, a macro ran, and a PowerShell process started with an encoded command line. The EDR tells you the PowerShell process made outbound connections to an unfamiliar IP.

All true, all useful — and all of it is preamble. The interesting question is what the payload actually is, and the disk doesn't answer that.

$ vol -f workstation-mem.raw windows.pstree
# Shows WINWORD.EXE → powershell.exe → powershell.exe
# The chain the event log already implied. Memory confirms it was alive
# at acquisition and shows the child PowerShell that the log may not
# have captured cleanly.

$ vol -f workstation-mem.raw windows.malfind --pid <powershell-pid>
# Finds the reflective payload. A PAGE_EXECUTE_READWRITE region of
# private memory starting 4d 5a 90 00 — the MZ header of a Windows
# executable that doesn't match any DLL on disk. That's the thing the
# disk never saw.

Two commands, two answers the disk couldn't give you. Without them the report reads "PowerShell ran something suspicious and reached out to an IP." With them you have the payload, its C2, and a clean pivot to every other host running the same binary in memory.

In-memory credential theft. LSASS holds cached credentials, Kerberos tickets, DPAPI master keys, and secure strings for running processes. A Mimikatz-equivalent tool dumps them straight from LSASS memory — no file is ever written.

The disk tells you a suspicious process existed. Memory tells you which credentials were actually accessible at that moment, whether they're still valid, and whether the attacker got them.

Living-off-the-land execution. powershell.exe, wmic.exe, rundll32.exe, regsvr32.exe, mshta.exe, cscript.exe — all Microsoft-signed, all on every Windows install, all capable of executing remote payloads in memory.

When an attacker uses them, the disk shows a legitimate binary running a normal-looking command line. Memory shows what that binary actually did — the objects it loaded, the code it injected, the handles it opened.

You can't tell the difference between legitimate sysadmin use and attacker abuse from disk logs alone. Memory tells you what the process was actually doing.

Kernel-level compromise. A rootkit that hooks the system call table hides its own processes from Get-Process, its own files from directory listings, and its own network connections from WFP callouts.

A user-space EDR sees only what the rootkit allows. Disk forensics sees only files the rootkit makes visible. Memory analysis — specifically kernel-object enumeration and pool-tag scanning — sees the rootkit's own structures, because the rootkit can't simultaneously hide them from memory and remain functional.

When memory acquisition is mandatory

Four conditions that move memory from optional to required. These are the triggers your SOC procedure should encode so you're not making the call at 03:14 under business pressure.

Memory isn't required for every investigation. A commodity ransomware variant that wrote its executable to disk, a user-reported phishing email with a malicious link that was blocked, a routine alert that turns out to be a false positive — you can resolve these with disk and telemetry alone. Adding memory to every trivial case would grind your SOC to a halt.

The threshold is specific. Memory becomes mandatory, not optional, when any of four conditions are present.

Credentialed-user compromise suspected. If the attacker reached a state where they could authenticate as a user, the investigation has to account for what credentials were accessible, where they've been used since, and whether any session tokens are still live.

Credentials live in LSASS memory, not on disk. You can't answer those questions without memory.

Disk looks clean but telemetry says something's wrong. An EDR fires on process behaviour, a SIEM flags unusual network traffic, a honey-token hits — and disk investigation finds nothing.

That's not a false positive. That's an investigation that has found the attack is memory-resident and hasn't acquired the one piece of evidence that can confirm it.

Attribution matters past "a compromise occurred." Litigation, insurance claims, regulatory notification, HR proceedings — any of these need specific claims about what was accessed, what credentials were taken, what systems were reached.

For any attack involving memory-resident components, those claims can't be reconstructed from disk alone. If your conclusion is going to be challenged by someone else's expert witness, you need the memory.

Incident may recur. Persistence that lives entirely in memory — a WMI event consumer that re-injects a payload, a scheduled task that reloads from a remote host — survives reimaging if you don't address the reinfection vector.

Disk shows you reinfection happened. Only memory explains how.

What this course builds

Three capabilities, each a prerequisite for the next. The course sequence follows this order — acquire, interpret, correlate — and every module fits into one of the three.

Three capabilities, each one a prerequisite for the next.

Memory acquisition discipline. The ability to acquire memory from Windows and Linux systems in a way that preserves evidence integrity and survives legal scrutiny.

Memory is the most volatile forensic evidence you deal with. It exists only while the system is running, it changes with every CPU cycle, and it's gone at shutdown. Getting acquisition right — tool selection, verification, chain-of-custody documentation — is the foundation. No amount of analysis skill compensates for a capture that won't stand up in court.

Structure-level memory interpretation. Reading a memory image at the OS structure level, not just the plugin-output level.

Volatility 3 is a good tool. Like every tool, it has edge cases, version-specific behaviours, and parser limitations. If you understand the underlying structures — EPROCESS, ETHREAD, VAD, task_struct, cred — you can validate tool output, recognise anomalies tools miss, and interpret evidence plugins don't yet exist for.

This is the capability that separates a practitioner who runs Volatility from one who knows when Volatility is wrong.

Memory-evidence correlation. Integrating what memory shows with disk, network telemetry, and event logs into a unified timeline.

Memory alone gives you instant-in-time evidence. Disk alone gives you durable evidence. Network telemetry alone gives you external observation. None is enough on its own.

The defensible investigation uses all three, with memory as the primary source for anything that happened in-process during the acquisition window.