Live Incident Response: Volatile Memory Acquisition and Triage

Volatile memory can contain process state, loaded code, network details, and other data that may disappear when a host is shut down. A memory capture is a point-in-time acquisition: it changes the live system, can miss inaccessible pages, and may be affected by the acquisition tool and operating system.

Use your incident plan to decide what to collect and in what order. RFC 3227 recommends collecting evidence from more volatile to less volatile and gives a typical example; it does not replace incident-specific safety, containment, or evidence-handling decisions.

Memory acquisition workflow: capture to a writable case destination, calculate a hash after the capture, record it with the case notes, then protect the evidence copy.

---

Live acquisition changes the host

Loading a driver or running a capture utility changes system state and may trigger endpoint protection. Use a tool and version approved for the host, record the operator, time, tool version, command, errors, and destination, and follow your response lead’s direction. Do not disable security controls just to make an acquisition tool load.

---

Step 1: Record the Host and Prepare a Writable Destination

01

Document the System and Check Case Storage

Preparation

Use trusted, pre-positioned acquisition tools where possible. Keep the tool media separate from the evidence destination. The destination must be writable during capture and have enough free space for the memory image, notes, and hash manifest. After acquisition and verification, protect the evidence copy according to your process.

Windows (PowerShell)

$CaseDir = 'E:\DFIR_Case_001'
New-Item -ItemType Directory -Path $CaseDir -Force | Out-Null

$os = Get-CimInstance Win32_OperatingSystem
[pscustomobject]@{
    CapturedUTC = [DateTime]::UtcNow.ToString('o')
    Hostname    = $env:COMPUTERNAME
    OS          = $os.Caption
    Architecture = $os.OSArchitecture
    RAM_GiB     = [math]::Round($os.TotalVisibleMemorySize / 1MB, 2)
}

Get-Volume -DriveLetter E |
    Select-Object DriveLetter, SizeRemaining, FileSystemType

Linux (Bash)

CASE_DIR=/mnt/forensics/DFIR_Case_001
mkdir -p "$CASE_DIR"
chmod 0700 "$CASE_DIR"

date -u '+Captured UTC: %Y-%m-%dT%H:%M:%SZ'
hostnamectl --static
uname -a
free -h
df -hT "$CASE_DIR"

❯ View Expected Console Output

Confirm before continuing:
- Host name, OS, architecture, and UTC collection time recorded
- Case destination is writable and has sufficient free space
- Case ID and evidence handling owner are documented

---

Step 2: Acquire Memory with an Approved Tool

02

Capture the Live Memory Image

Acquisition

Run only the command for the tool version you have validated. The Windows example uses the WinPmem mini executable’s documented positional output path. Linux examples use Microsoft’s AVML or a LiME kernel module prepared for the running kernel. Prepare LiME on a trusted matching build system before an incident; do not install compilers or build the module on the suspected host.

Windows (WinPmem)

# Run from an elevated PowerShell session with the approved tool available.
$Tool = 'E:\IR-Tools\winpmem_mini_x64.exe'
$Image = 'E:\DFIR_Case_001\WORKSTATION-04-memory.raw'

& $Tool $Image

# Confirm that a non-empty output file was created.
Get-Item -LiteralPath $Image |
    Select-Object Name, Length, LastWriteTimeUtc

Linux (AVML)

# Use a trusted, pre-positioned AVML binary and a writable case destination.
sudo /mnt/ir-tools/avml acquire /mnt/forensics/DFIR_Case_001/host-memory.lime

# Confirm the output exists and is non-empty.
sudo test -s /mnt/forensics/DFIR_Case_001/host-memory.lime \
  && sudo stat -c 'Image: %n | Bytes: %s' \
     /mnt/forensics/DFIR_Case_001/host-memory.lime

Linux (LiME)

# The module must be built and validated for this exact running kernel in advance.
CASE_DIR=/mnt/forensics/DFIR_Case_001
MODULE="/mnt/ir-tools/lime-$(uname -r).ko"

sudo insmod "$MODULE" "path=$CASE_DIR/host-memory.lime format=lime"
sudo test -s "$CASE_DIR/host-memory.lime" \
  && sudo stat -c 'Image: %n | Bytes: %s' "$CASE_DIR/host-memory.lime"
sudo rmmod lime

❯ View Expected Console Output

Verify the tool reports completion, the destination file exists, and its size is plausible for the host.
Record the exact tool version, command, start/end times, errors, and output path.

Check Windows driver policy

WinPmem versions use a kernel driver, and Windows security policy may block a driver even when the executable runs. Confirm compatibility and signing for the exact release and host configuration before an incident. If it is blocked, stop and use an approved alternative or escalate; do not disable Secure Boot, Memory Integrity, or driver enforcement to force a capture.

---

Step 3: Hash the Completed Image and Record Custody

03

Calculate SHA-256 After the Capture Completes

Integrity

Hash the completed image and store the hash in the case record. A SHA-256 hash helps detect later changes; it is not a digital signature and does not by itself prove who collected the file or that the acquisition was complete. Keep the notes and manifest with the case, and restrict write access to the evidence copy after verification.

Windows (PowerShell)

$Image = 'E:\DFIR_Case_001\WORKSTATION-04-memory.raw'
$Hash = Get-FileHash -LiteralPath $Image -Algorithm SHA256

$Manifest = [pscustomobject]@{
    CaseID       = 'INC-2026-1005'
    SourceHost   = $env:COMPUTERNAME
    CapturedFile = (Get-Item -LiteralPath $Image).Name
    FileSizeBytes = (Get-Item -LiteralPath $Image).Length
    Algorithm    = 'SHA256'
    Hash         = $Hash.Hash
    HashedUTC    = [DateTime]::UtcNow.ToString('o')
}

$Manifest | Format-List |
    Out-File -LiteralPath 'E:\DFIR_Case_001\manifest.txt' -Encoding utf8
$Manifest

Linux (Bash)

CASE_DIR=/mnt/forensics/DFIR_Case_001
IMAGE="$CASE_DIR/host-memory.lime"

sha256sum -- "$IMAGE" | tee "$CASE_DIR/host-memory.lime.sha256"
stat -c 'Image bytes: %s' "$IMAGE"
date -u '+Hashed UTC: %Y-%m-%dT%H:%M:%SZ' \
  | tee -a "$CASE_DIR/acquisition-notes.txt"

❯ View Expected Console Output

Record the actual 64-character SHA-256 value printed for this image.
Compare the file size and hash with the case manifest before moving or analyzing it.

---

Step 4: Triage the Image on an Analysis Workstation

04

Start Offline Analysis with Volatility 3

Triage

Analyze a verified working copy on a separate, trusted workstation. Do not run string searches or memory-analysis tools on the suspected endpoint as part of this step. Start with system and process context, then investigate network artifacts and suspicious processes. Plugin availability and symbol requirements vary by operating system and image format.

Windows image

# Run these commands on the analysis workstation with Volatility 3 installed.
vol -f 'D:\Cases\INC-2026-1005\WORKSTATION-04-memory.raw' windows.info
vol -f 'D:\Cases\INC-2026-1005\WORKSTATION-04-memory.raw' windows.pslist
vol -f 'D:\Cases\INC-2026-1005\WORKSTATION-04-memory.raw' windows.netscan

Linux image

# Run these commands on the analysis workstation with Volatility 3 installed.
vol -f ./host-memory.lime banners
vol -f ./host-memory.lime linux.pslist
vol -f ./host-memory.lime linux.sockstat

❯ View Expected Console Output

Save the tool version, command lines, plugin output, and any symbol or parsing errors in the case notes.
Treat extracted strings, addresses, and process names as leads to validate, not confirmed indicators by themselves.

Limits of a memory capture

A live image is not a perfect, atomic copy of every byte of physical or virtual memory. Acquisition tools, driver compatibility, operating-system protections, inaccessible pages, and concurrent activity affect what is captured. Page files and swap are separate evidence sources; collect them under your response plan using a tool that explicitly supports them, and document how they were acquired.

Tool references

• WinPmem project and usage
• Microsoft AVML project and usage
• LiME project
• Volatility 3 documentation
• RFC 3227: Guidelines for Evidence Collection and Archiving