/analyzing-memory-images

name: analyzing-memory-images
description: Analyze volatile memory images (RAM dumps) using Volatility 3 — process enumeration, injected code detection, credential extraction, network artifacts, rootkit analysis, and timeline construction from memory-resident data. Use when examining a memory capture from a compromised host, hunting for injected code or hollowed processes, extracting credentials or network state from RAM, or detecting kernel-level rootkits.
verified: 2026-07-27

Analyzing Memory Images

Memory is the only place certain artifacts exist — injected code, decrypted payloads, credential material, and network connections from processes that have already exited. Disk forensics misses all of these. The work is getting the image before it is lost, then asking the right questions in the right order.

When to Use

• You have a memory dump (raw, LiME, EWF, crash dump, or VM snapshot) to analyze
• Investigating a compromised host and need artifacts that exist only in RAM
• Looking for injected code, process hollowing, or reflective DLL loading
• Extracting credential material — hashes, Kerberos tickets, cached credentials
• Identifying network connections and listening ports from a point-in-time capture
• Detecting kernel-level rootkits — SSDT hooks, DKOM, hidden drivers

When NOT to Use

• **Broader incident response methodology** — use `responding-to-incidents`
• **You have an acquired disk image, not a RAM capture** — use `analyzing-disk-images`
• **On-disk artifacts of a live/triage Windows host** — use `investigating-windows-endpoints`
• **Analyzing a known malware sample on disk** — use `analyzing-malware`
• **Writing detection rules from your memory findings** — use `engineering-detections`

Acquisition

Acquire memory before doing anything else on a live system. Every command you run on the box changes what is in memory. Image first, triage second.

# Linux — LiME (kernel module, minimal footprint)
sudo insmod lime-$(uname -r).ko "path=/evidence/mem.lime format=lime"
# Alternative: AVML (no kernel module needed, userspace)
sudo ./avml /evidence/mem.lime

# Windows — WinPMem (signed driver)
winpmem_mini_x64.exe mem.raw
# Alternative: DumpIt (single executable, click-to-run for non-technical staff)
DumpIt.exe /OUTPUT mem.raw /QUIET

# macOS — osxpmem is dead (Rekall archived, last release 2017, Intel-only, and
# blocked by SIP/kext restrictions on Big Sur+ and all Apple Silicon). Full-RAM
# capture on a modern Mac needs commercial tooling with Apple entitlements
# (e.g. Volexity Surge Collect); otherwise take process-scoped dumps and
# record that physical memory was not obtainable. See responding-to-incidents.

# VM snapshots — no agent needed
# VMware:   .vmem file alongside the .vmx (suspend the VM first for consistency)
# Hyper-V:  checkpoint creates .bin and .vsv in the snapshot directory
# KVM/QEMU: virsh dump <domain> mem.raw --memory-only
# VirtualBox: VBoxManage debugvm <name> dumpvmcore --filename mem.elf

# Crash dumps — partial but sometimes all you have
# Windows:  %SystemRoot%\MEMORY.DMP (complete dump), or minidumps
# Linux:    /var/crash/, kdump output, /proc/kcore (live, pseudo-file)

**Hash immediately after acquisition.** Record SHA-256, source host, timestamp (UTC), collection tool and version, and analyst name. If the image will be used in legal or regulatory proceedings, maintain chain of custody from this point.

Volatility 3 Workflow

Start with orientation, then follow the evidence. Do not run every plugin blindly — each question has a plugin that answers it.

Orientation

# Identify the OS profile and confirm the image is valid
vol -f mem.raw windows.info
vol -f mem.lime linux.bash
vol -f mem.raw banners.Banners    # fallback for unknown images

`windows.info` gives you the OS version, build number, and kernel base address. If this fails, the image may be corrupt, the wrong format, or require a custom symbol table. For Linux, you need the matching ISF (Intermediate Symbol Format) file — generate it from the kernel debug symbols of the exact kernel version.

Process Analysis

# Process listing — what was running
vol -f mem.raw windows.pslist     # walks the ActiveProcessLinks list
vol -f mem.raw windows.psscan     # scans for EPROCESS structures
                                          # (finds hidden/unlinked processes)
vol -f mem.raw windows.pstree     # parent-child relationships

# Compare pslist vs psscan: processes in psscan but not pslist were
# unlinked from the active list — this is DKOM or a terminated process
# that has not been fully cleaned up. Either is worth investigating.

**What to look for in the process list:**

• Processes with unusual parents (`svchost.exe` not under `services.exe`)
• Multiple instances of singleton processes (`lsass.exe`, `csrss.exe`)
• Processes with misspelled names (`scvhost.exe`, `lssas.exe`)
• Unexpected processes running as SYSTEM
• Processes with creation times that cluster around the suspected compromise

# DLL listing — what each process loaded
vol -f mem.raw windows.dlllist --pid <PID>
# Look for DLLs loaded from unusual paths (Temp, AppData, user-writable dirs)

# Handles — files, registry keys, mutexes, events
vol -f mem.raw windows.handles --pid <PID>
# Mutexes are especially useful: malware families often use characteristic
# mutex names to prevent re-infection

Injected Code Detection

This is where memory analysis earns its keep. Disk-based forensics cannot see code that was never written to a file.

# VAD-based detection — finds memory regions with suspicious protections
vol -f mem.raw windows.malfind
# Reports regions that are:
#   - Committed, private memory with PAGE_EXECUTE_READWRITE
#   - Containing a PE header (MZ magic) in a region not backed by a file
#   - Tagged as VadS (private) rather than VadF (file-mapped)

# Dump suspicious regions for further analysis
vol -f mem.raw windows.malfind --dump --pi