Playbooks
T1562.001Digital Forensics & Live Response
A SOC playbook for digital forensics and live response — memory capture best practices, disk imaging, triage collection, chain of custody procedures, and evidence preservation for incident investigations.
View on Graph
What Digital Forensics and Live Response Covers
Digital forensics is a crucial phase of any incident response investigation — the systematic preservation, collection, analysis, and reporting of digital evidence from computer systems involved in a security incident.
- MITRE ATT&CK maps defense evasion against forensic tools to
T1562.001(Impair Defenses: Disable or Modify Tools) — sophisticated attackers actively target forensic processes, making live response a race against time. - Live response collects volatile data from a running system — data that would be lost when the system is powered off. Dead forensics analyzes non-volatile data from disk images. Both are essential phases of a forensic investigation.
- The core tension: pulling the plug (powering off a system) preserves disk state but destroys memory, running processes, and network connections. Live response preserves volatile data but leaves the system running (risk of attacker cleanup or destruction).
Step 1: Triage — Pull the Plug or Live Acquire?
Decision Matrix
| Scenario | Action | Rationale |
|---|---|---|
| Ransomware encrypting files | Pull the plug immediately | Stop the encryption — disk forensics sufficient |
| Active C2 beacon observed | Live acquire | Memory contains the implant, network connections, and decrypted C2 communication |
| Insider data exfiltration | Live acquire | Need running processes, clipboard, network connections to capture the exfiltration method |
| Unknown APT compromise (no active activity) | Live acquire then power off | Capture volatile data, then preserve disk for full image |
| Rootkit bootkit suspected | Live acquire + specialized tools | Rootkits hide from OS — need memory dump and boot sector imaging |
| Legal / law enforcement involved | Follow LE guidance exactly | Evidence admissibility may require specific acquisition procedures |
Volatile Data Lifespan (Order of Volatility)
| Data Type | Lifetime After System Shutdown | Collection Priority |
|---|---|---|
| CPU registers / cache | Nanoseconds | 1 — cannot be captured after modification |
| RAM / Page tables | Seconds | 2 — DMA cold boot attacks can recover within minutes |
| Network connections | Seconds | 3 — lost when network cable is pulled |
| Running processes | Seconds | 4 — lost when system halts |
| Disk cache / buffers | Minutes | 5 — flushed on shutdown |
| System event logs | Persistent on disk | 6 — survived on disk, but overwritten over time |
| File system | Persistent | 7 — standard dead forensics |
Step 2: Memory Capture (Highest Priority)
Tools for Memory Capture
Before running any memory capture tool, review the Windows Event Logging for recent system events and Volatility for later memory analysis.
| Tool | Platform | Output Format | Notes |
|---|---|---|---|
| DumpIt (Magnet Forensics) | Windows | Raw (.bin or .mem) | Easiest — single EXE, outputs memory file |
| WinPmem | Windows | AFF4 or raw | Open source, integrated with Rekall |
| LiME (Linux Memory Extractor) | Linux | Lime format (raw or compressed) | Loadable kernel module |
| AVML (Microsoft) | Linux | Raw | Creates memory dump without loading kernel module |
| Mac Memory Reader | macOS | Raw | Runs on Intel Macs |
| Firertc | Platform-agnostic | Raw (via DMA) | PCIe capture card — bypasses OS, captures RAM directly (expensive) |
Memory Dump Procedure — Windows (DumpIt)
# 1. Download DumpIt (from Magnet Forensics) to a write-protected USB
# 2. Run from USB — DO NOT run from the compromised system's disk
# 3. Execute (GUI or CLI):
DumpIt.exe
# Output: COMPUTERNAME_DATE_TIME.mem in the same directory
# File size: Same as system RAM (8 GB RAM = ~8 GB memory file)
Memory Dump Procedure — Linux (LiME)
# 1. Transfer LiME to the compromised system via USB or network share
# 2. Load the kernel module:
sudo insmod lime.ko "path=/mnt/forensics/memory.lime format=lime"
# 3. Verify capture:
ls -la /mnt/forensics/memory.lime
# File size: Same as system RAM (may be compressed depending on format)
# 4. Unload the module after capture:
sudo rmmod lime
What to Check After Memory Capture
# Volatility 3 — quick triage of memory dump
vol -f memory.dump windows.pslist
# Identify hidden processes (pslist is API-based; psscan is raw physical scan)
vol -f memory.dump windows.psscan
# Compare — any process in psscan but not pslist is suspicious (rootkit)
vol -f memory.dump windows.pslist | awk '{print $2}' > pslist.txt
vol -f memory.dump windows.psscan | awk '{print $2}' | sort -u > psscan.txt
diff pslist.txt psscan.txt
# Check network connections from memory
vol -f memory.dump windows.netscan
# Extract command lines
vol -f memory.dump windows.cmdline
# Check for injected code
vol -f memory.dump windows.malfind
# Dump suspicious processes for further analysis
vol -f memory.dump windows.dumpfiles.DumpFiles --pid 1234
Step 3: Live Response — Artifact Collection
Windows Live Response Collection
# Create a working directory on a forensics USB
$output = "E:\evidence_$(hostname)_$(Get-Date -Format 'yyyyMMdd_HHmmss')"
New-Item -ItemType Directory -Path $output
# 1. Captured running processes (with parents and command lines)
tasklist /v /fo csv > "$output\tasklist.csv"
wmic process get Name,ProcessId,ParentProcessId,CommandLine,ExecutablePath /format:csv > "$output\processes.csv"
# 2. Network connections
netstat -ano > "$output\netstat.txt"
netstat -anob > "$output\netstat_with_pids.txt" # shows process names (admin required)
# 3. Active network shares
net share > "$output\shares.txt"
# 4. Scheduled tasks
schtasks /query /fo csv /v > "$output\scheduled_tasks.csv"
# 5. Services
sc query type= service state= all > "$output\services.txt"
wmic service get Name,State,StartMode,PathName,ProcessId /format:csv > "$output\services.csv"
# 6. Auto-start locations
reg export "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" "$output\hkcu_run.reg"
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" "$output\hklm_run.reg"
# 7. Event logs (critical ones)
wevtutil epl Security "$output\security.evtx"
wevtutil epl System "$output\system.evtx"
wevtutil epl Application "$output\application.evtx"
wevtutil epl "Windows PowerShell" "$output\powershell.evtx"
# 8. Prefetch files (process execution history, limited retention)
Copy-Item "C:\Windows\Prefetch\*" "$output\prefetch\" -Recurse
# 9. User artifacts (each user profile)
$users = Get-ChildItem "C:\Users" -Directory
foreach ($user in $users) {
$userOutput = "$output\users\$($user.Name)"
New-Item -ItemType Directory -Path $userOutput -Force
# Recent files
Copy-Item "$($user.FullName)\AppData\Roaming\Microsoft\Windows\Recent\*" "$userOutput\recent\" -Recurse -ErrorAction SilentlyContinue
}
# 10. Create hash of all collected files
Get-ChildItem $output -Recurse | Get-FileHash -Algorithm SHA256 > "$output\hashes.txt"
Linux Live Response Collection
#!/bin/bash
OUTPUT="/mnt/forensics/$(hostname)_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUTPUT"
# 1. Running processes
ps auxf > "$OUTPUT/ps_auxf.txt"
ps aux > "$OUTPUT/ps_aux.txt"
# 2. Network connections
netstat -tulpn > "$OUTPUT/netstat.txt"
ss -tulpn > "$OUTPUT/ss.txt"
# 3. Network interfaces
ip addr > "$OUTPUT/ip_addr.txt"
ip route > "$OUTPUT/ip_route.txt"
# 4. Open files
lsof > "$OUTPUT/lsof.txt"
# 5. Loaded kernel modules
lsmod > "$OUTPUT/lsmod.txt"
# 6. User sessions
w > "$OUTPUT/w.txt"
who > "$OUTPUT/who.txt"
last -x > "$OUTPUT/last.txt"
# 7. Auth logs
cp /var/log/auth.log "$OUTPUT/auth.log" 2>/dev/null || true
cp /var/log/secure "$OUTPUT/secure.log" 2>/dev/null || true
# 8. Shell history (for each logged-in user)
cp ~/.bash_history "$OUTPUT/bash_history.txt" 2>/dev/null || true
# 9. Scheduled tasks
ls -la /etc/cron* > "$OUTPUT/cron_contents.txt"
cat /etc/crontab > "$OUTPUT/crontab.txt" 2>/dev/null || true
# 10. Hash all collected files
find "$OUTPUT" -type f -exec sha256sum {} \; > "$OUTPUT/hashes.txt"
Step 4: Disk Imaging (Dead Forensics)
When to Image
| Method | When to Use | Pros | Cons |
|---|---|---|---|
| Live image | System must remain running | Captures locked files, preserves runtime state | Larger image, may miss deleted files |
| Dead image (powered off) | Standard forensics | Best for deleted file recovery, simpler analysis | Loses volatile data |
| Remote image (over network) | Critical server, no physical access | No travel required | Network-dependent, slower, more risk of failure |
| Minimal image (targeted) | Large storage, targeted investigation (find specific files) | Faster, smaller image | May miss unrelated evidence |
Imaging Procedure
# Linux — dd imaging
# Verify the source device first:
sudo fdisk -l /dev/sda
# Create a forensic image
sudo dd if=/dev/sda of=/mnt/forensics/evidence.dd bs=4M conv=noerror,sync status=progress
# Or use dc3dd (enhanced dd with hash calculation):
sudo dc3dd if=/dev/sda of=/mnt/forensics/evidence.dd hash=sha256 hlog=/mnt/forensics/image_hashes.txt
# Guymager (GUI imaging tool on Linux):
# Supports compression, EWF format, progress indication
guymager
Write Blockers
| Type | Connection | Use Case |
|---|---|---|
| Hardware write blocker | USB, FireWire, SATA | Preferred — hardware-enforced read-only access |
| Software write blocker | Linux kernel | Second choice — mount with ro,noatime,nodiratime |
Step 5: Chain of Custody
Chain of custody is the documentation trail that proves evidence was handled correctly, from collection to courtroom. Every transfer, analysis, and storage event must be logged.
Chain of Custody Template
CHAIN OF CUSTODY DOCUMENT
==========================
Incident ID: INC-2026-05-23-001
Case Number: FR-2026-001
EVIDENCE ITEM 1: Memory dump
SRC: COMPUTER01 (10.0.1.45)
DST: FD-HDD-001 (Forensic Drive 1)
Hash (SHA256): e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
File name: COMPUTER01_20260523.mem
| Action | Date/Time (UTC) | Custodian (Name & Signature) | Method | Notes |
|--------|-----------------|------------------------------|--------|-------|
| Acquisition | 2026-05-23 19:15 | Jane Smith (Analyst) | DumpIt v3.0 | System running, captured via write-blocked USB |
| Transfer | 2026-05-23 20:30 | Jane Smith → John Doe (Lead) | Direct handoff, witnessed by CC camera | Evidence sealed in anti-static bag #0412 |
| Analysis | 2026-05-24 09:00 | John Doe (Lead) | Volatility 3 on forensic workstation FW-01 | Volatility analysis — no network access on FW-01 |
| Return | 2026-05-25 17:00 | John Doe → Jane Smith | Direct handoff | Evidence bag #0412 re-sealed |
| Storage | 2026-05-25 17:05 | Jane Smith | Evidence locker #3 | Key held by SOC manager only |
Documentation Principles
| Principle | Description |
|---|---|
| No alteration | Original evidence is never modified — always work on copies |
| Capture hashes | SHA256 hash of every evidence file at acquisition and every transfer |
| Log every action | Date, time, custodian, tool, and purpose of every action on the evidence |
| Secure storage | Evidence in locked, access-controlled storage with audit log |
| Witnessed transfers | Two people sign for evidence handoffs where possible |
| Tool validation | Document which tool version was used and whether the tool was validated |
Related
- EDR Basics — detection and response for T1059, T1003, T1055, T1204, T1562 techniques
- Indicators: IoC, IoA, and TTP — covers the indicators: ioc, ioa, and ttp concepts
- SIEM Log Management — detection and response for TA0040 techniques
- Windows Event Logging & Audit Policy — detection and response for T1562 techniques
- Active Directory Compromise Response — detection and response for T1558 techniques
