TR1.5 Memory Acquisition Across Platforms

Figure TR1.5 — Memory acquisition tool selection. Windows uses WinPMem by default. Linux tries AVML first (no kernel module), falls back to LiME if kernel_lockdown blocks userland access. Virtual machines can use hypervisor snapshots.

What exists only in physical memory

Memory acquisition is a Tier 2 evidence capture — it runs after the Tier 1 volatile snapshot (processes, connections, sessions) and before the Tier 3 log and disk collection. The reason it occupies its own tier is that physical memory contains entire categories of evidence that exist nowhere else in the system.

Decrypted payloads are the most common example. A fileless attack that downloads an encrypted payload, decrypts it in memory, and executes it without writing to disk leaves no file artifact. The decrypted payload exists only in the process's virtual memory. Endpoint detection tools may record that the process executed and what command line it used, but the payload itself — the code the attacker ran — is only recoverable from a memory dump.

Credential material in memory goes beyond what disk forensics can recover. Windows LSASS (Local Security Authority Subsystem Service) holds NTLM hashes, Kerberos tickets, and cached credentials for every logged-in user. An attacker running Mimikatz or a custom credential dumper targets LSASS specifically because the credentials in memory enable lateral movement. The memory dump captures the same credential material the attacker extracted — proving what they had access to, not just that they ran a tool.

Beacon configurations from implants like Cobalt Strike, Sliver, or Brute Ratel exist in decrypted form only in the running process's memory. The beacon's configuration includes the full C2 infrastructure — server addresses, Malleable C2 profile settings, sleep intervals, jitter values, and the watermark that identifies the team server. Network traffic captures the encrypted communication but not the configuration. Disk artifacts show the DLL or shellcode loader but not the decrypted configuration it unpacks at runtime.

Memory is the only source that reveals the attacker's infrastructure in full.

Injected code in legitimate processes is invisible to standard process listing. An attacker who injects shellcode into svchost.exe or explorer.exe creates no new process — the injected code runs inside the existing process's memory space. Process monitoring shows svchost.exe with its normal command line and parent chain. Only a memory dump reveals the injected regions that contain the attacker's code.

This is why the NE WS-FIN-042 scenario uses DLL sideloading through rundll32.exe — the malicious DLL appears as a normally loaded module, but its decrypted payload in memory reveals its true function.

Network stack buffers capture recent communication that no packet capture recorded. If the security team wasn't running a full packet capture at the time of the compromise (most organisations aren't), the network stack buffers in memory may contain fragments of recent HTTP requests, DNS responses, and TLS session data.

These fragments are not complete packet captures — they're partial, fragmented, and mixed with other data — but they can reveal C2 URLs, domain names, and authentication tokens that the attacker used in the minutes before the memory dump.

Active session tokens in memory reveal what the attacker can access right now. A Kerberos ticket granting ticket (TGT) in memory means the attacker can request service tickets for any service the compromised account has access to. An OAuth refresh token in a browser process's memory means the attacker can generate new access tokens for cloud applications.

The memory dump captures these active sessions in their valid state — after containment revokes the sessions, the tokens in the dump still reveal the scope of access the attacker held at the moment of acquisition.

Windows memory acquisition: WinPMem and Magnet RAM Capture

WinPMem is the open-source standard for Windows memory acquisition. It installs a kernel driver that reads physical memory and writes it to a raw dump file. The command is straightforward:

# WinPMem acquisition — run as Administrator
.\winpmem_mini_x64.exe E:\IR\WS-FIN-042_memory.raw
# Verify output size matches installed RAM
Get-Item E:\IR\WS-FIN-042_memory.raw | Select-Object Name, @{N='SizeGB';E={[math]::Round($_.Length/1GB,2)}}
# SizeGB should be close to installed RAM (e.g., 15.9 for 16 GB)
# SHA256 immediately after acquisition
Get-FileHash E:\IR\WS-FIN-042_memory.raw -Algorithm SHA256 | Format-List

WinPMem's acquisition time scales linearly with installed RAM — approximately 2–5 minutes for 16 GB, 5–10 minutes for 32 GB, 10–20 minutes for 64 GB. The dump writes to an external USB drive or a network share. Never write the memory dump to the system's local disk — the write operation modifies disk state, potentially overwriting deleted file evidence in unallocated space, and the dump file itself consumes the system's available disk space.

The raw dump file format that WinPMem produces is compatible with Volatility, Rekall, and most commercial memory analysis tools. The file contains a byte-for-byte copy of physical memory — including the kernel, all running processes, the file system cache, and the network stack buffers. The investigation team opens this file and sees the system exactly as it existed at the moment of acquisition.

Pages that the OS had swapped to the pagefile are not included in the raw dump — if the investigation team needs pagefile content (which may contain evidence from processes that were swapped out), the pagefile itself (C:\pagefile.sys) should be collected as a separate Tier 3 artifact during the KAPE collection phase.

Magnet RAM Capture is a free alternative from Magnet Forensics. It provides a GUI and can capture to a raw, DMP, or AFF4 format. The advantage over WinPMem is a more polished interface and automatic compression options that reduce the output file size by 30–50%. The disadvantage is that it's a larger tool (~4 MB vs WinPMem's ~500 KB) and the GUI requires more user interaction — the analyst clicks through dialogs rather than running a single command.

For scripted triage where the acquisition runs as part of an automated collection pipeline, WinPMem's command-line interface is preferred. For manual acquisition by an analyst who has never run a memory dump before, Magnet RAM Capture's interface reduces the risk of operator error.

Windows Credential Guard introduces a constraint on memory acquisition. On systems with Credential Guard enabled, LSASS credentials are isolated in a Hyper-V protected virtual machine (VTL 1) that standard memory acquisition tools cannot read. The main memory dump still captures the rest of physical memory — process state, network buffers, injected code, beacon configurations — but the credential material that Mimikatz would extract is protected.

The triage responder should note Credential Guard status in the evidence manifest because it affects what the investigation team can extract from the dump.

Linux memory acquisition: AVML vs LiME

Linux memory acquisition presents a entirely different challenge than Windows because the kernel's security model treats physical memory access as a privileged operation that can be restricted at boot time.

# Check kernel lockdown status before attempting acquisition
cat /sys/kernel/security/lockdown
[none] integrity confidentiality
# "integrity" or "confidentiality" = AVML will fail
# "[none]" = AVML can proceed
# AVML acquisition (when lockdown is [none])
./avml --compress /evidence/memory.lime.snappy
# LiME acquisition (requires matching kernel module)
insmod /evidence/tools/lime-5.15.0-97-generic.ko "path=/evidence/memory.lime format=lime"
# Verify kernel version for LiME module compatibility
uname -r
5.15.0-97-generic

AVML operates entirely in userland — no kernel module required. It tries three memory sources in order: /dev/crash, /proc/kcore, and /dev/mem. Because it ships as a single static Rust binary, the analyst copies it to the target and runs it immediately. No compilation, no dependency installation, no kernel header matching. The tradeoff: on systems with kernel_lockdown set to integrity or confidentiality (which activates automatically with UEFI Secure Boot), all three memory sources are blocked. AVML fails silently or with a minimal error.

LiME operates as a loadable kernel module, giving it access to all physical memory including regions that userland tools cannot read. The tradeoff is compilation: LiME must be built against the exact kernel headers of the target system. A module compiled for 5.15.0-94-generic will not load on a system running 5.15.0-97-generic. The kernel's module version checking rejects the mismatch with insmod: ERROR: could not insert module: Invalid module format.

On a kernel_lockdown system, LiME can still load if the module is signed with a key enrolled in the system's UEFI Secure Boot database — this is the only path to memory acquisition on a locked-down system without rebooting.

The LiME output format matters for downstream analysis. LiME's native format (format=lime) is supported by Volatility 3, the primary open-source memory analysis framework. LiME can also output in padded raw format (format=padded) or a network stream (format=tcp, path=4444) that sends the dump directly to a receiving workstation. The TCP output option is valuable for servers where writing a 64 GB dump to local storage is impractical — the dump streams directly to the analyst's workstation without consuming disk space on the target system.

The NE scenario illustrates both failure modes. Priya succeeds on Windows — WinPMem loads its driver and acquires 16 GB in approximately 4 minutes. Tom fails on Linux — AVML is blocked by kernel_lockdown (Secure Boot enabled), and the pre-compiled LiME module was built against the wrong kernel version. Tom documents both failures in the evidence manifest and proceeds with /proc state capture and container evidence collection.

The memory gap is real: any in-memory-only evidence on web-prod-01 (decrypted payloads, credential cache, injected code) is now unrecoverable unless the investigation team can provide a correctly compiled and signed LiME module before the system is rebooted or contained.

Incident readiness: preventing acquisition failures

Memory acquisition failures during live incidents are almost always preventable with preparation. The readiness checklist has four items.

First, test every acquisition tool against the exact configuration of every production system type. Not a lab VM — the production configuration, including Secure Boot status, Credential Guard, and kernel version. A tool that works in the lab and fails in production is worse than no tool at all, because the analyst spends triage time troubleshooting instead of collecting evidence.

Second, for Linux environments, pre-compile LiME modules for every kernel version running in production. When the kernel updates, compile a new LiME module for the new version and retain the old one. Store the compiled modules on the IR USB alongside AVML — try AVML first (faster, no kernel matching), fall back to LiME if AVML is blocked.

Third, for kernel_lockdown environments, sign the LiME module with a key enrolled in the system's Secure Boot database. This requires coordination with the platform team — the signing key must be enrolled before the incident, not during it.

Fourth, validate that the output device (USB drive, network share) has enough free space for the dump before starting acquisition. A 64 GB server produces a 64 GB dump file. A 32 GB USB drive will fail mid-acquisition — after partial writes have consumed triage time and modified the USB's filesystem state.

For virtual machines running on Hyper-V, VMware, or KVM, an alternative acquisition path exists that bypasses the guest OS entirely. A hypervisor-level snapshot captures the VM's memory state from outside the guest — no driver installation, no kernel module, no kernel_lockdown constraint. On Hyper-V, Checkpoint-VM creates a snapshot that includes the VM's memory state in the .VMRS file. On VMware, a snapshot creates a .vmem file containing physical memory.

The analyst copies the snapshot file to the evidence store and converts it for analysis with Volatility. This approach has zero impact on the running VM — no tool is loaded, no driver is installed, no process is started inside the guest. The limitation is access: the analyst needs hypervisor-level permissions, which are typically held by the infrastructure team, not the SOC.

Pre-arranging this access during incident readiness planning ensures the SOC can request a VM snapshot during a live incident without waiting for permission escalation.

This decision block goes into the evidence manifest and the triage report. The investigation team reads it and immediately knows: (1) memory was not acquired, (2) the specific reason, (3) what evidence categories are missing, and (4) what post-incident action prevents the same failure next time. Omitting this documentation creates a false impression that memory was either acquired or not needed.