Your hard drive tells part of the story. RAM tells the rest.
When malware runs, it has to live somewhere. Modern attackers know you're going to image that disk, so they build their tools to exist only in memory. No files to find. No traces on disk. Reboot the machine and the evidence vanishes.
That's where memory forensics comes in.
What Memory Forensics Actually Is
Memory forensics is the analysis of a computer's RAM to extract evidence of what was running, what it was doing, and what it was connected to. Think of it as taking a snapshot of everything happening on a system at a specific moment.
Unlike disk forensics - where you're looking at files that were saved - memory forensics captures the live state. Running processes, network connections, encryption keys sitting in plaintext, injected code that never touched the filesystem.
Why Incident Responders Care
I've worked cases where disk analysis came up clean. Antivirus found nothing. Logs looked normal. But the client knew something was wrong - data was leaving the network.
Memory told the whole story. A fileless attack had injected malicious code into a legitimate process. It was beaconing out to a C2 server, exfiltrating data, and none of it ever wrote to disk.
Here's what memory gives you that disk forensics can't:
Running malware - Even fileless attacks have to execute somewhere. Memory captures the actual malicious code, even when it's hiding inside legitimate processes.
Decrypted data - Encrypted files are useless during disk analysis. But when software runs, it decrypts data into memory. Passwords, keys, decrypted documents - they're all there.
Network connections - Active connections, recently closed sockets, DNS queries. You see exactly what the machine was talking to.
Process injection artifacts - Attackers love hiding in trusted processes like svchost.exe or explorer.exe. Memory analysis reveals code that doesn't belong.
The Tools: Volatility 3
If you're doing memory forensics, you're probably using Volatility. It's the standard.
Volatility 3 reached feature parity with Volatility 2 in April 2025, and the older version is now officially deprecated. The rewrite was worth it - V3 is faster, more modular, and handles modern OS versions without the headaches.
Some plugins you'll use constantly:
- windows.pslist - Shows running processes. Your starting point for almost every investigation.
- windows.pstree - Same data, but shows parent-child relationships. Suspicious when cmd.exe spawns from Excel.
- windows.netscan - Network connections and listening ports. Find the C2 channels.
- windows.malfind - Hunts for injected code and suspicious memory regions. This is where you catch the fileless stuff.
- windows.cmdline - Shows command-line arguments for each process. Attackers often reveal themselves here.
The framework now uses a layered architecture with proper symbol tables, which means it handles the latest Windows and Linux versions without constant manual updates.
Getting Started
You need two things: a memory image and Volatility.
For capturing memory, tools like WinPMEM, FTK Imager, or Magnet RAM Capture will dump live memory to a file. Do this before you pull the power cord - once the machine reboots, that evidence is gone.
Then point Volatility at it:
vol -f memory.dmp windows.pslist
vol -f memory.dmp windows.malfind
vol -f memory.dmp windows.netscan
Start with the process list. Look for weird names, unusual parent processes, or anything running from temp directories. Then dig deeper into the suspicious ones.
The Takeaway
Disk forensics tells you what was saved. Memory forensics tells you what was happening.
If you're doing incident response without memory analysis, you're missing half the picture. And in a world where fileless attacks are increasingly common, it might be the half that matters most.
Grab a sample memory image from a test VM, install Volatility 3, and start exploring. The more comfortable you get with these tools before an incident, the faster you'll move when it counts.
