Playbooks

T1562.001

Digital 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

ScenarioActionRationale
Ransomware encrypting filesPull the plug immediatelyStop the encryption — disk forensics sufficient
Active C2 beacon observedLive acquireMemory contains the implant, network connections, and decrypted C2 communication
Insider data exfiltrationLive acquireNeed running processes, clipboard, network connections to capture the exfiltration method
Unknown APT compromise (no active activity)Live acquire then power offCapture volatile data, then preserve disk for full image
Rootkit bootkit suspectedLive acquire + specialized toolsRootkits hide from OS — need memory dump and boot sector imaging
Legal / law enforcement involvedFollow LE guidance exactlyEvidence admissibility may require specific acquisition procedures

Volatile Data Lifespan (Order of Volatility)

Data TypeLifetime After System ShutdownCollection Priority
CPU registers / cacheNanoseconds1 — cannot be captured after modification
RAM / Page tablesSeconds2 — DMA cold boot attacks can recover within minutes
Network connectionsSeconds3 — lost when network cable is pulled
Running processesSeconds4 — lost when system halts
Disk cache / buffersMinutes5 — flushed on shutdown
System event logsPersistent on disk6 — survived on disk, but overwritten over time
File systemPersistent7 — 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.

ToolPlatformOutput FormatNotes
DumpIt (Magnet Forensics)WindowsRaw (.bin or .mem)Easiest — single EXE, outputs memory file
WinPmemWindowsAFF4 or rawOpen source, integrated with Rekall
LiME (Linux Memory Extractor)LinuxLime format (raw or compressed)Loadable kernel module
AVML (Microsoft)LinuxRawCreates memory dump without loading kernel module
Mac Memory ReadermacOSRawRuns on Intel Macs
FirertcPlatform-agnosticRaw (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

MethodWhen to UseProsCons
Live imageSystem must remain runningCaptures locked files, preserves runtime stateLarger image, may miss deleted files
Dead image (powered off)Standard forensicsBest for deleted file recovery, simpler analysisLoses volatile data
Remote image (over network)Critical server, no physical accessNo travel requiredNetwork-dependent, slower, more risk of failure
Minimal image (targeted)Large storage, targeted investigation (find specific files)Faster, smaller imageMay 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

TypeConnectionUse Case
Hardware write blockerUSB, FireWire, SATAPreferred — hardware-enforced read-only access
Software write blockerLinux kernelSecond 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

PrincipleDescription
No alterationOriginal evidence is never modified — always work on copies
Capture hashesSHA256 hash of every evidence file at acquisition and every transfer
Log every actionDate, time, custodian, tool, and purpose of every action on the evidence
Secure storageEvidence in locked, access-controlled storage with audit log
Witnessed transfersTwo people sign for evidence handoffs where possible
Tool validationDocument which tool version was used and whether the tool was validated

Sources