Memory Acquisition — Tools, Techniques, and Triage Artifacts

Memory acquisition is the single highest-value action in the first 30 minutes of a Windows IR. Everything that happens after the system reboots — the disk imaging, the log analysis, the timeline reconstruction — is working with incomplete information without the memory image.

Memory Acquisition Tools Comparison

Tool	Method	Fleet Support	Output Format	Best For
WinPmem	Kernel driver	Manual	Raw .raw	Single system, open source
Magnet RAM Capture	Kernel driver	Manual	Raw .mem	Single system, GUI
Velociraptor	VQL artifact	Yes (fleet)	Raw or compressed	Enterprise IR
DumpIt	Kernel driver	Manual	Raw .dmp	Quick single-host
FTK Imager	Kernel driver	Manual	.mem / .ad1	When already using FTK

Fleet acquisition via Velociraptor:

# Velociraptor artifact for fleet memory acquisition
name: Windows.Memory.Acquisition
sources:
  - query: |
      SELECT upload(
        file=pathspec(
          DelegatePath=winpmem(),
          Path="/"),
        name=format(format="memory_%s.raw", 
                   args=[hostname()])
      ) AS Upload
      FROM scope()

Step-by-Step Memory Acquisition

Option A: WinPmem (CLI)

# Run from USB/network share, output to network share
# Requires admin privileges

# Acquire to network share
.\winpmem_mini_x64_rc2.exe \\forensic-server\case\$(hostname)_memory.raw

# Verify hash immediately after acquisition
Get-FileHash \\forensic-server\case\$(hostname)_memory.raw -Algorithm SHA256
Get-FileHash \\forensic-server\case\$(hostname)_memory.raw -Algorithm MD5

# Document:
# - Acquisition start time
# - Acquisition end time
# - System uptime at acquisition (systeminfo | findstr "System Boot")
# - Tool version
# - Both hash values

Option B: Magnet RAM Capture (GUI)

1. Run as Administrator from USB media
2. Set destination to \\forensic-server\case\ (network share)
3. Click "Capture Memory"
4. After completion: SHA256 and MD5 hashes displayed in output log
5. Copy hash values to chain of custody form

Option C: Velociraptor Live Response (Remote)

# From Velociraptor server — collect memory from suspect host without
# physically touching the system

velociraptor query \
  'SELECT * FROM Artifact.Windows.Memory.Acquisition()' \
  --org default \
  --client [CLIENT_ID]

# Memory image collected and stored in Velociraptor server's file store
# Accessible via web interface for download and analysis

Documenting the Acquisition

Chain of custody starts at acquisition. Every acquisition must be documented:

FORENSIC ACQUISITION RECORD

Case number:        IR-2024-089
Date/time (UTC):    2024-09-02T18:30:00Z
Analyst:            M. Torres
System hostname:    WS-JSMITH-01
System IP:          10.1.2.33
System uptime:      4 days 7 hours (system boot: 2024-08-29T11:15:00Z)
Acquisition tool:   WinPmem v4.0.rc1
Tool hash (SHA256): [tool binary hash — proves tool integrity]
Tool run from:      USB media (E:\)
Output location:    \\forensic-server\case\IR-2024-089\

Artifacts collected:
  1. Physical memory image
     File: WS-JSMITH-01_memory_20240902T1830.raw
     Size: 16,384 MB (16 GB RAM)
     Acquisition duration: 00:18:42
     MD5:    9b4c2f1d3e8a7b6c5d4e3f2a1b0c9d8e
     SHA256: 4a3f7e2c8b1d5e9f3c7a2e6b4d8f1a5c...

  2. Network state (netstat)
     File: WS-JSMITH-01_netstat_20240902T1825.txt
     Captured before memory acquisition
     MD5:    2d7f3a1c...

  3. Process list
     File: WS-JSMITH-01_processes_20240902T1826.csv
     MD5:    5e9c4b2a...

Analyst signature: [digital or physical signature]
Witness (if applicable): [name]

Key Memory Artifacts for IR

After acquisition, initial triage with Volatility or MemProcFS targets:

# 1. Process list comparison (detect DKOM rootkits)
vol.py -f memory.raw windows.pslist
vol.py -f memory.raw windows.psscan
# Compare: processes in psscan not in pslist = DKOM-hidden

# 2. Active network connections
vol.py -f memory.raw windows.netscan
# Look for: ESTABLISHED connections to external IPs from unusual processes

# 3. Injection detection
vol.py -f memory.raw windows.malfind
# Look for: MZ header in private executable memory regions

# 4. Command line history
vol.py -f memory.raw windows.cmdline
# Look for: encoded PowerShell, LOLBin arguments, lateral movement commands

# 5. Credential extraction (high sensitivity)
vol.py -f memory.raw windows.hashdump
# Output: NTLM hashes — treat as live credentials

Worked Example

Memory acquisition under time pressure: production server with active C2

Situation: Production web server (WS-WEB-01) identified as beaconing to 185.220.101.9:443. Server cannot be powered off — it serves 50,000 users. On-call engineer needs it back in 30 minutes.

Priority decision:

Time available: 30 minutes
Memory size: 32 GB RAM

Memory acquisition time estimate: ~35 minutes (WinPmem on 32 GB ≈ 1 GB/min)
→ Cannot do full memory acquisition in time

Triage approach:
  1. Network state + process list (5 min) — most time-critical
  2. Registry + event logs via KAPE (15 min) — high value, fast
  3. Partial memory: target specific processes only (10 min)
     → procdump on the suspicious PID identified in netstat

Execution:

# Step 1: Network state (2 min)
netstat -anob > \\forensic-server\case\WEB01_netstat.txt

# From netstat: svchost.exe PID 8844 → ESTABLISHED 185.220.101.9:443

# Step 2: Process dump of suspicious PID (5 min)
# Using procdump from Sysinternals
.\procdump.exe -ma 8844 \\forensic-server\case\svchost_8844.dmp

# Step 3: KAPE triage (15 min)
.\kape.exe --tsource C: ^
           --tdest \\forensic-server\case\WEB01_kape ^
           --target !BasicCollection ^
           --vss

# Step 4: Full process list + module list (3 min)
tasklist /v /fo csv > \\forensic-server\case\WEB01_processes.csv
wmic process list full > \\forensic-server\case\WEB01_wmic.txt

# Step 5: Hash everything collected
Get-ChildItem \\forensic-server\case\ -Recurse | ForEach-Object {
  Get-FileHash $_.FullName -Algorithm SHA256
} | Export-Csv \\forensic-server\case\IR-2024-089_hashes.csv

Documentation note: “Full memory acquisition not feasible (32 GB, 35 min estimated, 30 min window). Process dump of PID 8844 (suspected C2 process) collected as partial substitute. Full memory acquisition scheduled for maintenance window 2024-09-03T02:00Z.”

Result: Process dump analysis with Volatility confirms process hollowing in svchost.exe PID 8844. Containment proceeds without requiring full memory acquisition.

Retrieval Practice

An analyst acquires memory from a compromised system using WinPmem. The resulting file is 15.9 GB for a system with 16 GB RAM. Is this normal, and does the size difference indicate data loss?

Reveal answer

Yes, this is normal and expected. The size difference (15.9 GB vs 16 GB) reflects two legitimate phenomena: (1) Memory reserved by hardware and firmware — some physical memory addresses are mapped to hardware devices (MMIO — memory-mapped I/O) and are not readable by WinPmem or any software tool. These regions are skipped during acquisition, resulting in a file slightly smaller than the advertised RAM capacity. (2) Memory in use by the acquisition tool itself — WinPmem's kernel driver uses a small amount of physical memory. The acquired image does not represent 'lost' forensic data; these skipped regions contain hardware state, not process memory or kernel structures of forensic interest. Normal variation: 1–5% smaller than advertised RAM capacity is expected and acceptable.

Retrieval Practice

What is the forensic risk of running memory acquisition tools directly from the suspect system's local hard drive (C:\\tools\\winpmem.exe) rather than from removable media?

Reveal answer

Running from local disk modifies the source evidence in two ways: (1) File system metadata changes — when Windows loads winpmem.exe from local disk, it updates the $STANDARD_INFORMATION Last Access time for the tool binary and potentially the directory (depending on OS settings). This timestamp change is recorded in the MFT and could confuse the file system timeline. (2) Disk write pressure — running a tool from local disk causes Windows to load the binary into the page cache, potentially causing other pages to be written to pagefile.sys (paged out). This can overwrite slack space or previously-deleted content that the investigation needed. Additionally: the tool binary itself on local disk is itself a forensic artifact — its presence, hash, and timestamps tell the story of the response. Best practice: run all acquisition tools from read-only USB or network share; document any exception and the forensic impact.