July 10, 202612 min read

Memory Forensics: Capturing and Analyzing RAM to Find Malware That Disk Analysis Misses

Sources:Volatility Foundation|The Art of Memory Forensics (Ligh, Case, Levy, Walters)|SANS Memory Forensics Cheat Sheet

Eric Bang

Founder & Cybersecurity Evangelist

77%

of successful breaches in 2025 involved fileless or memory-resident malware techniques at some stage — disk forensics alone misses the majority of attack evidence

Volatility 3

the current standard open source memory analysis framework — supports Windows, Linux, and macOS memory images with 100+ analysis plugins

30 seconds

the approximate time to acquire a 16GB RAM image using WinPMem on a live Windows system — critical to capture before the system is rebooted and memory is lost

0 disk artifacts

fileless malware that runs entirely in PowerShell or reflectively loads DLLs creates zero file system artifacts — memory is the only forensic evidence source

RAM acquisition: capturing memory before it disappears

Memory must be acquired from a live system before shutdown. The acquisition process must be completed quickly — on cloud instances, evidence may be captured via snapshot; on physical or virtual machines, a memory acquisition tool runs on the live system.

WinPMem (Windows, open source, recommended)

WinPMem is the current standard open source Windows memory acquisition tool maintained by the Velocidex team. Acquisition: winpmem_mini_x64.exe memory.raw acquires a raw memory image to the specified file. For large RAM systems, use a compressed format: winpmem_mini_x64.exe -o memory.aff4 for AFF4 compressed output. WinPMem uses a kernel driver to access physical memory — requires admin privileges. Acquisition speed on a 16GB RAM system: approximately 30-60 seconds depending on I/O speed. Write the output to an external drive or network share, not the local disk being forensicated.

LiME (Linux Memory Extractor, open source)

LiME is a loadable kernel module for Linux memory acquisition. It must be compiled against the running kernel version — this typically means compiling on a system with the same kernel headers before deployment, or having a pre-built module ready. Acquisition: insmod lime.ko path=/mnt/external/memory.lime format=lime. LiME can also acquire over the network (format=tcp port=4444) to avoid writing to the local disk. For cloud Linux instances: EC2 instances can be acquired via instance snapshot if LiME is not available — the memory image in a running instance snapshot is accessible via the AWS Memory Extractor.

Cloud platform memory acquisition

For AWS EC2: AWS supports memory capture via the Amazon EC2 Instance Connect Endpoint or by creating an AMI snapshot that includes memory state. More reliably: deploy Velocidex Velociraptor (open source IR platform) as an agent, which provides remote memory acquisition without physical access. For Azure VMs: Azure does not provide native memory acquisition — deploy WinPMem via Azure Run Command and pull the output via Azure Blob Storage. For GCP: similar to Azure — use gcloud compute ssh with WinPMem, or deploy an IR agent.

What NOT to do during acquisition

Do not reboot before acquisition — RAM is volatile and reboot destroys all evidence. Do not run antivirus scans on the live system before acquisition — AV activity can overwrite memory regions being analyzed. Do not install acquisition tools to the local disk of the forensicated system (contamination) — run from an external drive or a network share. Do not acquire to the system's own disk — the disk write activity modifies free space and may overwrite deleted artifacts you need.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Volatility 3: the analysis framework

Volatility 3 is the current major version of the open source memory forensics framework. It uses symbol tables (ISF files) rather than profiles for OS identification — most modern Windows symbol tables are automatically retrieved from Microsoft's symbol server.

First steps: identify the OS and list processes

vol.py -f memory.raw windows.info — identifies the OS version, build, and kernel details from the memory image. vol.py -f memory.raw windows.pslist — lists all processes visible in the process list (EPROCESS linked list). Compare against: vol.py -f memory.raw windows.pstree — shows parent-child relationships (a cmd.exe spawned by a Word document is suspicious). vol.py -f memory.raw windows.psscan — scans memory for EPROCESS structures including processes that have been hidden from the normal linked list (rootkit detection).

Detect injected code and hollowed processes

vol.py -f memory.raw windows.malfind — the most important plugin for malware detection. malfind scans all process memory regions for: regions marked as executable+writable (normal code is executable but not writable — a writable+executable region indicates injected shellcode), regions starting with PE headers in unexpected locations (reflective DLL injection), and private memory regions with executable code (code not backed by a mapped file). malfind output includes the memory region hex dump — inspect for MZ headers (PE files) and x86/x64 shellcode patterns.

Network connections and active C2

vol.py -f memory.raw windows.netstat — lists all active network connections and listening sockets from the memory image. This captures connections that may not appear in system logs if the attacker tampered with event logging. Look for: unexpected outbound connections from system processes (svchost.exe connecting to external IPs on port 443 — potential C2), connections to IP addresses on non-standard ports, and connections from processes that should not communicate over the network (notepad.exe, explorer.exe with outbound connections).

Extract and analyze loaded modules

vol.py -f memory.raw windows.dlllist --pid [PID] — lists all DLLs loaded into a specific process. A DLL listed in memory that does not exist on disk (no corresponding file path) indicates an injected reflective DLL. vol.py -f memory.raw windows.dumpfiles --pid [PID] — extracts all memory-mapped files for a process to disk for further analysis (submit to sandbox, run through antivirus). Cross-reference extracted DLL hashes against VirusTotal.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

High-value memory artifacts for specific attack techniques

Different attack techniques leave characteristic memory artifacts. Knowing what to look for reduces analysis time.

Credential extraction from LSASS

Mimikatz and similar credential dumping tools target LSASS (Local Security Authority Subsystem Service) memory to extract NTLM hashes and plaintext credentials cached in WDigest. In memory forensics: vol.py -f memory.raw windows.lsadump — extracts cached credentials from the LSASS memory region (similar to what Mimikatz does, for forensic purposes). Also: look for evidence of credential dumping tools in malfind output targeting the lsass.exe process — injected shellcode in lsass address space is a strong credential theft indicator. Evidence of past credential dumping: check lsass.exe handle list for unusual process handles (a non-system process with a handle to lsass with PROCESS_VM_READ access).

Ransomware encryption keys in memory

During active ransomware encryption, the symmetric encryption key (AES key) used to encrypt files exists in the ransomware process's memory. If memory is captured during active encryption — before all files are encrypted and the key potentially wiped — it may be possible to recover the encryption key from memory. This is forensically significant: in some ransomware incidents, memory forensics during the active encryption phase has enabled key recovery and decryption without paying ransom. Use vol.py windows.malfind to identify the ransomware process, then dump that process's memory region for key extraction by a malware analyst.

PowerShell command history in memory

PowerShell-based attacks often use obfuscated or encoded commands that appear in PowerShell process memory even when transcript logging is disabled. vol.py -f memory.raw windows.cmdline — extracts the command line for all processes including PowerShell command arguments. For more detailed PowerShell history: search the raw memory image for PowerShell command buffer artifacts using strings and grep: strings memory.raw | grep -i 'invoke-expression|encodedcommand|iex|downloadstring' — finds PowerShell attack patterns in the raw strings. Decoded base64 payloads also appear in memory after decoding, even if the original command was encoded.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Linux and macOS memory forensics

Volatility 3 supports Linux and macOS memory analysis with the same plugin architecture. Linux analysis is particularly relevant for cloud server incidents.

Linux memory analysis with Volatility 3

vol.py -f memory.lime linux.pslist — lists running processes from the Linux memory image. vol.py -f memory.lime linux.netstat — network connections. vol.py -f memory.lime linux.malfind — detects injected code in process memory (executable+writable regions). For Linux-specific persistence: vol.py -f memory.lime linux.bash — extracts bash history from memory (bash keeps history in memory before writing to .bash_history — this recovers commands even if .bash_history was cleared). Critical for detecting LD_PRELOAD rootkits: compare process module lists from memory against disk — modules present in memory but not on disk are rootkit-injected.

Acquiring memory from a containerized environment

Containers share the host kernel — memory acquisition from the container host captures all container processes. Run WinPMem or LiME on the container host to acquire a memory image containing all container process memory. Alternatively: for Kubernetes environments, use Velociraptor deployed as a DaemonSet to acquire memory from affected pods without terminating the pod. Container memory forensics is an emerging field — container-specific process isolation means some Volatility plugins designed for bare-metal assume process isolation that containers may not provide.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

The bottom line

Memory forensics is the forensic discipline that exposes what disk analysis misses: fileless malware, injected code, active C2 connections, and decrypted payloads. The prerequisite is capturing RAM before reboot — WinPMem for Windows, LiME for Linux, cloud snapshots for cloud instances. Volatility 3's malfind, pslist, psscan, and netstat plugins address the most common incident response scenarios in under an hour of analysis. For organizations responding to sophisticated intrusions where disk forensics produces no findings, memory acquisition is the next step that often breaks the case open.

Frequently asked questions

Does memory acquisition require taking the system offline?

No — memory acquisition runs on the live system without requiring shutdown or reboot. WinPMem and LiME acquire from a running system. The system remains operational during acquisition, though there will be minor performance impact during the read. This is the key advantage of memory forensics: you capture the live state including active connections and in-memory malware without losing the evidence that a reboot would destroy. After acquisition completes, you have a point-in-time snapshot of RAM for offline analysis.

How do you analyze memory from a system you cannot physically access?

For remote memory acquisition: Velociraptor (open source IR platform) supports remote memory acquisition via an agent deployed on the endpoint — you trigger acquisition from the Velociraptor server and the memory image is uploaded to a collection server. For cloud VMs: use platform-specific mechanisms (AWS EC2 snapshot, Azure Run Command with WinPMem, GCP gcloud ssh). For EDR-integrated memory forensics: Crowdstrike Falcon, Microsoft Defender for Endpoint, and other enterprise EDR platforms include memory scanning capabilities that do not require full memory image acquisition — they run analysis modules against live process memory remotely.

What is the difference between Volatility 2 and Volatility 3?

Volatility 2 used 'profiles' — OS-specific data structure definitions compiled into the tool. Profiles required matching the exact OS version and build number. Volatility 3 uses ISF (Intermediate Symbol File) symbol tables derived from debug symbols, which are automatically retrieved from Microsoft's symbol server for Windows images — no manual profile selection required for most Windows versions. Volatility 3 also has improved performance for large memory images and a cleaner plugin API. Most new plugins are written for Volatility 3. Use Volatility 3 for new investigations; Volatility 2 legacy plugins may still be needed for very old OS versions or specialized use cases not yet ported.

Sources & references

Free resources

Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Author

Eric BangCISSP

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

View profile →LinkedIn

Back to all briefings

Subscribe for Updates

memory forensics RAM forensics Volatility framework fileless malware detection live memory acquisition incident response forensics process injection detection memory analysis 2026

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

Memory Forensics: Capturing and Analyzing RAM to Find Malware That Disk Analysis Misses

RAM acquisition: capturing memory before it disappears

Volatility 3: the analysis framework

High-value memory artifacts for specific attack techniques

Linux and macOS memory forensics

The bottom line

Frequently asked questions

Does memory acquisition require taking the system offline?

How do you analyze memory from a system you cannot physically access?

What is the difference between Volatility 2 and Volatility 3?

Sources & references

Critical CVE Reference Card 2025–2026

Ransomware Incident Response Playbook

Get threat intel before your inbox does.

Subscribe to enter the giveaway