Memory Forensics: Acquisition, Volatility & Live System Analysis
RAM holds some of the most important evidence on a compromised system: running processes, network connections in progress, decryption keys in use, and injected code that was never written to disk. Fileless malware can live entirely in memory and never touch the drive at all. This chapter covers how to acquire that memory before it's gone and how to start pulling it apart.
Why Memory Matters
Disk forensics captures what a system has saved. Memory forensics captures what a system is doing right now, including things that were deliberately designed to never be saved.
| Disk Evidence | Memory-Only Evidence |
|---|---|
| Installed applications and files at rest | Running processes and their command-line arguments |
| Saved documents and downloads | Network connections currently open or recently closed |
| Registry hives as written to disk | Decrypted data and encryption keys actively in use |
| Malware binaries, if dropped to disk at all | Injected or unpacked malware code that never touched disk |
| N/A | Fileless malware that only ever existed in RAM |
This is why memory sits near the top of the order of volatility from chapter 1. Only CPU registers, cache, and live kernel state rank above it, and none of those can be collected in practice, which makes RAM the first source an examiner actually captures. Once a system is powered off or rebooted, everything in that right-hand column is gone permanently. Disk evidence can usually wait a few hours for a proper response; memory usually cannot.
Memory Acquisition
There are two broad ways to get memory content for analysis, depending on whether the system is still running.
Analysis With the Volatility Framework
Volatility is a widely used open-source memory analysis framework built around plugins, each designed to answer a specific question about the memory image. Exact plugin names and syntax vary between framework versions, so the table below stays at the category level.
| Plugin Category | What It Reveals |
|---|---|
| Process listing | Running processes, plus processes that were hidden or unlinked from the normal list |
| Network connections | Active sockets and recently closed connections still resident in memory |
| Process memory scanning | Injected code, where a process's in-memory content doesn't match what's expected for it |
| Command history | Commands typed into shells or consoles during the session |
| Registry hives in memory | Registry data loaded at capture time, sometimes ahead of what's flushed to disk |
Process and Injection Artifacts in Memory
Memory analysis is where a lot of malware behavior that hides well on disk becomes visible. A few patterns come up repeatedly.
- Parent-child anomalies: a process spawned by a parent that wouldn't normally spawn it, such as an office application launching a command shell.
- Process hollowing and injection signatures: a process whose in-memory code doesn't match its on-disk image, a strong indicator that legitimate process space was hollowed out and replaced.
- Hidden or unlinked processes: a technique sometimes called DKOM, where a process is removed from the visible process list in memory but is still actually running.
- Orphaned network connections: an otherwise ordinary-looking process holding a network connection that doesn't fit its normal behavior.
Limitations and Best Practices
Memory forensics is powerful, but it comes with real constraints an examiner has to plan around.
| Limitation | Practical Impact |
|---|---|
| Extreme volatility | Memory must be acquired first, or before disk in many response plans, or the evidence is lost forever |
| Anti-forensic tooling | Memory-wiping and scrubbing tools exist and can destroy evidence before an examiner ever arrives on scene |
| Single point in time | A memory image is only a snapshot; it doesn't show how the system got there |
Memory analysis is strongest when read alongside the disk and filesystem artifacts covered in chapters 2 and 3, not in isolation. A memory snapshot is a single point in time; the next chapter builds the timeline around it.
Key Takeaways
- Memory holds evidence disk never will: running processes, live network connections, decryption keys in use, and injected or fileless code.
- Memory can be acquired live from a running system, or recovered from existing sources like hibernation files, pagefiles, and crash dumps.
- Live acquisition tools leave a small footprint on the evidence, an accepted tradeoff against losing memory evidence entirely.
- Volatility is a plugin-based framework where each plugin category answers a specific question about the memory image.
- Process hollowing, hidden/unlinked processes (DKOM), and orphaned network connections are key injection indicators to look for.
- Because memory is the most volatile evidence source that can actually be collected, it must be acquired first or it's lost permanently once the system reboots or shuts down.
Knowledge Check
Click an answer to reveal the explanation.
Why must memory usually be acquired before other evidence during incident response?
A process's in-memory code doesn't match its on-disk image. What does this most likely indicate?
What is Volatility primarily used for in digital forensics?