TR1.5 Memory Acquisition: Tools, Techniques, and Verification

Figure TR1.5 — Memory acquisition tool selection. Each environment has a primary tool (lowest friction, fewest dependencies) and alternatives. Cloud instances require guest-level tools (AVML/WinPMEM) because hypervisor-level capture is not available on public cloud.

Windows memory acquisition with WinPMEM

Six-step method — Windows memory capture:

What to look for: A complete copy of the system’s physical RAM containing all running processes, their memory contents, loaded DLLs, kernel data structures, and network state.

Where to find it: Physical RAM, accessible via a kernel driver that WinPMEM loads temporarily.

How to extract it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# WinPMEM — pre-staged on triage USB at E:\tools\
# Run from elevated PowerShell (Administrator)
E:\tools\winpmem_mini_x64.exe E:\IR\%COMPUTERNAME%_memory.raw

# Expected output:
# WinPmem 4.0
# Loading driver...
# Driver loaded successfully.
# Acquiring memory: 16.0 GiB (17179869184 bytes)
# Progress: 100%
# Memory acquired successfully: E:\IR\DESKTOP-NGE042_memory.raw

How to interpret and verify the output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Verify dump size matches physical RAM
$dump = Get-Item "E:\IR\DESKTOP-NGE042_memory.raw"
$ram = (Get-CimInstance Win32_PhysicalMemory | Measure-Object -Property Capacity -Sum).Sum
Write-Host "Dump: $([math]::Round($dump.Length/1GB,2)) GB, RAM: $([math]::Round($ram/1GB,2)) GB"
# Acceptable: dump size within 90-100% of physical RAM

# Hash the dump for chain of custody
$hash = Get-FileHash "E:\IR\DESKTOP-NGE042_memory.raw" -Algorithm SHA256
$hash.Hash | Out-File "E:\IR\DESKTOP-NGE042_memory_hash.txt"
Write-Host "SHA256: $($hash.Hash)"

Critical: write the dump to EXTERNAL media (USB, network share), NOT the target system’s disk. Writing a 16 GB dump to the target’s C: drive overwrites 16 GB of unallocated disk space — potentially destroying deleted files that the investigation team could have recovered. The USB drive should be formatted with NTFS (FAT32 has a 4 GB file size limit — insufficient for memory dumps).

What WinPMEM captures that volatile triage commands cannot:

The ps and tasklist commands show the CURRENT process list at the moment they execute. A memory dump captures the process list PLUS: the full memory contents of each process (code, data, heap), the process environment block (PEB) containing loaded DLLs and environment variables, the kernel’s EPROCESS structure (including hidden processes that rootkits remove from the active process list), VAD (Virtual Address Descriptor) trees showing all memory regions (including injected code), and open handles (files, registry keys, network sockets, mutexes).

Volatility3 plugins extract this data from the dump: windows.pslist (process list), windows.pstree (parent-child relationships), windows.netscan (network connections with owning process), windows.malfind (injected code detection), windows.handles (open handles per process), windows.cmdline (full command lines), windows.dlllist (loaded DLLs per process), windows.hashdump (cached NTLM hashes from the SAM), and windows.lsadump (LSA secrets including service account passwords).

Linux memory acquisition with AVML and LiME

AVML (primary tool). Single static binary, no kernel module, no compilation required. Reads from /dev/crash or /proc/kcore.

1
2
3
4
5
6

# Pre-staged on triage USB
/mnt/usb/tools/avml /mnt/usb/IR/$(hostname)_memory.lime
# Verify
ls -lh /mnt/usb/IR/$(hostname)_memory.lime
free -h | grep Mem  # Compare sizes
sha256sum /mnt/usb/IR/$(hostname)_memory.lime > /mnt/usb/IR/$(hostname)_memory_hash.txt

LiME (fallback — higher quality, more complex). Kernel module that reads physical memory directly. Requires a pre-compiled .ko file matching the EXACT running kernel version.

1
2
3
4
5

# Check if pre-compiled module exists for this kernel
ls /mnt/usb/tools/lime/lime-$(uname -r).ko
# If yes: load and acquire
insmod /mnt/usb/tools/lime/lime-$(uname -r).ko "path=/mnt/usb/IR/$(hostname)_lime.raw format=raw"
# LiME writes the dump and auto-unloads the module

AVML vs LiME decision:

Use AVML when: rapid acquisition is needed (no preparation required), the kernel is 4.x+ (AVML requires /dev/crash or /proc/kcore), and you do not have a pre-compiled LiME module for the target kernel.

Use LiME when: AVML fails (restricted /dev/crash on hardened systems), you need the highest dump quality (LiME reads physical memory directly through the kernel, potentially capturing more consistent data), or the target is an older kernel where AVML’s /dev/crash reading is unreliable.

Pre-compiling LiME modules for your fleet: Maintain a directory of pre-compiled LiME .ko files for every kernel version running in your environment. After every kernel update: compile a new LiME module on a clean system with the matching kernel headers and add it to the triage USB. This 5-minute preparation step eliminates the “I don’t have a LiME module for this kernel” problem during incidents.

1
2
3
4
5
6

# On a BUILD system (NOT the compromised server):
apt install linux-headers-$(uname -r) build-essential git
git clone https://github.com/504ensicsLabs/LiME
cd LiME/src && make
# Output: lime-$(uname -r).ko — copy to triage USB
cp lime-$(uname -r).ko /mnt/usb/tools/lime/

ISF generation for Volatility3 — the critical dependency

Volatility3 cannot parse a Linux memory dump without an ISF (Intermediate Symbol Format) file matching the target kernel. The ISF maps kernel data structure offsets to named fields — without it, the raw memory is uninterpretable bytes.

Three ISF generation methods:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Method 1: dwarf2json (requires kernel debug symbols)
# Install debug symbols on a CLEAN system with the same kernel
apt install linux-image-$(uname -r)-dbgsym  # Ubuntu with dbgsym repos enabled
dwarf2json linux --elf /usr/lib/debug/boot/vmlinux-$(uname -r) > isf_$(uname -r).json

# Method 2: btf2json (for kernels 5.2+ with BTF — no debug symbols needed)
# BTF (BPF Type Format) is built into many modern kernels
btf2json /sys/kernel/btf/vmlinux > isf_$(uname -r).json

# Method 3: Pre-built ISFs from Volatility3 symbol repository
# https://github.com/volatilityfoundation/volatility3/tree/main/volatility3/symbols
# Search for your distribution + kernel version

Collect these during triage to enable ISF generation later:

1
2
3
4
5
6

uname -r > /IR/kernel_version.txt
cp /boot/config-$(uname -r) /IR/ 2>/dev/null
cp /boot/System.map-$(uname -r) /IR/ 2>/dev/null
ls /sys/kernel/btf/vmlinux > /IR/btf_available.txt 2>/dev/null
dpkg -l | grep linux-image > /IR/kernel_packages.txt 2>/dev/null
rpm -qa | grep kernel > /IR/kernel_packages.txt 2>/dev/null

Cloud and virtual machine memory acquisition

VMware ESXi / vSphere: Suspend the VM or create a snapshot. The snapshot includes a .vmem file containing the VM’s physical memory. Copy the .vmem file for Volatility3 analysis. Do NOT resume the VM before copying — resuming overwrites the suspended memory state.

Hyper-V: Create a checkpoint (Export-VM produces a .bin file containing memory). Or use WinPMEM from within the guest OS.

AWS EC2 / Azure VM / GCP Compute: Cloud providers do NOT offer hypervisor-level memory capture for customer VMs. Memory acquisition requires guest-level tools: deploy AVML (Linux) or WinPMEM (Windows) inside the instance. For EC2: use SSM Run Command to execute AVML remotely without SSH. For Azure: use Run Command via the Azure portal or CLI.

1
2
3
4
5

# AWS SSM: remote AVML execution (no SSH required)
aws ssm send-command --instance-ids i-0abc123 \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["cd /tmp && curl -sO https://INTERNAL_URL/avml && chmod +x avml && ./avml /tmp/memory.lime"]'
# Then copy the dump from the instance

Investigation Finding — IF-2026-TR1-MEM-001

Artifact: Memory acquisition procedure reference

Source: Operational standard — not incident-specific.

Findings:

Memory acquisition toolkit for the NE environment requires:

• Windows: WinPMEM v4.0 on triage USB. ISF auto-detected by Volatility3 for Windows 10/11 and Server 2016+.

• Linux: AVML v0.14.0 (primary) + pre-compiled LiME modules for 3 kernel versions currently deployed (5.15.0-88, 5.15.0-91, 6.1.0-18). ISFs pre-generated via btf2json for all 3 kernels.

• Cloud: WinPMEM/AVML deployed via SSM/Run Command. No hypervisor-level capture available.

• Proves: The NE triage toolkit supports memory acquisition across all 3 environments without preparation delays. Pre-compiled LiME modules and pre-generated ISFs eliminate the “I can’t analyse the dump because I don’t have the profile” problem.

• Does not prove: That the toolkit is current — kernel updates may introduce new versions that require new LiME modules and ISFs. The triage toolkit must be updated after every kernel patch cycle.

• Next step: Add toolkit maintenance to the monthly SOC operations checklist: after every kernel update, compile new LiME module, generate new ISF, add both to the triage USB.

Reference: Microsoft AVML (github.com/microsoft/avml), 504ensics LiME (github.com/504ensicsLabs/LiME), Volatility Foundation (github.com/volatilityfoundation/volatility3).

Troubleshooting

“WinPMEM fails with ‘Cannot load driver’.” Cause: Secure Boot or Driver Signature Enforcement is blocking the unsigned WinPMEM driver. Solutions: (1) Use the signed version of WinPMEM if available. (2) Temporarily disable Driver Signature Enforcement: bcdedit /set nointegritychecks on (requires reboot — not ideal during triage). (3) Use DumpIt or Magnet RAM Capture as alternatives (both use signed drivers). (4) If on a VM: use hypervisor-level capture instead.

“AVML fails with ‘Permission denied’ on /dev/crash.” Some hardened Linux configurations restrict /dev/crash. Try: avml --source /proc/kcore /IR/memory.lime. If both fail: use LiME with a pre-compiled kernel module. If LiME is also unavailable: document “Memory acquisition not possible on this system” and proceed with volatile state capture (ps, ss, w) as the best available alternative.

“The memory dump file is much smaller than physical RAM.” Common causes: (1) Insufficient disk space on the output media — check df -h. (2) The dump was written to FAT32 media (4 GB file size limit) — use NTFS or ext4. (3) AVML encountered memory regions it could not read and skipped them. A dump within 90% of physical RAM is acceptable for analysis; a dump below 50% may have significant gaps requiring re-acquisition with an alternative tool.