Chapter 2

Evidence Preservation

How to acquire RAM, disk images, and live artifacts correctly — hash verification, write-blockers, acquisition tools, chain of custody documentation, and what to do when you can't take a full image.

Scenario

A finance server is confirmed compromised. You have a 90-minute window before the business demands it be returned to service. In that time you need to preserve everything necessary to answer the question: "What did the attacker do on this server and did they move anywhere else?" You can't image a 2 TB RAID array in 90 minutes. You need to know which evidence to prioritize, in what order, using what tools, and how to document the acquisition so the evidence is usable in a legal proceeding if the investigation escalates. This chapter is the operational guide for that scenario.

Acquisition Priority Under Time Pressure

When you can't preserve everything, preserve the highest-value evidence first in order of volatility:

  Evidence Acquisition Priority (time-constrained)
  ═══════════════════════════════════════════════════════════════════

  PHASE 1 — Live capture (before any shutdown):
    □ Capture running processes (tasklist /v, Get-Process)
    □ Capture network connections (netstat -anob)
    □ Capture logged-on users (query user, Get-LoggedOnUser)
    □ Capture ARP cache (arp -a)
    □ Acquire RAM image (WinPmem, Magnet RAM Capture)
      → On a 16 GB system: ~5-10 minutes acquisition time

  PHASE 2 — Targeted disk collection (before full image):
    □ Windows Event Logs      → C:\Windows\System32\winevt\Logs\*
    □ Prefetch files          → C:\Windows\Prefetch\*
    □ Registry hives          → SYSTEM, SOFTWARE, SAM, SECURITY, NTUSER.DAT
    □ MFT ($MFT)              → Requires raw disk access (RawCopy or KAPE)
    □ Scheduled tasks         → C:\Windows\System32\Tasks\*
    □ PowerShell history      → %APPDATA%\Microsoft\Windows\PowerShell\...
    → KAPE triage: ~10-30 minutes for key artifacts from a live system

  PHASE 3 — Full disk image (if time allows):
    □ FTK Imager or dd of the OS drive
    □ E01 format with SHA-256 hash verification
    → 500 GB SSD @ USB 3.0: ~60-90 minutes

  PHASE 4 — SIEM/EDR (always available regardless of disk access):
    □ Pull all events for the host from SIEM for the investigation window
    □ Pull EDR process telemetry for the same window
    □ These are independent of physical access — do in parallel

Memory Acquisition

RAM capture must happen before any reboot. Tools for Windows memory acquisition:

ToolLicenseNotes
WinPmemFree, open sourcePart of the Velociraptor/DFIR toolset. Standalone executable. Outputs raw or AFF4 format. Most commonly used in professional DFIR.
Magnet RAM CaptureFree (Magnet Forensics)GUI-based. Outputs raw .mem file. Good for rapid on-site acquisition with non-technical first responders.
DumpItFree (Comae)Simple double-click acquisition. Outputs raw .bin. No installation needed — runs from USB drive.
Volatility's winpmemFree, open sourceIntegrated into Volatility 3 workflows for direct analysis without separate acquisition steps.
F-ResponseCommercialRemote memory acquisition over network without pre-installed agent. Useful when you can't physically or RDP-access the host.
PowerShellacquire-memory.ps1
# Memory acquisition with WinPmem
# Run from a USB drive or network share to avoid writing to the target system

# WinPmem acquisition — outputs to specified destination
$destination = "D:\evidence\HOSTNAME-2026-09-20\memory.raw"
$winpmem = "D:\tools\winpmem_mini_x64_rc2.exe"

# Start acquisition — this takes 5-15 minutes depending on RAM size
& $winpmem $destination

# Verify acquisition completed and hash the output
$hash = Get-FileHash -Path $destination -Algorithm SHA256
Write-Host "Memory image: $destination"
Write-Host "SHA-256: $($hash.Hash)"
Write-Host "Size: $((Get-Item $destination).Length / 1GB) GB"

# Document in chain of custody log
$logEntry = [PSCustomObject]@{
    Timestamp     = (Get-Date -Format "yyyy-MM-dd HH:mm:ss UTC")
    Investigator  = $env:USERNAME
    Host          = $env:COMPUTERNAME  # Host you're acquiring FROM
    Action        = "Memory acquisition"
    OutputFile    = $destination
    SHA256        = $hash.Hash
    ToolUsed      = "WinPmem mini x64 rc2"
}
$logEntry | Export-Csv -Path "D:\evidence\chain-of-custody.csv" -Append -NoTypeInformation

Disk Acquisition

For full disk images, FTK Imager (free) is the industry standard for Windows forensics. It produces E01 (Expert Witness Format) images with built-in hash verification and compression.

Bashdisk-image-linux.sh
# Full disk acquisition on Linux using dc3dd (forensic dd)
# dc3dd adds hashing, progress reporting, and output splitting

# Identify the target drive
lsblk
# → sda: 500G — OS drive (target)
# → sdb: 2T  — evidence drive (destination)

# Mount evidence drive
mount /dev/sdb1 /mnt/evidence

# Acquire with dc3dd — hashes while imaging, splits at 4GB for FAT32 compat
dc3dd \
  if=/dev/sda \
  of=/mnt/evidence/HOST-server01-2026-09-20.dd \
  ofsz=4G \                # split into 4 GB chunks
  hash=sha256 \            # hash while imaging
  log=/mnt/evidence/HOST-server01-acquisition.log \
  verb=on                  # progress output

# dc3dd automatically appends hash to the log file
# Verify: dc3dd if=/mnt/evidence/HOST-server01-2026-09-20.001 hash=sha256

# For E01 format on Linux: use ewfacquire (libewf-tools)
ewfacquire \
  -t /mnt/evidence/HOST-server01-2026-09-20 \
  -f encase6 \
  -C "server01.corp.local" \
  -D "Finance server — confirmed compromise 2026-09-20" \
  -e "analyst@corp.local" \
  /dev/sda

KAPE Triage Collection

KAPE (Kroll Artifact Parser and Extractor) collects targeted forensic artifacts without a full disk image. For time-constrained acquisitions, KAPE triage is often the right call.

Batchkape-triage.bat
:: KAPE triage collection — key forensic artifacts from live system
:: Run from USB drive; writes to separate evidence drive

:: Variables
set KAPE=D:\tools\kape\kape.exe
set TSOURCE=C:
set TDEST=E:\evidence\HOST-%COMPUTERNAME%-%DATE%\triage
set MDEST=E:\evidence\HOST-%COMPUTERNAME%-%DATE%\modules

:: Collect target artifacts (filesystem collection)
%KAPE% --tsource %TSOURCE% --tdest %TDEST% ^
  --target !SANS_Triage ^
  --tflush

:: Module processing (runs EZTools parsing on collected artifacts)
:: This parses MFT, registry hives, event logs into readable CSV
%KAPE% --msource %TDEST% --mdest %MDEST% ^
  --module !EZParser ^
  --mflush

:: !SANS_Triage includes:
::   - MFT ($MFT)
::   - Windows Event Logs
::   - Registry hives (SYSTEM, SOFTWARE, SAM, SECURITY)
::   - NTUSER.DAT per user
::   - Prefetch
::   - LNK files and Jump Lists
::   - Shellbags
::   - Scheduled Tasks
::   - PowerShell history
::   - Browser artifacts (Chrome, Edge, Firefox)
::   - SRUM database
::   - Amcache.hve / Shimcache

echo Collection complete. Artifacts in %TDEST%
echo Parsed output in %MDEST%

Live Response — Capturing Volatile State

Before acquisition, capture the volatile live-system state. This takes under 5 minutes and preserves evidence that disappears on shutdown.

PowerShelllive-response.ps1
# Live response collection — run BEFORE memory acquisition, BEFORE any shutdown
# Output to evidence drive, not local disk

param([string]$OutputDir = "D:\evidence\live-response")
New-Item -ItemType Directory -Path $OutputDir -Force | Out-Null

$ts = Get-Date -Format "yyyyMMdd-HHmmss"

# Running processes (full detail)
Get-Process | Select-Object Id,Name,Path,CPU,WorkingSet,StartTime |
  Export-Csv "$OutputDir\processes-$ts.csv" -NoTypeInformation

# Process with command line (requires WMI)
Get-WmiObject Win32_Process |
  Select-Object ProcessId,Name,CommandLine,ParentProcessId |
  Export-Csv "$OutputDir\process-cmdlines-$ts.csv" -NoTypeInformation

# Network connections
netstat -anob 2>&1 | Out-File "$OutputDir\netstat-$ts.txt"

# Logged-on users
query user 2>&1 | Out-File "$OutputDir\loggedon-$ts.txt"

# ARP cache
arp -a 2>&1 | Out-File "$OutputDir\arp-$ts.txt"

# DNS cache
ipconfig /displaydns 2>&1 | Out-File "$OutputDir\dnscache-$ts.txt"

# Running services
Get-Service | Where-Object Status -eq Running |
  Export-Csv "$OutputDir\services-$ts.csv" -NoTypeInformation

# Scheduled tasks
Get-ScheduledTask | Where-Object State -ne Disabled |
  Select-Object TaskName,TaskPath,State,@{n="Actions";e={($_.Actions | Out-String).Trim()}} |
  Export-Csv "$OutputDir\tasks-$ts.csv" -NoTypeInformation

# Autorun locations (common persistence points)
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" 2>$null |
  Out-File "$OutputDir\autoruns-hklm-run-$ts.txt"
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" 2>$null |
  Out-File "$OutputDir\autoruns-hkcu-run-$ts.txt"

Write-Host "Live response collection complete: $OutputDir"

Chain of Custody Documentation

Every piece of evidence must be tracked from acquisition to presentation. A chain-of-custody record documents who had the evidence, when, and what they did with it.

FieldExampleWhy it matters
Evidence item description"RAM image of FINANCE-SRV01, 32 GB, acquired 2026-09-20 14:33 UTC"Identifies exactly what was captured
Hash at acquisitionSHA-256: a3f9c2e1...Proves the evidence hasn't been modified since capture
Acquisition investigatorJ. Smith, Corporate IR TeamWho is responsible for the acquisition
Storage locationEncrypted evidence vault, shelf 3, evidence bag #0047Physical security of evidence media
Transfer log2026-09-21 09:00 — transferred to external forensic firm (signed receipt #12)Every transfer requires documentation and signature
Hash at analysis startSHA-256: a3f9c2e1... (matches — integrity confirmed)Proves nothing changed in transit
Common mistake: acquiring to local disk

Writing a disk image or KAPE output to the same drive you're imaging will overwrite forensic evidence. The target system's disk is evidence — treat it as read-only and write all acquired data to an external drive you brought to the scene. Even live response script output should go to an external drive. This isn't just best practice — it's the difference between evidence that holds up and evidence that doesn't.

Q & A

Q: You don't have a write-blocker on site. Can you still image the drive?

You can, but you must document the absence of a write-blocker and take steps to minimize writes. On Linux, mount the source drive read-only: mount -o ro /dev/sda1 /mnt/source. On Windows, use the registry to enable software write-blocking before connecting the drive: HKLM\SYSTEM\CurrentControlSet\Control\StorageDevicePolicies → WriteProtect = 1. Document in your case notes: "Hardware write-blocker not available at time of acquisition. Source drive mounted read-only via [method]. Hash verified at acquisition and analysis start — hashes match, confirming no writes occurred." In a legal context, opposing counsel may challenge this — but a documented, hash-verified acquisition with software write protection is far stronger than no acquisition at all.

Q: The host is a cloud VM. How do you acquire it forensically?

Cloud VMs require cloud-native acquisition methods. For AWS: take an EBS snapshot of the root volume (this is a block-level copy, consistent and hash-verifiable). For Azure: create a managed disk snapshot or use Azure's disk export feature. For both: the snapshot is a point-in-time copy that can be attached to a forensic workstation instance for analysis with Autopsy, TSK, or Sleuth Kit. Memory acquisition in cloud VMs is harder — you can't attach a physical RAM capture tool. Options: (1) use the hypervisor snapshot feature if available (pauses the VM and captures a consistent disk+memory state); (2) use Volatility's cloud memory acquisition plugins for AWS/Azure; (3) accept that memory may not be available and focus on disk artifacts and CloudTrail/Activity Logs, which are preserved independently. Chapter 49 covers cloud forensics in depth.