Order of Volatility — What to Collect First and Why

Forensic acquisition is not about collecting everything — it’s about collecting the right things in the right order before they disappear. Every minute spent debating collection order is a minute of volatile evidence decaying.

The Volatility Ladder

MOST VOLATILE (collect first)
┌─────────────────────────────────────────────────────┐
│ 1. CPU registers, CPU cache              (seconds)  │
│    → Not typically collectable during IR            │
├─────────────────────────────────────────────────────┤
│ 2. RAM — running processes, injected code           │
│    → Lost on shutdown or reboot         (minutes)   │
├─────────────────────────────────────────────────────┤
│ 3. Network state — connections, ARP, routing        │
│    → Lost on reboot, may change in minutes          │
├─────────────────────────────────────────────────────┤
│ 4. Running processes with open handles              │
│    → Lost when process terminates                   │
├─────────────────────────────────────────────────────┤
│ 5. Disk — MFT, registry hives, event logs           │
│    → Survives reboot; some artifacts decay          │
├─────────────────────────────────────────────────────┤
│ 6. Remote logs — SIEM, Zeek, firewall               │
│    → Survives local incident; retention-limited     │
└─────────────────────────────────────────────────────┘
LEAST VOLATILE (can collect later)

Live Acquisition Sequence — The First 30 Minutes

Step 1: Network State (2 minutes)

Before any acquisition tool runs, capture current network connections:

:: Run from an admin cmd prompt on the suspect system
:: Save to removable media, NOT local disk

netstat -anob > \\forensic-server\case\hostname_netstat.txt
arp -a >> \\forensic-server\case\hostname_netstat.txt
ipconfig /all >> \\forensic-server\case\hostname_netstat.txt
route print >> \\forensic-server\case\hostname_netstat.txt

Why first: Active C2 connections appear here. The ESTABLISHED state plus the PID owning the connection is your fastest pivot to the malicious process. This data degrades if the attacker’s beacon loses connectivity or a process terminates.

Step 2: Running Processes (2 minutes)

:: Process list with full paths and parent relationships
tasklist /v /fo csv > \\forensic-server\case\hostname_processes.csv

:: Processes with network connections (correlates PID to connection)
tasklist /m > \\forensic-server\case\hostname_modules.txt

Step 3: Memory Acquisition (20+ minutes)

Memory is the most valuable and most time-consuming live acquisition. Use dedicated memory acquisition tools — not procdump on all processes (too slow, incomplete).

Tools by reliability:
  WinPmem (open source, kernel driver)
  Magnet RAM Capture (free, GUI)
  Velociraptor Windows.Memory.Acquisition artifact (fleet-scale)
  
Output: raw memory image (hostname_memory.raw)
Hash immediately after acquisition.

Target: Full physical memory image, not a virtual memory dump. Physical memory contains kernel structures, driver code, and cross-process artifacts that virtual dumps miss.

Step 4: Registry Hive Export (5 minutes)

Live registry hives contain current state including volatile keys that don’t exist on disk:

:: Export live hives using reg.exe (or KAPE/Velociraptor)
reg save HKLM\SYSTEM \\forensic-server\case\SYSTEM.hiv
reg save HKLM\SAM \\forensic-server\case\SAM.hiv
reg save HKLM\SOFTWARE \\forensic-server\case\SOFTWARE.hiv
reg save HKCU \\forensic-server\case\NTUSER.hiv

Step 5: Event Logs (5 minutes)

:: Copy event logs before attacker cleanup script runs
for %f in (C:\Windows\System32\winevt\Logs\*.evtx) do ^
  copy "%f" \\forensic-server\case\evtx\

Step 6: Prefetch, MFT, and Disk Triage (KAPE — 15 minutes)

Use KAPE (Kroll Artifact Parser and Extractor) with --target !ALL
to collect: Prefetch, MFT ($MFT), browser history, LNK files,
            shellbags, SRUM, scheduled tasks, startup items

Output: triage package ready for Plaso ingestion

Forensic Footprint — What Your Tools Write

Every acquisition tool writes to the system in some way. Document the footprint:

Tool                        | Writes to disk?           | Impact
───────────────────────────────────────────────────────────────
netstat (built-in)          | No — read-only            | Minimal
WinPmem (memory)            | Kernel driver loaded      | Minor registry entries
KAPE (triage collector)     | Source=same disk: YES     | Timestamp updates on accessed files
KAPE (output to network)    | Source=network share: NO  | Minimal
reg save                    | Writes .hiv to disk       | Timestamp change on HIVE file

Best practice: Run acquisition tools from removable media (USB, mapped network share) and output to network share — keeps the forensic footprint off the suspect disk.

Retrieval Practice

An incident responder is called to a compromised workstation. The user says 'I already ran a full antivirus scan and it found nothing.' What forensic concern does this raise and what evidence may have been affected?

Reveal answer

The AV scan modified the system before forensic acquisition. Concerns: (1) Access time changes — AV read every file, updating the 'last accessed' timestamp ($STANDARD_INFORMATION Access time in MFT) for potentially millions of files, making file access timeline analysis unreliable. (2) File system writes — AV quarantine operations may have moved or modified suspicious files, altering the MFT record. (3) Memory artifact modification — some AV products perform memory scanning that affects process state or kills processes. (4) Potential evidence destruction — if AV deleted or quarantined the malware binary, the binary is gone from its original path (may be recoverable from quarantine folder). Document the AV scan as a 'first responder action that modified the system' in the acquisition notes — this is required for chain of custody. It doesn't invalidate the investigation, but it must be disclosed.

Retrieval Practice

Why is MD5 alone insufficient for forensic integrity verification, and what hash combination should be used?

Reveal answer

MD5 alone is insufficient because MD5 has known collision vulnerabilities — two different files can produce the same MD5 hash (demonstrated in 2004, practical attacks demonstrated by 2008). An adversary or defense attorney could theoretically argue that the evidence was modified and the MD5 hash was engineered to match. Standard forensic practice: compute BOTH MD5 and SHA256 for every acquired artifact. MD5 provides backward compatibility with legacy tools and fast computation; SHA256 provides collision resistance (no known practical collision attacks). If both hashes match the original computation, the probability of undetected modification is negligible. Some organizations add SHA1 for a third verification point. Document all hash values in the chain of custody form at the time of acquisition — not retrospectively.