Module 3 · Memory Forensics with Volatility 3

Manish Garg
Manish Garg Associate of (ISC)² · RingSafe
May 13, 2026
4 min read
Read as
100% Free

No signup. No paywall. No catch. One of our 10 most-requested practitioner modules — published in full so anyone can learn for free. We earn through consulting, not by gating knowledge.

See all 10 free modules →

Why this module exists. Memory forensics — capturing and analysing RAM contents — surfaces evidence that never touches disk: in-memory malware, decrypted volume keys, the actual command history of a live attacker, and a thousand process states a defender cannot see any other way. This module covers acquisition (LiME, Magnet RAM Capture, AVML) and analysis with Volatility 3.

Why this module exists. Half the modern malware ecosystem never writes a payload to disk — it lives in memory, injected into legitimate processes, and dies at reboot. Without memory forensics you are flying blind on that whole class. This module is the practitioner workflow.

Acquisition — get the memory before you lose it

Memory acquisition is the most fragile forensic activity: every running process is changing memory contents. Two principles:

  • Image memory before disk. Powering down or even imaging disk first will lose volatile state.
  • Use a tool that runs from removable media, with minimal memory footprint. The tool itself necessarily occupies some memory; minimise it.
# Linux — LiME (Linux Memory Extractor)
sudo insmod lime.ko "path=/evidence/mem.lime format=lime"

# Linux — AVML (Microsoft's memory acquisition for Azure VMs, works elsewhere)
sudo ./avml /evidence/mem.lime

# Windows — Magnet RAM Capture (free for IR)
# Run from USB stick, output to external evidence disk

# Cloud — for EC2, EBS-snapshot the volume and use the AWS Memory
# Forensics workflow (no in-instance acquisition needed)

Volatility 3 — the standard analysis tool

Volatility 3 is the canonical memory analysis framework. Plugins are organised by what they extract. The first five plugins you run on any image:

# Identify the OS profile (Volatility 3 detects automatically)
vol -f mem.lime windows.info       # for Windows images
vol -f mem.lime linux.info         # for Linux images

# Process tree — the foundation of every memory investigation
vol -f mem.lime windows.pstree
# parent-child hierarchy; orphan processes are highly suspicious

# Hidden processes — comparing pslist (linked list) vs psscan (carving)
vol -f mem.lime windows.pslist
vol -f mem.lime windows.psscan
# Differences = processes hidden by rootkits

# Network connections
vol -f mem.lime windows.netscan
# Process-mapped connections; look for unexpected outbound

# Loaded DLLs per process
vol -f mem.lime windows.dlllist --pid 4242
# DLLs from non-standard paths = injection

What you are looking for — the high-signal patterns

  1. Process injection. A legitimate process (svchost.exe, explorer.exe) with a DLL loaded from C:\Windows\Temp or %APPDATA% is classic injection. The malfind plugin surfaces processes with executable pages not backed by a file.
  2. Process hollowing. A legitimate process image was replaced after creation. The process’s image base does not match the on-disk file; malfind and hollowfind detect this.
  3. Suspicious network connections. Outbound to unfamiliar IPs, beaconing patterns, encoded HTTP traffic. Correlate with the parent process via netscan.
  4. Command history. linux.bash for bash history in memory; windows.cmdline for running command lines. Often shows the actual attacker commands that PowerShell logging missed.
  5. Credentials in memory. windows.lsadump.Lsadump extracts LSA secrets, cached domain creds, hashes. The post-compromise picture is usually here.

Real-world walkthrough — finding Cobalt Strike

Cobalt Strike beacons are the canonical memory-only payload. The signature:

  • A legitimate Windows process (often rundll32.exe, svchost.exe, or a recently-spawned notepad.exe) with an executable page not backed by a file.
  • The page contains the Beacon configuration encoded with a known transform (XOR with 0x2e or 0x69 historically; newer profiles vary).
  • Volatility’s malfind + the third-party volatility-cobaltstrike plugin extract the C2 configuration directly.
vol -f mem.lime windows.malfind
# Look for executable pages with no backing file. The dump is the beacon shellcode.

# With the third-party plugin:
vol -f mem.lime --plugin-dirs ./plugins windows.cobaltstrikescan
# Surfaces the C2 URL, sleep time, jitter, and other config fields directly.

Anti-forensics and limitations

  • Anti-VM detection in advanced malware can refuse to fully decrypt in memory if VM artefacts are detected. Use bare-metal acquisition where possible for high-stakes IR.
  • Encrypted page tables (Intel TDX, AMD SEV) prevent host-level memory acquisition for confidential VMs. Memory forensics is moving to in-guest acquisition only.
  • Memory after reboot is gone. Plan acquisition before triage decisions force shutdown.

Key takeaways

  • Memory before disk — volatile data dies first.
  • LiME on Linux, Magnet RAM Capture or AVML on Windows, EBS snapshot for cloud VMs.
  • Volatility 3 plugins: pstree, pslist vs psscan, netscan, dlllist, malfind.
  • High-signal patterns: process injection, hollowing, suspicious outbound, in-memory credentials.
  • Cobalt Strike configuration extracts directly from memory with the right plugin.
Worried about your exposure?

Get a free attack-surface review

We check what an attacker would see about your business — leaked credentials, exposed services, dark-web mentions. 30 minutes, no obligation.

Book exposure review Replies in 4 working hrs · India-only · Senior consultants