Chapter 5 · Attacks & Defenses·Advanced·~16 min

Incident Response

Timeline reconstruction from disk and memory, Volatility-driven RAM analysis, the attribution problem, tabletop exercises that actually find gaps, and what a good postmortem looks like.

You will learn

  • Building a forensic timeline from filesystem, registry, and event logs
  • Memory forensics with Volatility: process trees, injected code, persistence
  • Why attribution is hard and which signals carry weight
  • Tabletop design: injects, decision points, what to measure
  • Blameless postmortems and the action-item discipline

Timeline reconstruction

The first artifact in any serious investigation is a timeline. Tools like Plaso (log2timeline) parse dozens of source formats into a unified, sorted event list. Sources that consistently pay off:

  • Windows Event Logs: 4624/4625 logons, 4688 process creation (if enabled), 7045 service install, Sysmon 1/3/11 if deployed.
  • Filesystem MFT: $STANDARD_INFORMATION vs $FILE_NAME timestamps. Timestomping changes the first but not the second; the divergence is the IOC.
  • Registry hives: ShimCache, AmCache, UserAssist, RecentDocs, all of which record executed-binary metadata even when the binary is gone.
  • Prefetch: confirms execution, gives a count, and records the last 8 run timestamps in modern Windows.
  • Browser history and downloads: Chrome's History DB and Edge's WebCache often contain the initial-access URL.

The skill is correlating across sources: a 4688 firing inside a process tree whose parent is an unusual WMI provider, with a corresponding Prefetch entry, with a download in the browser history five minutes earlier. That chain is the breach narrative.

Memory forensics

Disk gives you persistence. Memory gives you running malware, decrypted strings, injected code, and credentials that never touched disk. Capture with WinPMem, DumpIt, or via hypervisor introspection on cloud workloads; analyze with Volatility 3 or Rekall.

The bread-and-butter Volatility commands:

  • windows.pslist and windows.psscan: process list from the active list vs scanning for EPROCESS structures. Divergence indicates DKOM-style hiding.
  • windows.malfind: scans for executable pages without a backing file (classic injected code).
  • windows.netscan: socket and connection state, including for processes that closed connections recently.
  • windows.dlllist and windows.handles: loaded modules and open handles per process; useful for finding LSASS-touching tools.
  • windows.cmdline: full command-line of each process, often containing PowerShell payloads inline.

Memory dumps are best taken before isolation or shutdown. If a host is suspected of being compromised, the question is whether to pull network first (preserving memory state but tipping the attacker) or capture memory first (slower but more evidence).

Attribution: what holds up

Attribution carries political weight and is often demanded by stakeholders. What actually justifies it:

  • TTP overlap: the same toolset, the same operator habits (typo in batch scripts, working hours), the same C2 fronting infrastructure as a previously documented group.
  • Infrastructure reuse: a domain registered with the same odd email pattern, a TLS certificate with the same uncommon JA3, an X.509 subject identical to a prior campaign.
  • Code reuse: distinctive code paths or strings that match a tracked family; YARA rules over time.

What does NOT hold up alone: language strings in the malware (planted), timezone of activity (planted), IP geolocation of C2 (rented). Attribution is a probabilistic statement built from many weak signals; single-source attribution is usually wrong.

The Mandiant APT1 report (2013) set the modern bar by combining infrastructure, OPSEC failures, and persistent TTP tracking over years.

Tabletop exercises

A tabletop is a scripted scenario walked through with decision-makers. Good tabletops produce specific gaps, not feel-good participation. Design principles:

  • Realistic injects: drip new information every 10-15 minutes (the SOC sees X; a journalist calls; regulator sends a question). Pace mirrors actual incidents.
  • Force decisions, not discussion: at each branch, the team must choose. "We would call legal" is not a decision; "Legal, who has authority to take production read-only?" is.
  • Include adjacent teams: comms, legal, exec, customer support. Tech-only tabletops miss the failures that hurt most (no comms plan when CNN calls).
  • Measure: time to first decision, time to first external comm, time to containment decision, count of action items generated.

An exercise that ends with "we handled it well" was probably too easy. An exercise that ends with 12 concrete action items in the backlog is the goal.

Postmortems

The discipline borrowed from SRE: blameless, factual, with concrete action items and owners. A useful template:

  1. Summary: one paragraph a CEO can read.
  2. Timeline: minute-by-minute, including detection lag, decision points, mitigation steps.
  3. Impact: data affected, customer impact, regulatory exposure, dollar estimate.
  4. Root cause(s): technical, process, organizational. Usually multiple.
  5. What went well: name it. The next incident depends on the same people choosing to engage.
  6. What did not: name it without blame.
  7. Action items: each with an owner, a due date, and a tracking ticket. Anything else is a wish.

The single best test: six months after the postmortem, can you point at completed action items, or did the document become wallpaper? Most do. The teams that do not are the ones that improve.

The two regrets that recur

Across decades of incident reports, two regrets dominate:

  • Backups that were never restore-tested: encrypted by ransomware, useless when needed, because the restore path was never exercised end-to-end.
  • Logs that were never centralized: each host had relevant data, but the data lived only on that host, which the attacker wiped. Centralization with write-once retention is the single highest-ROI investment.

If your org has done both, it is ahead of most.

Take the quizBack to intermediate