Memory Forensics Fundamentals: A Practical Introduction

When responders arrive at a compromised system, the instinct is often to image the disk and move on. It is a familiar workflow, well-documented and well-tooled. But disk imaging alone increasingly misses the most critical evidence in modern intrusions. Today's threat actors know how forensics works. They deliberately avoid writing to disk, load code directly into memory, and rely on the assumption that responders will collect their drives and send them to a lab — losing everything that was only ever in RAM.

Memory forensics closes that gap. A RAM capture taken from a live system preserves the runtime state of every running process, every active network connection, and every piece of code that was executing at that exact moment in time. For fileless malware, process injection attacks, and credential harvesting operations, it is often the only forensic evidence available.

This guide covers the practical fundamentals: why memory matters, when to capture it, how to capture it reliably, what artifacts to look for, and how to structure an analysis with Volatility.

Why Memory Forensics Matters

Disk forensics and memory forensics answer different questions. Disk forensics tells you what was installed, what files existed, and what executables ran. Memory forensics tells you what was actually happening at the moment of capture — what code was running, what connections were open, and what data was actively being processed.

The distinction matters enormously in modern intrusions for several reasons:

• Fileless malware leaves no disk artifacts. Techniques like PowerShell-based loaders, reflective DLL injection, and process hollowing execute entirely in memory. The malicious code never touches the file system in any recoverable form, so disk imaging produces nothing useful.
• Encryption keys and credentials are only in RAM. If an attacker has deployed ransomware but encryption is still in progress, the keys may be recoverable from memory. Similarly, tools like Mimikatz harvest credentials from the LSASS process — which can only be analyzed live or from a memory dump.
• Active network connections disappear at reboot. Netstat output shows what is connected right now. A memory dump preserves the network connection table, including connections to command-and-control infrastructure that the attacker may have since closed.
• Injected code does not appear on disk. Process injection techniques — CreateRemoteThread, APC injection, process doppelgänging — load attacker-controlled code into legitimate processes. The injected shellcode or DLL exists only in the memory of the target process. Without a memory dump, you cannot recover it.
• The clipboard and open documents. Clipboard contents, open browser tabs, and files currently being edited are all in memory. In insider threat and data exfiltration cases, this can be significant evidence.

The SANS Institute order of volatility — the foundational principle of evidence collection — puts RAM at the top of the list precisely because it disappears the moment power is lost. Treat it accordingly.

When to Capture Memory

The triage decision to capture memory should happen early, before you do anything else on the live system. Every action you take on a running system — running tools, opening files, even typing commands — modifies memory. The longer you wait, the more evidence you overwrite.

Capture memory when any of the following conditions apply:

• You suspect fileless malware or living-off-the-land techniques. If EDR or threat intelligence points to a threat actor known for in-memory execution (Cobalt Strike, Meterpreter, PowerShell Empire), memory capture is not optional — it is the primary collection target.
• You see unexplained network connections. An active connection to an unknown IP, particularly on ports commonly used for C2 (443, 80, 8080, 4444, 1337), warrants immediate memory capture before the connection drops.
• EDR or AV has triggered on process injection. If your detection tooling has flagged a CreateRemoteThread, code injection, or hollow process alert, the injected payload is currently in memory and can be extracted.
• A privileged process is behaving anomalously. If svchost.exe, lsass.exe, or explorer.exe is making unusual network connections or spawning unexpected child processes, memory will tell you whether it has been hollowed or injected into.
• Ransomware is detected before encryption completes. If you have caught an active ransomware deployment in early stages, there is a non-trivial chance that the encryption key material is still in memory and recoverable.

Conversely, memory capture is lower priority when the system has already been rebooted (memory is gone), when you are dealing with a historical incident rather than a live one, or when the available disk space and bandwidth make a 32 or 64 GB memory capture impractical during a rapid triage operation. In those cases, focus on disk artifacts and logs — but document the decision.

Memory Acquisition Methods

Acquiring memory from a live system requires a kernel-mode driver that can map and read physical memory pages. The tool runs on the target, reads RAM sequentially, and writes the output to a file (typically with a .raw, .dmp, .mem, or .lime extension). There are a handful of well-vetted acquisition tools used in professional IR work.

Windows: WinPmem and DumpIt

WinPmem is the open-source standard for Windows memory acquisition. It is maintained by the Rekall/Volatility community and outputs raw memory images compatible with Volatility. Usage is straightforward from an elevated command prompt:

winpmem_mini_x64_rc2.exe memory.raw

DumpIt (by Magnet Forensics) is another popular choice, particularly in enterprise IR engagements. It produces a .dmp file in Microsoft crash dump format, which Volatility can also parse. DumpIt is reliable, fast, and commonly pre-staged on IR jump kits.

Key considerations for Windows acquisition:

• Run as Administrator. Memory acquisition requires SYSTEM or Administrator privileges. Attempting to run without elevation will fail silently or produce a corrupt image.
• Write to an external drive. Never write the memory image to the same volume you are investigating. Use a USB drive or network share to avoid modifying the evidence system's file system artifacts.
• Verify the image. Hash the output file with sha256sum or certutil -hashfile immediately after capture. Document the hash in your case notes. This establishes integrity for any future evidentiary use.
• Note system specifications. Record the OS version, build number, and total physical RAM. You will need this to select the correct Volatility profile or symbol table during analysis.

Linux: LiME

LiME (Linux Memory Extractor) is the de facto standard for Linux memory acquisition. Unlike Windows tools, LiME requires compiling a kernel module for the specific kernel version running on the target system. This is most efficiently done in advance as part of IR preparation, compiling LiME against the kernel versions used in your environment.

insmod lime-5.15.0-91-generic.ko "path=/mnt/usb/memory.lime format=lime"

LiME can also stream memory directly over a TCP connection, which is useful when you cannot write locally. The receiving system captures the stream into a file for analysis.

On Linux, physical memory can sometimes be read directly from /dev/mem or /proc/kcore, but both are subject to kernel restrictions that often make them incomplete or unusable. LiME is the more reliable path.

Live vs. Dead Acquisition

Live acquisition captures RAM from a running system and preserves the full volatile state. Dead acquisition refers to techniques like extracting RAM from a hibernation file (hiberfil.sys on Windows) or a virtual machine snapshot. Both are valid sources for Volatility analysis:

• hiberfil.sys — Windows hibernation compresses and writes RAM to disk when the system hibernates. Tools like Volatility can decompress and analyze hibernation files directly, though they may not contain the most recent system state.
• VM snapshots — VMware (.vmem), VirtualBox, and Hyper-V all support memory snapshots. These are ideal for malware analysis and lab environments.
• Crash dumps — Windows kernel crash dumps (MEMORY.DMP) contain a subset of physical memory. Complete memory dumps capture the full physical address space and can be analyzed like a raw image.

Key Memory Artifacts

A raw memory image contains everything the operating system had loaded into physical memory at the moment of capture. The forensic value depends on knowing what to look for and where to find it within the memory structures.

• Process list and process tree. The OS kernel maintains a doubly-linked list of all running processes (EPROCESS structures on Windows). Comparing the process list derived from this structure to a separate scan of memory pages (pool tag scanning) can reveal processes that have been unlinked to hide from task managers — a classic rootkit technique.
• Network connections. Active and recently closed TCP/UDP connections are stored in kernel structures. Memory forensics can reveal C2 connections that have since been torn down but were active at the time of capture.
• Injected code and hollowed processes. Memory regions flagged as executable but with no backing file on disk are a strong indicator of injected shellcode. Process hollowing leaves a legitimate process image in memory replaced by attacker-controlled code, detectable by comparing the in-memory PE headers to the file on disk.
• Loaded DLLs and mapped files. Each process has a list of loaded modules. DLLs loaded from unusual paths, with spoofed names, or not present on disk indicate DLL sideloading or reflective loading attacks.
• Handles and open files. The handle table for each process records open file handles, registry keys, mutexes, and event objects. Mutexes in particular are useful IOCs — many malware families create named mutexes to prevent re-infection, and those names appear consistently across samples.
• Registry hives in memory. The Windows kernel caches active registry hives in memory. This allows extraction of registry keys that may not yet have been flushed to disk, including recently written persistence entries.
• Encryption keys and credentials. AES keys, RSA private keys, and WEP/WPA keys can sometimes be identified in memory by their statistical properties or surrounding context. LSASS process memory contains cached credentials in formats parseable by tools like Mimikatz, making LSASS dump analysis a standard step in credential theft investigations.
• Clipboard data. The Windows clipboard is stored in memory and can be extracted to reveal recently copied data, which in exfiltration investigations may include credentials, documents, or proprietary data.

Volatility Framework Primer

Volatility is the industry-standard open-source framework for memory forensics. It provides a plugin-based architecture that extracts and reconstructs OS data structures from raw memory images. Volatility 3 is the current release and no longer requires profiles in the traditional sense — it uses symbol tables downloaded automatically based on the OS build identified in the image.

Installation

Volatility 3 runs on Python 3 and installs cleanly via pip:

pip install volatility3

Alternatively, clone the repository directly for the latest development builds:

git clone https://github.com/volatilityfoundation/volatility3.git

The basic invocation pattern is:

python3 vol.py -f memory.raw [plugin]

Essential Plugins

A practical memory investigation typically begins with a small set of high-value plugins before drilling into specific areas of interest:

• windows.pslist — Lists all running processes from the kernel's active process list (PsActiveProcessHead). Shows process name, PID, parent PID, number of threads, and start time. This is always the first plugin to run. Look for processes with suspicious parent-child relationships (e.g., Word.exe spawning powershell.exe) and processes with names that mimic legitimate binaries (e.g., svch0st.exe).
• windows.psscan — Scans memory for EPROCESS pool tags rather than walking the process list. This finds processes that have been unlinked from the active list to hide from pslist. Discrepancies between pslist and psscan output are a strong indicator of rootkit activity.
• windows.netscan — Enumerates network connection structures from memory, including active and recently closed TCP connections, UDP listeners, and associated process information. Pay close attention to connections from unexpected processes (svchost.exe connecting to a residential IP on port 443) and connections to known-bad infrastructure.
• windows.malfind — Searches process memory for regions that are marked executable, are not backed by a file on disk, and contain patterns consistent with shellcode (e.g., PE headers in memory regions that should not have them). This is the primary plugin for detecting process injection and hollowing. It produces verbose output — expect false positives from JIT compilers, but any PE header found in a non-module memory region warrants closer examination.
• windows.dlllist — Lists all loaded DLLs for each process. Run it against a specific suspicious process using --pid to see its full module list. Look for DLLs loaded from temp directories, user-writable paths, or with names closely resembling legitimate system DLLs.
• windows.handles — Lists open handles for processes. Particularly useful for identifying named mutexes that serve as malware fingerprints, and for finding open handles to files or pipes that indicate inter-process communication with attacker infrastructure.
• windows.cmdline — Extracts the full command line for every running process from the Process Environment Block (PEB). This reveals the arguments passed to processes at launch, including encoded PowerShell commands, tool flags, and target IP addresses that may not be visible from the process name alone.
• windows.hashdump — Extracts NTLM password hashes from the SAM database in memory. Requires SYSTEM and SAM hive offsets. The output can be used with offline cracking tools or for pass-the-hash detection correlation.

Analysis Workflow

A structured approach prevents the common mistake of chasing interesting artifacts without maintaining investigative context. The following workflow is practical for most Windows memory investigations:

• Step 1 — Establish baseline. Run windows.info to confirm the OS version, build, and capture time. Verify the image is complete and parseable before investing analysis time.
• Step 2 — Process analysis. Run windows.pslist and windows.psscan in parallel. Identify all running processes, map the parent-child tree, flag anomalies. Look for processes running from unusual paths, processes with unexpected parents, and any discrepancies between the two plugins.
• Step 3 — Network review. Run windows.netscan. Map all external connections to geolocation and threat intelligence feeds. Flag any process making network connections that it should not be making. Correlate connection timestamps with process start times to establish sequence of events.
• Step 4 — Injection scanning. Run windows.malfind. For every flagged region, extract the bytes and check the signature. PE headers found in injectable process memory almost always warrant extraction and sandboxing. Use -o to dump flagged regions to files for further analysis.
• Step 5 — Module analysis. For each suspicious process identified in steps 2-4, run windows.dlllist --pid [PID]. Cross-reference every loaded module against a known-good baseline for that process. Submit unknown hashes to threat intelligence platforms.
• Step 6 — Command line and handles. Run windows.cmdline for the full argument list on suspicious processes. Run windows.handles --pid [PID] for specific processes to identify mutex names, open files, and pipe connections.
• Step 7 — Artifact extraction. Extract specific artifacts relevant to your investigation: registry hives with windows.registry.hivelist and windows.registry.printkey, credential material with windows.hashdump or windows.lsadump, and file artifacts with windows.filescan and windows.dumpfiles.

Throughout the workflow, maintain contemporaneous notes. Document every command run, every finding, and every investigative decision. Memory analysis can be non-linear, and it is easy to lose track of what you have already examined.

Common Findings in Real Incidents

Patterns emerge across different intrusion types. Knowing what to expect based on the threat actor category significantly accelerates analysis.

Fileless Malware

In Cobalt Strike and similar post-exploitation framework deployments, the beacon payload typically runs as an injected thread within a legitimate process. windows.malfind will flag the memory region, and dumping it will reveal either a Cobalt Strike beacon DLL (identifiable by its configuration block) or raw shellcode. The parent process is often a document viewer, browser, or scripting host that opened the initial dropper. windows.cmdline on the parent process frequently reveals the initial PowerShell or mshta command that loaded the payload.

Credential Harvesting

LSASS process memory is the primary target for credential theft. In cases where Mimikatz or similar tooling has run, you will often see evidence in two places: a suspicious process that made a handle request to LSASS (visible in windows.handles), and the LSASS process itself accessed by a process other than legitimate credential management services. In some cases, the output of the credential harvest is still in the memory of the attacking process as plaintext strings, recoverable with windows.strings filtered to the process memory range.

Lateral Movement Artifacts

Memory frequently preserves evidence of lateral movement that disk logs miss. WMI-based lateral movement often leaves transient process artifacts in memory that do not generate robust disk events. PsExec and similar tools may create temporary service entries visible in memory-resident registry hives even after the attacker cleaned up disk-based artifacts. Active SMB connections to internal hosts in windows.netscan output, originating from processes that should not be making internal network connections, are a reliable lateral movement indicator.

Ransomware Key Material

In active ransomware incidents caught early, memory sometimes contains recoverable key material. Ransomware implementations that generate the encryption key in memory before writing encrypted files may leave the key material in the heap of the ransomware process. While key recovery is not guaranteed — it depends entirely on the specific implementation and how much encryption has already completed — it is worth attempting on any system where ransomware is caught in the early encryption phase.

Building Memory Forensics into Your IR Process

Memory forensics is most valuable when it is a planned, default step in your response process rather than an afterthought. By the time you realize you should have captured memory, it is often already too late. Practical steps to institutionalize memory forensics in your IR capability:

• Pre-stage acquisition tools. Keep signed copies of WinPmem and DumpIt on your IR jump kit alongside write-protected USB drives with sufficient capacity for the largest systems in your environment (128 GB or more). For Linux environments, pre-compile LiME modules for every kernel version in production.
• Define triage triggers. Document explicitly which alert categories or triage findings trigger mandatory memory capture before any other response action. Process injection alerts, C2 connection detections, and credential theft indicators should all be on this list.
• Train responders on acquisition. Memory capture is simple but must be done correctly under pressure. Responders should practice the acquisition workflow regularly so that the steps are automatic during an incident. A corrupted or incomplete memory image collected under pressure is a common and avoidable failure.
• Automate collection where possible. EDR platforms and endpoint management tools often support remote memory acquisition or can be configured to trigger acquisition scripts on specific alert categories. Automated collection preserves memory state before a human responder is even on the call.
• Integrate Volatility into your toolchain. Build out a standard set of Volatility commands and analysis scripts tuned to your environment. Automate the initial triage plugins so that a new memory image can be processed through the first three analysis steps without manual intervention, freeing analysts to focus on interpreting results rather than running commands.
• Practice on known-bad samples. Download memory images from public repositories like the Volatility Foundation's sample images or capture samples from controlled malware detonations in your lab. Regular practice against known-bad images builds the pattern recognition that makes real-incident analysis faster and more accurate.

Memory forensics is a discipline, not a tool. The ability to consistently extract meaningful intelligence from a RAM image — quickly, under pressure, during an active incident — comes from repeated practice and a solid understanding of operating system internals. The tools are free and the sample images are available; the investment is in the time to develop the skill before it is urgently needed.

For broader coverage of the artifacts that complement memory analysis, the Windows Forensic Artifacts cheatsheet provides a structured reference for disk-based evidence sources, and the Linux Forensic Artifacts guide covers the equivalent evidence landscape on Linux systems.