analyzing-memory-images

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 responding-to-incidents
• 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)