Post-Incident Forensics vs Live Response — When to Use Which

A senior IR analyst walks into a conference room. “We’ve contained the host. Do you want live response or do you want me to image the disk?” The wrong answer costs you evidence you cannot get back.

Live response and post-incident forensics are not interchangeable. They answer different questions, operate on different evidence types, and run on different timelines. Teams that conflate them either burn hours doing the wrong thing or miss the evidence that would have closed the case.

This is the decision framework — what each approach actually does, when each is right, and the sequence to use when you want both.

What live response actually is

Live response is evidence collection from a system that is still powered on and running. The analyst (or, more commonly, an automated collector) connects to the system — physically, via SSH/WinRM, or via an EDR’s live-response shell — and gathers volatile and semi-volatile artifacts before the system is shut down.

The evidence categories live response collects:

• RAM contents — process memory, kernel structures, mounted-but-encrypted volume keys, in-flight C2 data, recently-decrypted strings
• Running processes and their loaded modules — pslist, dlllist, handles
• Active network connections — TCP/UDP table, open sockets, listening ports
• Logged-in users and their sessions
• Open files and file handles
• Loaded kernel drivers
• Scheduled tasks, services, and persistence mechanisms in their currently-resolved state
• Recently-executed commands (PowerShell history, bash history, prefetch)
• Browser session state (cookies, active tabs, in-progress downloads)
• Decrypted credentials in memory (LSASS contents, browser-cached passwords)

The defining property: all of this disappears at shutdown. If you do not collect it while the system is running, it is gone forever.

What post-incident (dead-box) forensics actually is

Dead-box forensics is performed after the system is powered off and the disk has been imaged. The investigator works from the disk image — never the live system — using forensic tools (Autopsy, FTK, X-Ways, EnCase) to reconstruct the file system.

The evidence categories dead-box forensics specializes in:

• Complete file system reconstruction — every file, every directory, every metadata field, every NTFS alternate data stream
• Deleted file recovery — anything still recoverable from unallocated space, slack space, and the MFT
• File system timeline reconstruction — when every file was created, modified, accessed, or deleted, correlated across timestamps
• Registry hive analysis (Windows) — autoruns, USB device history, recently-opened documents, user activity
• Browser history and cache — durable artifacts on disk, even after the browser was closed
• Email artifacts — PST/OST/MBOX contents, including deleted messages
• Application-specific artifacts — Skype/Teams/Slack history, Outlook calendars, locally-stored database files
• Slack space and unallocated space carving — fragments of files no longer referenced but not yet overwritten

The defining property: this evidence is preserved indefinitely once the disk image exists, because the image is immutable.

The crucial overlap (and the gap)

Both methods can collect: persistence mechanisms (registry run keys, services, scheduled tasks), file system metadata (creation times), running-process information (live response sees what’s running now; dead-box sees the prefetch and event logs that record what ran).

But neither method alone gets everything:

• Live response misses: complete file system, deleted files, evidence in slack space, evidence that has been written but not yet “noticed” by running processes
• Dead-box misses: anything that existed only in memory (fileless malware, in-memory injected code), the active network state at time of compromise, decrypted credentials and keys, in-flight C2 data

The fileless malware case is the canonical “you needed live response” scenario. A PowerShell payload that lives only in memory leaves traces in event logs but the actual malicious code is in powershell.exe’s memory — visible only in a memory dump. Image the disk after shutdown and the payload is gone with no surviving sample to analyze.

The decision matrix

When you have to choose, run through these questions:

When to do both (and the order matters)

For serious incidents you should do both. The order is fixed:

1. Live response first — capture memory, volatile artifacts, network state. This requires the system to be running.
2. Orderly shutdown — graceful when possible (some destructive payloads trigger on hard shutdown).
3. Hardware write-blocker attached, disk imaged — produce the dead-box image.
4. Dead-box analysis — work from the image, never the live system.

You cannot reverse this order. If you image the disk first then power on the live system, the boot process modifies the disk, taints any future image, and may destroy memory evidence by overwriting RAM.

The standard sequence taught in ECIH and used in court-track investigations:

[Live system found compromised]
       │
       ▼
[Photograph the screen — what's running, what windows are open]
       │
       ▼
[Pull network cable / EDR-quarantine — STOP further activity]
       │
       ▼
[Capture memory dump via WinPMEM / LiME / EDR live-response]
       │
       ▼
[Capture volatile artifact triage via KAPE / Velociraptor]
       │
       ▼
[Document what you collected — chain of custody starts]
       │
       ▼
[Graceful shutdown (Start → Shutdown, OR hard shutdown if destructive
 payload risk — document the choice)]
       │
       ▼
[Attach write-blocker, image the disk per disk-imaging procedure]
       │
       ▼
[Dead-box analysis on image, in lab, on isolated workstation]

Every step has a documentation requirement. The chain of custody form gets a new entry at every step. See Chain of Custody — The Single Mistake That Loses Court Cases for the documentation discipline.

Live response tools, classified

There are four classes of live response tooling, each suited to different scenarios:

Class 1 — Pure memory acquisition

Tools whose only job is to write a memory image to disk:

• WinPMEM — Windows memory imaging, raw or AFF4 output
• LiME (Linux Memory Extractor) — Linux memory imaging, raw or LiME format
• MAGNET RAM Capture — Windows, free, GUI

You run these first, write the dump to external storage, then analyze the dump offline with Volatility 3 (see Memory Forensics with Volatility 3 — A Practical Walkthrough).

Class 2 — Triage collectors

Tools that gather a large pre-defined bundle of volatile + semi-volatile artifacts in one run:

• KAPE (Kroll Artifact Parser and Extractor) — Windows, comprehensive, fast, free
• Velociraptor — cross-platform, query-language driven, free, scales to hundreds of endpoints
• GRR Rapid Response — Google’s tool, cross-platform, scalable, free
• F-Response — commercial, lets investigators mount remote live drives read-only

Use a collector when you need consistent triage across many endpoints, or when one analyst is collecting and another will analyze.

Class 3 — EDR live response

Most modern EDRs include a “live response” or “live terminal” feature that opens an authenticated remote shell to the host without needing a separate tool. Capabilities vary, but most provide:

• File system browse / get / put
• Process listing and termination
• Registry query
• Limited shell command execution
• Memory dump trigger
• Custom-script execution

Use EDR live-response when speed matters and the EDR is already deployed — no need to install another agent on a possibly-compromised host. Trade-off: tied to one vendor, may not support all the artifact types a dedicated collector does.

Class 4 — Targeted artifact tools

When you only need one specific thing and don’t want to image everything:

• Sysinternals Suite — handle.exe, procexp, autoruns, tcpvcon, sigcheck — single-purpose tools that print one piece of state
• NetworkMiner / Wireshark — for live network capture
• Browser history extractors — Hindsight, BrowsingHistoryView

Use these for surgical extractions — “I just need the autoruns” or “I just need to see what’s listening on port 4444.”

The mistakes that destroy live response evidence

Five anti-patterns to avoid:

1. Logging in interactively to a compromised host. Your login modifies LSASS, creates new event log entries, may launch processes, and changes the volatile state you were trying to capture. Use the EDR or remote tooling — do not RDP in.

2. Writing the memory dump to the same drive being imaged. The write modifies the disk and taints any subsequent dead-box image. Always write to external storage (USB, network share to an evidence server, EDR-mediated transfer).

3. Running tools from the compromised host’s local installation. The attacker may have replaced standard binaries (sigcheck, procexp, etc.) with trojanized versions. Always run tools from a known-good kit on external media.

4. Letting the OS auto-update or auto-defrag during acquisition. Memory state changes constantly. The capture should be as fast as possible and the system should be undisturbed during it.

5. Forgetting to hash the memory dump as soon as it’s written. Same chain-of-custody principle as disk images — if there’s no hash, the integrity claim is weaker in court.

When you should NOT do live response

There are scenarios where the right call is to skip live response and go straight to dead-box:

• The host has already been powered off before you arrived. The volatile evidence is gone; further action just delays the dead-box work.
• The compromise is months old and dormant. No active C2, no running process — the evidence is on disk and in logs, not in memory.
• The case is a routine policy-violation investigation (employee misuse, NSFW browsing, casual data theft) where the in-memory state doesn’t matter and a disk image is sufficient.
• The system is a production server where you cannot tolerate the 20–45 min of degradation during live capture AND the immediate harm is contained. Take a snapshot at the hypervisor level (instantaneous) and proceed from there.

The judgment: live response is for cases where volatile evidence matters. If volatile evidence doesn’t matter to this case, skip it.

What ECIH actually tests

The ECIH exam treats live response vs dead-box as a fundamental concept. Expect:

• “Which approach captures volatile evidence?” (live response)
• Order-of-operations questions (live before dead-box, always)
• Tool-to-purpose mapping (WinPMEM → memory; FTK Imager → disk; KAPE → triage)
• Scenario questions (“which approach would best answer X?”)
• Court-admissibility questions on whether live response can be used as evidence (yes, with proper methodology)

The classic exam trap is the question where the system has already been shut down and you’re asked what to do — the right answer is dead-box; do not try to power it back on to “do live response.” Powering on modifies the disk.

Where this fits in the overall response

Live response is a Detection & Analysis / Containment activity. Dead-box forensics is typically a Post-Incident activity (though it may overlap with eradication when you need to confirm the threat is fully removed). Both feed the Post-Incident Activity phase where lessons-learned and evidence retention happen.

Where to take this next

For the memory-dump analysis that follows live response, Memory Forensics with Volatility 3 — A Practical Walkthrough is the next step.

For the disk-imaging procedure that the dead-box workflow depends on, Disk Imaging in Forensics — dd vs FTK Imager vs Autopsy covers tool choice and methodology.

For the chain-of-custody discipline that makes either approach admissible, Chain of Custody — The Single Mistake That Loses Court Cases is mandatory reading.

For the containment decision that precedes any evidence collection, Containment Decisions Under Pressure covers the trade-offs.

And to put it all in a procedure your team actually follows, Building an Incident Response Playbook from Zero is the structure.