Chapter 15: Live Response and Triage Forensics — Capturing Volatile Evidence Before You Pull the Plug

Where you are: Part III, Chapter 15 of 40. Chapter 14 taught the gold-standard acquisition: power the machine down, attach a write-blocker, image a still disk, and prove the copy is bit-for-bit identical. This chapter handles the messier reality you will meet far more often — the machine is on, you cannot turn it off without losing the case, and the most valuable evidence in the room evaporates the instant you pull the plug. It is the bridge from acquisition (Ch.14) to memory forensics (Ch.22), and it is the home of the order of volatility and triage at scale (KAPE, CyLR, Velociraptor).

Learning paths: This chapter is the spine of the 🛡️ Incident Response track — when an alert fires at 2 a.m., this is the playbook. 🔍 Forensic Examiners need it for live previews and for defending alterations they made to a running system. 📜 Legal/eDiscovery practitioners must understand it because here, more than anywhere, you knowingly change the original — and you will be asked to justify every keystroke. 💾 Data Recovery techs get two gifts: how full-disk encryption can turn a clean power-off into a permanently locked brick, and how to rescue a deleted-but-still-open file before the process exits.

The 2 a.m. decision: a server you cannot turn off

The page comes in at 02:14. Your endpoint detection platform flagged a production web server — call it WEB-07, 10.20.3.17 — for repeated outbound connections to a hosting-range IP address it has never spoken to before, on a regular sixty-second heartbeat. That cadence is the signature of malware beaconing to a command-and-control (C2) server: checking in, asking for orders. By the time you VPN in and pull up the console, three facts are already shaping every decision you will make tonight.

First, WEB-07 is live and in production. It is serving customer traffic and holding open database connections mid-transaction. Pulling the power cord — the move Chapter 14 would have you make on a seized desktop — will drop those connections, possibly corrupt the database, and take a revenue-generating service offline. That is a business decision as much as a forensic one, and at 2 a.m. it is your decision.

Second, and more important forensically, the interesting part of this intrusion may not be on the disk at all. Modern intrusions are frequently fileless: the attacker's code runs entirely in memory, injected into a legitimate process like svchost.exe or lsass.exe, never written to a file you could carve back later. The C2 address, the decryption key for the next-stage payload, the commands the operator has already typed, the credentials harvested from this host — all of that lives in RAM right now and only in RAM. Power the machine off and it is gone forever. There is no undelete for volatile memory.

Third, you do not yet know whether WEB-07's system disk is encrypted. If BitLocker (or LUKS, or FileVault) is protecting the volume and the key is not escrowed where you can reach it, then a power-off does not just lose RAM — it re-locks the disk. You would be left holding a lawfully acquired image that is an unreadable wall of ciphertext. The system is running and decrypted right now; that is a window that closes the moment the power does.

This is the situation Chapter 14 does not cover, and it is the rule rather than the exception in incident response. Chapter 14's discipline — the original is sacred; never work on the original — assumed you had the luxury of a powered-off device and a write-blocker. Tonight you have neither. You are going to touch a running, possibly compromised, possibly evidence-destroying system with your own hands, and every command you run will change it. The skill this chapter teaches is not how to avoid that — you cannot — but how to do it in the right order, capture the most perishable evidence first, and document your actions so thoroughly that a year from now, on a witness stand, you can account for every byte you altered and prove that the evidence you collected is sound even though the system you collected it from is not.

Why This Matters. Chapter 14's mantra — the original is sacred — is not abandoned here; it is adapted. In live response you cannot keep the original pristine, so the discipline shifts from preservation to minimization plus documentation: touch as little as possible, in a defensible order, and record everything you touch with timestamps and hashes. Technology changed (RAM-only malware, full-disk encryption, cloud-tethered state); the principle did not. You still treat the original with reverence — you just prove your reverence with a logbook instead of a write-blocker.

The observer effect, stated plainly

In 1910 the forensic scientist Edmond Locard articulated what every examiner now calls Locard's exchange principle: every contact leaves a trace. It was meant to describe how a burglar carries fibers out and leaves fingerprints behind, but it describes you on a live system with uncomfortable precision. The instant you run tasklist, the operating system allocates memory for the command, loads pages, updates the process table, writes Prefetch evidence, advances the system clock, and possibly evicts from RAM the very pages you were hoping to capture. You are Locard's burglar. You cannot enter the scene without altering it.

The honest, professional response is not to pretend otherwise. It is to (1) capture the highest-value, most-volatile evidence before you start poking around, (2) prefer tools that touch as little as possible, (3) write all your output off the subject machine, and (4) log your own footprints so meticulously that they can never be confused with the intruder's. That last point is the second recurring theme of this book — every action leaves a trace, and the absence of a trace is itself a trace — turned back on the examiner. Your traces must be distinguishable from the suspect's, or you have contaminated your own crime scene.

The order of volatility

When you cannot collect everything at once — and on a live system you never can — you collect in order of how fast each thing disappears. The canonical statement is RFC 3227, the IETF's February 2002 "Guidelines for Evidence Collection and Archiving," §2.1, Order of Volatility. It is twenty-plus years old and still governs every live-response playbook in the field. Technology changes; this principle does not.

From nanoseconds to years

RFC 3227 lists, from most to least volatile:

ORDER OF VOLATILITY   (RFC 3227 §2.1)   —   collect TOP-DOWN, fastest-dying first

  MORE VOLATILE  ▲   Tier  Artifact                              Typical lifetime
  ───────────────┼──────────────────────────────────────────────────────────────
        |        │   1    CPU registers, L1/L2/L3 caches         nanoseconds
        |        │   2    Routing table, ARP cache, process      seconds –
        |        │        table, kernel statistics, *memory*       minutes (state)
        |        │   3    System RAM (full contents)              until power off
        |        │   4    Temporary file systems                  minutes – hours
        |        │        (tmpfs, /tmp, pagefile.sys, hiberfil)
        |        │   5    Disk — allocated + UNALLOCATED          years (until
        |        │                                                  overwritten)
        |        │   6    Remote logs, NetFlow, SIEM, monitoring  days – years
        |        │   7    Physical config, network topology       stable
  LESS VOLATILE  ▼   8    Archival media (backups, tape, cloud)   years – decades

A few notes on reading this ladder. RFC 3227 actually groups "memory" together with the routing table, ARP cache, and process table in a single tier, because all of those die at power-off. For teaching purposes the diagram breaks RAM out onto its own line, because the full contents of RAM (tier 3) are a strict superset of the live network and process state (tier 2): if you capture a complete memory image, you can later reconstruct the process list, network connections, and ARP cache from the image using Volatility (Ch.22). That is the central insight that drives the collection order in the next subsection.

Tier 1 — registers and CPU cache — has a lifetime measured in nanoseconds and is, for all practical purposes, uncapturable by software running on the same CPU. You will never image the L1 cache. Forensics quietly skips tier 1 and starts where it can actually get a grip: tier 2/3, system memory.

Notice where disk sits: tier 5, with a lifetime of years. This is the first recurring theme of the book — deleted ≠ destroyed — restated as a volatility argument. The unallocated space on that disk, where deleted files persist until overwritten, is one of the least volatile things in the room. It will wait for you. RAM will not. That is why, counterintuitively to newcomers, the running system's memory is a higher acquisition priority than the hard drive that physically dominates it.

Why This Matters. The order of volatility converts an overwhelming scene ("everything is evidence and I have one pair of hands") into a queue. You do not have to decide whether something is worth collecting under pressure; you decide the order, fastest-dying first, and you keep moving down the ladder. When a defense attorney later asks why you collected memory before disk, your answer is not improvisation — it is a twenty-year-old published standard.

Why memory usually comes first

Here is the subtle part, and the place newcomers most often go wrong. There are two reasonable schools of thought about what to grab first on a live box:

School one: snapshot the live state first. Run a quick, scripted battery of commands — process list, network connections, logged-on users — then image memory. The argument: an active C2 connection might drop at any second, and netstat captures it in milliseconds whereas a memory image takes minutes.

School two: image memory first, then collect state. The argument: every command you run pollutes memory. Each tasklist, each netstat, allocates pages, loads DLLs, and can evict the attacker's data from RAM before your memory imager ever reaches it. If memory is your highest-value evidence (and against fileless malware it is), you protect it by capturing it before you trample it. And because a full memory image is a superset of live state, you lose almost nothing: you can recover the process list and network connections from the memory image afterward with Volatility's pslist and netscan plugins (Ch.22).

The mature answer reconciles them and is what this chapter recommends: image memory first, because it is the largest, highest-value, most fragile artifact and because running other tools degrades it; then collect the live volatile state with a fast scripted battery; then move to triage and disk. The one exception that justifies a quick pre-capture network snapshot is when a transient connection is itself the evidence you cannot afford to lose and the memory image will take many minutes — in that case grab netstat/ss first, in seconds, then image memory. Whatever you choose, the rule that actually matters is: decide the order deliberately, write down the order you used, and write down why. A documented, defensible order beats a "perfect" one you cannot reconstruct on the stand.

Limitation. There is no zero-footprint capture of a live system, including the memory capture itself. The imager must run on the subject's CPU, allocate its own memory, and load its own driver — it overwrites some of the very thing it is reading. A software memory image is therefore internally inconsistent (a "smear," discussed below) and can never be reproduced bit-for-bit. Accept this, document it, and do not let an opponent frame an unavoidable physical fact as negligence. The alternative to an imperfect memory image is no memory image, which is worse.

When you cannot just pull the plug

For most of forensic history the standard advice for a seized computer was blunt: pull the plug. Not a graceful shutdown — yank the power so that shutdown scripts, anti-forensic wipers, and journaling cleanup never run, freezing the disk in place. That advice was correct for its era and is still correct for many cases. But four modern realities can turn a reflexive power-off into the worst decision of the investigation.

Full-disk encryption that re-locks on shutdown

This is the big one, and it has rewritten the playbook. When a volume is protected by BitLocker, FileVault 2, LUKS, or VeraCrypt, the data on the platters is ciphertext. While the system is booted and unlocked, the operating system holds the volume's decryption key in RAM and transparently decrypts every read. The moment you power off, that key is purged from memory and the volume re-locks. Now your lawfully seized, perfectly imaged drive is a featureless field of high-entropy bytes, and without the recovery key, passphrase, or a key escrowed in Active Directory / a TPM you can reach, it is — practically speaking — unrecoverable. (Encrypted-device forensics is the whole of Chapter 29; the point here is the live-response decision it forces.)

A live, unlocked, encrypted system offers two things a powered-off one cannot:

• A logical image of the decrypted volume. While the OS is up, you can image the mounted (decrypted) file system, capturing plaintext you could never reach from the raw disk later. This is live imaging (next section), with all its tradeoffs.
• The key itself, sitting in RAM. This is why memory capture and encryption intersect. The Full Volume Encryption Key (FVEK) and master keys live in memory while the volume is mounted. Tools such as bulk_extractor (with its AES key-schedule scanner), Elcomsoft Forensic Disk Decryptor, and Passware can recover those keys from a memory image and use them to decrypt an otherwise-locked disk image acquired later. Capture the RAM, recover the key, decrypt the dead-box image at your leisure. None of that is possible if you powered the machine off first.

War Story. A laptop is seized during an arrest. The responding officer, trained in the "always pull the plug" era, holds the power button until it dies — textbook, a decade ago. The drive is BitLocker-protected with a TPM-only protector and no escrowed recovery key. The lawfully obtained image is a 512 GB block of ciphertext. The case proceeds on other evidence, but the laptop — likely the richest source in the investigation — contributes nothing. The lesson is not that the officer was careless; it is that the technology changed and the procedure had to change with it. When you encounter a running, unlocked, encrypted device, the order of volatility now has an invisible top entry: the decryption key, dying at power-off.

Production services and the graceful-shutdown trap

WEB-07 is running a database mid-transaction. A hard power-off may leave that database in an inconsistent state requiring recovery on next boot; a graceful shutdown flushes buffers cleanly. So far that argues for a polite shutdown. But a graceful shutdown also runs code — shutdown scripts, scheduled cleanup, log rotation, and, on a compromised host, potentially an attacker's shutdown-triggered wiper that destroys evidence as the lights go out. You are caught between two failure modes: hard power-off risks data corruption; graceful shutdown risks evidence destruction and tips off any logic watching for it.

The modern resolution is usually a third option: do not shut down at all. Capture memory and triage artifacts on the live box, image the running volume if it is encrypted, and isolate rather than power off (next subsection). When you must take the host down, the forensic default for a suspected compromise still leans toward pull the plug over graceful shutdown — you would rather repair a journaling file system than let a wiper run — but you make that call consciously, after you have captured the volatile evidence that the power-off will destroy.

Cloud-tethered and ephemeral state

A 2026 workstation is rarely an island. It holds OAuth tokens and session cookies in memory that grant access to cloud accounts; it has cloud drives mounted (OneDrive, Google Drive, Dropbox) whose contents may be placeholders backed by servers you will need a separate legal process to reach (Ch.31); and it may be enrolled in mobile device management (MDM) that can issue a remote wipe the moment the device phones home or, conversely, the moment it goes offline and trips a "lost device" rule. Power-off and network-disconnect are no longer neutral acts. Disconnecting the network can trigger a dead-man response; leaving it connected can let an attacker — or an administrator, or an automated policy — destroy evidence remotely.

For servers, the cloud dimension is starker still. If WEB-07 is a virtual machine on a hypervisor you control, the cleanest possible capture is not an in-guest tool at all — it is a hypervisor snapshot that freezes RAM and disk together from outside the guest (more on this under memory capture). If WEB-07 is a cloud instance, your acquisition options shift to snapshotting the block volume through the cloud provider's API and capturing memory through an agent — a different toolkit, owned by Chapter 31, but the decision to act live rather than terminate the instance is made right here.

Isolate, don't always terminate

In incident response there is a permanent tension between containment (stop the attacker from doing more damage — the security priority) and preservation (keep the evidence intact — the forensic priority). Reflexively pulling the network cable serves containment but can destroy volatile evidence and trigger dead-man logic. The modern middle path is host isolation via an EDR agent: tools like CrowdStrike Falcon, Microsoft Defender for Endpoint, and Carbon Black can sever a host's network connections except the management channel back to you, freezing the attacker out while keeping the machine powered, memory intact, and reachable for live collection. Isolation buys you the time to capture memory and triage before anyone decides whether to power down. When EDR isolation is not available, a documented decision to physically disconnect the network — after capturing network state — is the fallback.

Legal Note. Before you touch the keyboard, establish and record your legal authority to act live. In a corporate IR you typically act under the engagement letter, the organization's acceptable-use policy, and explicit written authorization from a system owner who can consent (Ch.25). In law enforcement, live, on-scene examination may rest on a warrant that authorizes it, on consent, or on exigent circumstances — and few things establish exigency like evidence being actively destroyed in front of you (ransomware encrypting, a remote-wipe countdown, a wiper armed for shutdown). Note the basis in your log before the first command. "I had authority because…" written at 02:16 is far stronger than the same sentence reconstructed for a deposition two years later. The legal frameworks are detailed in Chapter 25 and Appendix E.

Live imaging vs. dead-box imaging

Chapter 14 was entirely about dead-box imaging: power off, write-block, image the static disk, verify the hash, and — crucially — be able to re-image and re-verify to the same hash on demand, because a powered-off disk does not change. That reproducibility is the bedrock of the dead-box method's courtroom strength. Live imaging is what you do when dead-box is impossible or would lose the case: you image the disk (or just memory) while the system runs. It is sometimes the only option — an unlocked encrypted volume, a server that cannot go down, a hardware RAID whose logical volume only exists while the controller is powered. But it comes with two hard tradeoffs you must understand and disclose.

The smear: why a live image is a blurred photograph

A dead-box image is a sharp photograph of a still subject. A live image is a long-exposure photograph of a moving subject — it comes out blurred, and forensics calls that blur smearing. Here is why. Imaging a 1 TB volume takes time — minutes to hours. During that time the running operating system keeps writing: log entries append, temp files appear and vanish, a database commits transactions, pages swap. Your imager reads sector 0 at 02:30 and sector 2,000,000,000 at 03:10. Those two sectors were captured forty minutes apart, from a system that was modifying itself the entire time. The result is an image that represents no single point in time — it is a composite, internally inconsistent snapshot. A file's directory entry might be captured before the data it points to was written, or after it was deleted. Memory images smear for the same reason, and worse, because RAM changes far faster than disk.

DEAD-BOX IMAGE                          LIVE IMAGE (SMEARED)
=============                           ====================
power OFF, write-blocked                power ON, system still writing
single point in time                   composite over minutes/hours
re-acquire -> SAME hash  (verifiable)   re-acquire -> DIFFERENT hash (system moved)
hash proves: copy == original          hash proves: integrity FROM acquisition forward
gold standard for admissibility        sometimes the ONLY option; disclose the tradeoff

The hash means something different now

In dead-box work the hash is a proof of equality: this image equals that original, and anyone can re-run the math to confirm it. In live work that proof is unavailable, because the original is a moving target — re-image WEB-07 five minutes later and you will get a different hash, not because anyone tampered with anything but because the system lived in between. So what does a hash of a live image prove? It proves integrity from the moment of acquisition forward: this image has not changed since I captured and hashed it. You compute the hash immediately on completion, record it in the log, and from that instant the hash guards the evidence file against alteration. It does not — and cannot — prove the image is a faithful single-instant copy of the source. Stating this distinction plainly in your report is not a confession of weakness; it is the mark of an examiner who understands the method. Opposing counsel cannot ambush you with a fact you disclosed first.

Recovery vs. Forensics. The same live image serves both disciplines, with different acceptance criteria. The 💾 recovery engineer imaging an unlocked, failing, encrypted laptop cares about getting the user's irreplaceable data out before the window closes — a smeared image that yields the files is a total success, and reproducibility is irrelevant. The 🔍 forensic examiner imaging the same laptop must additionally hash the result immediately, log the smearing as a known limitation, and be ready to testify that the inconsistency is inherent to live acquisition and does not impugn the specific files relied upon. Identical bytes captured by an identical command; two different bars to clear. This dual lens — can I use it? versus can I defend it? — recurs through every technique in this book.

The original is still sacred — even when you must touch it

It is worth confronting the apparent contradiction head-on, because a sharp cross-examiner will. Theme two of this book is the original is sacred; never work on the original. Live response appears to violate it outright — you are running commands directly on the evidence. The resolution is that "sacred" never meant "untouched at any cost"; it meant never carelessly or unaccountably altered. On a powered-off disk, reverence looks like a write-blocker. On a running system where a write-blocker is impossible, reverence looks like: capture memory before you trample it, run the fewest and lightest commands that get the job done, write every byte of output to external media so you never overwrite the subject's unallocated space, and log each action with a UTC timestamp and a hash. You are still treating the original as sacred. You are simply proving it with a disciplined, witnessed logbook instead of a piece of hardware. The principle endures; only its expression adapts to the technology.

Capturing volatile data, step by step

With the philosophy settled, here is the concrete sequence on a live host, in volatility order. Throughout, two ground rules are absolute: run trusted tools, and write output off the box.

Establishing trust: your toolkit and the two-clock problem

Do not trust the subject's own binaries. A competent attacker installs a rootkit that hooks the very commands you would use to investigate — a trojaned netstat that omits the C2 connection, a ps/tasklist that hides the malicious process, an ls that skips the malware's directory. If you run the subject's netstat, you may be reading the attacker's curated fiction. The countermeasure is a trusted toolkit on your own read-only media — statically-linked binaries (no dependency on the subject's possibly-poisoned shared libraries) on a USB stick or optical disc you prepared in advance and verified by hash. On Windows you carry your own copies of the Sysinternals suite and the EZ Tools; on Linux a static busybox plus static builds of ss, lsof, and friends.

This also enables one of the most elegant rootkit-detection techniques there is, and it is pure theme three — the absence of a trace is itself a trace. Run the cross-view difference: list processes (or connections, or files) two ways — once with the subject's tools and once with your trusted tools, or once through a high-level API and once by walking kernel structures directly — and diff the results. Anything that appears in the trusted/low-level view but is missing from the subject/high-level view is being actively hidden. The discrepancy is the evidence of the rootkit. A listening port that netstat denies exists, revealed by a kernel-level enumerator, is a fingerprint left by the very tool trying to leave none. (Anti-forensics and its detection is the whole of Chapter 30.)

Then solve the two-clock problem. Every timestamp you record is meaningless unless you know how the subject's clock relates to real time. The machine's clock may be skewed by seconds or wrong by hours, set to the wrong time zone, or deliberately altered. So your very first recorded action is to capture the subject's system time and an authoritative external time (your own synced watch, a phone, an NTP query) in the same log line, and note the skew. Now every later "the file was accessed at 19:43" can be translated to true UTC, and you can rebut any claim that your timeline is built on a lying clock. (Timestamps, time zones, and skew get their full treatment in Chapter 21.)

Tool Tip. Write your output off the subject system — to a dedicated evidence USB drive or, better, streamed over the network to a collector — and never to the subject's own disk. Writing to the subject's C: allocates clusters in unallocated space, overwriting the deleted-file remnants and slack you may need to carve later (theme one: deleted ≠ destroyed, unless you overwrite it yourself). The cleanest off-box pattern is a network stream: on your collector run a listener, e.g. nc -l -p 8888 > image.raw, and pipe the subject's acquisition tool straight to it so nothing lands on the subject's storage at all.

Capturing memory

Memory is the prize, so it comes first. The tool depends on the operating system, but the discipline is constant: run a trusted imager from your media, write the image to external media or a network stream, and hash it the instant it completes.

On Windows, the common choices are WinPmem (the open-source imager from the Velocidex/Rekall lineage), Magnet RAM Capture, Belkasoft RAM Capturer, FTK Imager's "Capture Memory" function (runnable from a USB Lite build), and Comae/Magnet DumpIt (often as simple as double-click → raw dump). A minimal WinPmem run, writing to the evidence drive E: and hashing immediately:

E:\tools> winpmem_mini_x64_rc2.exe E:\evidence\WEB07\WEB07-mem.raw
WinPmem64
 - Extracting driver to C:\Windows\Temp\pme....sys   <-- footprint: a driver loads
 - Driver loaded.
Will generate a RAW image
 - PhysicalMemory ranges: 18 segments, total 0x4_0000_0000 bytes (16 GiB)
 - Padding gaps with zeros...
... 100% .......................................... done
Acquisition complete. 17179869184 bytes written.
 - Driver unloaded.

E:\tools> certutil -hashfile E:\evidence\WEB07\WEB07-mem.raw SHA256
SHA256 hash of E:\evidence\WEB07\WEB07-mem.raw:
a17f4c9e2b6d83f05c1ae97d44b2e8103fd6c5b9a82e7041d3c9b6e5f0a1d2c4
CertUtil: -hashfile command completed successfully.

Two things to internalize from that output. First, the line Extracting driver and Driver loaded is your footprint, honestly displayed — the imager installs a kernel driver to read physical memory, which writes a temporary file and loads code. You did not avoid altering the system; you used a tool that tells you how it altered the system, and you log it. Second, the hash is computed and recorded immediately. From this line forward, a17f4c9e… is the seal on the evidence file.

On Linux, the modern, low-friction choice is AVML (Microsoft's "Acquire Volatile Memory for Linux"), a static binary that writes the LiME format and needs no matching kernel headers. The classic is LiME itself (the Linux Memory Extractor), a loadable kernel module — and LiME can stream straight over the network, writing nothing to the subject's disk:

# Option A — AVML (static, simplest), write to the evidence mount:
/mnt/ir/bin/avml /mnt/evidence/WEB07/WEB07-mem.lime
sha256sum /mnt/evidence/WEB07/WEB07-mem.lime | tee -a /mnt/evidence/SHA256SUMS

# Option B — LiME, streamed OFF-BOX over TCP (nothing touches the subject's disk):
#   on the collector:   nc -l -p 8888 > WEB07-mem.lime
#   on the subject (module from YOUR media):
insmod /mnt/ir/lime.ko "path=tcp:8888 format=lime"

And the cleanest capture of all, when the subject is a virtual machine you control: take a hypervisor snapshot and copy the resulting memory file from outside the guest. A VMware suspend produces a .vmem file (guest RAM) and a .vmsn snapshot; copying the .vmem gives you a memory image with near-zero in-guest footprint — you never ran a single tool inside the suspect operating system. When the option exists, snapshot-based capture is forensically superior to any in-guest imager, precisely because it minimizes the observer effect. Note all of these formats — raw, LiME, .vmem — load directly into Volatility for analysis in Chapter 22; your job tonight is to capture them soundly, not yet to parse them.

Try This. On your own workstation (never a production or evidence machine), capture memory with a free tool — WinPmem on Windows, AVML on Linux — and immediately hash it. Then capture it again and hash the second copy. The two hashes will differ. Sit with that for a moment: it is the smearing principle from earlier made tangible. A live capture is never reproducible, and that is a property of physics, not a flaw in your technique. Knowing it in your fingers means you will never be rattled when a cross-examiner "discovers" it.

Processes and parent-child lineage

With memory secured, capture the live state — starting with the running processes. A bare process name is nearly useless; what convicts is the full command line, the executable path, and the parent process ID (PPID). The command line shows what was run with what arguments (a PowerShell one-liner with a base64 -EncodedCommand payload is a screaming red flag). The PPID shows the lineage: a cmd.exe whose parent is the Microsoft Word process means a malicious macro spawned a shell — a classic intrusion pattern invisible if you only look at process names in isolation.

On Windows, prefer the structured collectors that capture command line and parentage:

# Run from an ELEVATED PowerShell launched from YOUR removable media (E:).
# All output goes to E:\ (evidence drive) — NEVER to the subject's C:.
$out = "E:\evidence\WEB07\volatile"
New-Item -ItemType Directory -Force -Path $out | Out-Null
Start-Transcript -Path "$out\session-transcript.txt" -IncludeInvocationHeader

# 1) Two-clock problem FIRST: record system time, source, and skew.
Get-Date -Format o                              # examiner-visible UTC offset
w32tm /query /status                            # time source / last sync

# 2) Processes WITH command line, parent, and image path (the parts that matter):
Get-CimInstance Win32_Process |
    Select-Object ProcessId, ParentProcessId, Name, CommandLine, ExecutablePath, CreationDate |
    Sort-Object ParentProcessId |
    Export-Csv "$out\processes.csv" -NoTypeInformation

On Linux, one line gets you PID, parent, user, the real start time, state, and the full argument vector:

ps -eo pid,ppid,user,lstart,stat,args > "$OUT/processes.txt"

War Story. A responder captures a tidy process list with tasklist — names only — and reports "nothing unusual; just the normal Windows processes." Weeks later, the memory image tells a different story: a legitimately-named svchost.exe had a non-standard parent and a command line pointing at a temp directory. The name was camouflage; the lineage and command line were the tell, and they were never collected live because the responder grabbed the cheapest, least-informative view. Capture command line and PPID, every time. The expensive collection is the one you have to redo from a memory image because the cheap one told you nothing.

Network connections and listening ports

Beaconing brought you here, so network state is central. You want every connection and listening socket, in numeric form, mapped to the owning process. On Windows, the workhorse is netstat with the flags that matter — -a (all, including listeners), -n (numeric; never let it do slow reverse-DNS that also tips off the attacker), -o (owning PID), -b (owning executable; requires elevation):

C:\> netstat -anob

Active Connections
  Proto  Local Address        Foreign Address        State         PID
  TCP    10.20.3.17:49774     185.220.101.47:443     ESTABLISHED   4812
 [svchost.exe]            <-- svchost making an OUTBOUND 443 to a hosting-range IP?
  TCP    10.20.3.17:8080      0.0.0.0:0              LISTENING      4812
 [svchost.exe]            <-- and listening on a non-standard port? two red flags
  TCP    10.20.3.17:445       0.0.0.0:0              LISTENING      4
 Can not obtain ownership information
  TCP    10.20.3.17:3389      10.20.3.9:51220        ESTABLISHED    1284
 [TermService]

Read that against your knowledge of normal: svchost.exe is a legitimate Windows process, but a genuine svchost does not normally open an outbound HTTPS connection to a bare IP in a hosting range, nor listen on :8080. The PID 4812 ties this socket back to the process whose suspicious command line and parentage you just captured — the two views corroborate each other. That 185.220.101.47 is your C2 address, the same one the EDR alert fired on, now confirmed at the host with an owning process attached.

On Linux, ss has superseded netstat; the flags -tunap give TCP and UDP, numeric, all states, with the owning process:

# ss -tunap
Netid State  Recv-Q Send-Q  Local Address:Port   Peer Address:Port    Process
tcp   ESTAB  0      0        10.20.3.41:51234     185.220.101.47:443   users:(("kworkerd",pid=2317,fd=7))
tcp   LISTEN 0      128      0.0.0.0:8080         0.0.0.0:*            users:(("kworkerd",pid=2317,fd=3))

Note the process name kworkerd — almost like the legitimate kernel worker threads named kworker/…, but those are kernel threads with no executable on disk and no network sockets. A user-space process masquerading as a kernel thread, owning a C2 socket, is textbook camouflage. Hold that name; the open-files step is about to expose it completely.

Logged-on users and sessions

Who is on the box, and who is connected to it? Capture both the interactive/remote logons and the network sessions. On Windows:

C:\> quser
 USERNAME       SESSIONNAME   ID  STATE   IDLE TIME  LOGON TIME
 svc_backup     rdp-tcp#3      3  Active  .          09/14 19:41   <-- a SERVICE acct
                                                                       logged in via RDP?
 administrator  console        1  Active  none       09/14 08:02

C:\> net session                 (inbound SMB sessions — who is connected TO us)
Computer            User name      Client Type   Opens  Idle time
\\10.20.3.9         svc_backup     Windows ...        2  00:00:11

An interactive RDP logon by svc_backup — an account that should only ever run a scheduled backup service, never sit at an interactive desktop — is the kind of anomaly that turns a "maybe" into a "yes, this host is compromised." Complement quser/query session with net session (inbound SMB) and, on Linux, w, who, and last -F (the last command shows the login history, including the attacker's source IP and times). Sysinternals psloggedon and logonsessions round out the Windows picture, and Kerberos ticket state via klist sessions can reveal lateral-movement footholds.

Open files, handles, and the deleted-but-open recovery

Now the step that ties three themes together at once. List the open file handles: which processes have which files open. This exposes what malware is reading and writing, which document a user has open, and — most beautifully — files that have been deleted from the directory but are still held open by a running process.

Recall theme one: deletion removes the pointer, not the data. On a live system there is an even stronger version. When a process has a file open and that file is then unlinked (deleted) from the directory, the operating system keeps the file's data fully intact on disk until the last handle closes — the directory entry is gone, but the bytes are alive and reachable through the running process. On Linux you find these with lsof +L1 (open files whose on-disk link count has dropped below one), and you recover them straight out of the kernel via the /proc file system:

# lsof +L1
COMMAND    PID  USER  FD  TYPE DEVICE SIZE/OFF NLINK    NODE NAME
kworkerd  2317  root  txt REG  253,0   245760     0  917501 /dev/shm/.x (deleted)
kworkerd  2317  root    4 REG  253,0   119284     0  917533 /tmp/.cfg (deleted)

There is kworkerd again — the fake "kernel thread" from the network step — and now it is fully unmasked: it is a user-space binary that deleted itself from disk after launching (a common anti-forensic move) but is still running and therefore still fully recoverable. NLINK 0 plus (deleted) is the signature. You recover the live malware binary, and the config it deleted, directly from the process's memory-backed file descriptors:

# Recover the deleted-but-running executable and its open config BEFORE the process exits:
cp /proc/2317/exe        /mnt/evidence/WEB07/recovered_kworkerd.bin
cp /proc/2317/fd/4       /mnt/evidence/WEB07/recovered_kworkerd.cfg
sha256sum /mnt/evidence/WEB07/recovered_* | tee -a /mnt/evidence/SHA256SUMS

The attacker deleted the file to leave no trace; the running process is the trace, and it hands you a perfect copy of the very evidence the deletion was meant to destroy. (On Windows the equivalents are Sysinternals handle.exe for open handles and psfile/net file for files opened over the network; openfiles /query exists but only works if the "maintain objects list" setting was enabled in advance, so do not rely on it.)

Recovery vs. Forensics. The deleted-but-still-open file is the purest dual-use artifact in the book. The 💾 recovery angle: a customer's developer runs rm on the production config file by accident, panics — but the service is still running and holding it open. Before anyone restarts anything, you cp /proc/<pid>/fd/<n> the live handle and hand back the "lost" file in thirty seconds, no carving, no downtime. The 🔍 forensic angle: a suspect's process holds open a now-deleted archive of stolen documents; you preserve that same handle as evidence the file existed and was in active use at the moment of capture, hashed and logged for court. One kernel mechanism — open file descriptors surviving unlink — serving an emergency restore and a criminal prosecution with equal grace.

Clipboard, ARP cache, and DNS cache

Round out the volatile collection with three small but high-value caches that vanish at power-off:

• Clipboard. Whatever the user last copied — a password, a destination path, a wallet address, a URL — sits in the clipboard until replaced. On Windows, Get-Clipboard (and Get-Clipboard -Format Image for a copied screenshot). In an insider case this single artifact has captured a soon-to-be-pasted exfiltration command in the act.
• ARP cache (arp -a on Windows; ip neigh on Linux) maps recently-contacted IPs to MAC addresses — a roster of who this host has talked to on the local segment in the last few minutes, including hosts that may be gone by morning.
• DNS resolver cache (ipconfig /displaydns on Windows; Get-DnsClientCache in PowerShell) lists the domain names this host recently resolved — frequently including the C2 or exfiltration domain before it rotated, even when the connection itself has already closed. The connection died; the cached name that birthed it lingers.

A PowerShell battery that captures these along with routing and network configuration, then hashes everything:

Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess |
    Sort-Object State | Export-Csv "$out\tcp.csv" -NoTypeInformation
Get-NetUDPEndpoint  | Export-Csv "$out\udp.csv"      -NoTypeInformation
Get-DnsClientCache  | Export-Csv "$out\dnscache.csv" -NoTypeInformation
arp -a              | Out-File   "$out\arp.txt"
Get-Clipboard       | Out-File   "$out\clipboard.txt"
quser           2>&1| Out-File   "$out\logged_on.txt"
route print         | Out-File   "$out\routes.txt"
Get-NetRoute        | Export-Csv "$out\netroute.csv"  -NoTypeInformation

Stop-Transcript
# Seal the whole collection with hashes, immediately:
Get-ChildItem $out -File | Get-FileHash -Algorithm SHA256 |
    Export-Csv "$out\HASHES.csv" -NoTypeInformation

The Linux equivalents — ip neigh, ip route, ss -tunap, w/who/last, lsmod, cat /proc/mounts — appear in the documented collector script below and in Appendix H. A consolidated artifact-location and command cheat sheet for all three operating systems lives in Appendix D.

Triage at scale: collecting the few artifacts that matter

Everything above is per-host live collection. But the breach that brought you in tonight rarely involves one host. The EDR alert that flagged WEB-07 also lit up forty other endpoints, and you have a thousand more you cannot rule out. Full-imaging a thousand 500 GB machines is 500 terabytes and weeks of work; it is not going to happen, and it would bury the actual investigation under noise. This is where the order of volatility meets operational reality and produces a distinct discipline: triage forensics.

The triage philosophy is simple. Most of an investigation's answers live in a small, predictable set of high-value artifacts — on Windows: the registry hives, the Windows event logs (.evtx), the $MFT` and NTFS journals (`$J/$UsnJrnl`, `$LogFile), Prefetch, Amcache, SRUM, scheduled tasks, and browser history. Together these are a few hundred megabytes, collectible in minutes per host. So instead of imaging everything, you collect the artifacts that matter from many hosts quickly, analyze them, and then select the handful of machines that warrant a full forensic image (Ch.14) or a deep memory analysis (Ch.22). Triage is how you turn "a thousand suspects" into "these six, image them" without spending your evidentiary budget on dead ends.

KAPE: targets and modules

KAPE (the Kroll Artifact Parser and Extractor, by Eric Zimmerman) is the de-facto Windows triage tool, and its architecture is worth understanding because it cleanly separates two phases. Targets define what to collect (described in .tkape files — e.g., RegistryHives, EventLogs, FileSystem, Prefetch, and the compound !SANS_Triage/KapeTriage targets that bundle dozens of these). Modules define what to run/parse (.mkape files that invoke parsers like MFTECmd, PECmd, RECmd). The critical operational rule: on a live subject you run Targets only — collect the artifacts to external media — and you run the Modules later, on your own workstation, against the collected copy. You do not run parsers on the subject; that is unnecessary execution on the evidence.

E:\kape> kape.exe --tsource C: --target KapeTriage ^
                  --tdest E:\evidence\WEB07\triage --vhdx WEB07

KAPE version 1.x   (running from removable media E:)
Loading targets... 'KapeTriage' is a compound target; expands to:
  RegistryHives, EventLogs, FileSystem($MFT,$J,$LogFile,$Boot,$T),
  Prefetch, Amcache, SRUM, RecentFileCache, ScheduledTasks, WMI,
  WebBrowsers, EventTraceLogs, SUM, LNKFilesAndJumpLists ...
Collecting (using VSS + raw NTFS reads for locked files)...
  C:\$MFT                                                  -> 487.3 MB
  C:\$Extend\$UsnJrnl:$J                                   ->  72.1 MB
  C:\Windows\System32\config\SYSTEM                        ->  copied
  C:\Windows\System32\config\SOFTWARE                      ->  copied
  C:\Windows\System32\winevt\Logs\Security.evtx           ->  copied
  C:\Windows\Prefetch\*.pf                                 ->  311 files
  ...
Total files copied: 4,812          Elapsed: 00:02:41
Container: E:\evidence\WEB07\triage\WEB07.vhdx
SHA256:    c4e1a90f7b2d6538e0c14af9d2b7e6103a5f8c9d0e1b2a3f4c5d6e7f8091a2b3

Two and a half minutes for the entire evidentiary heart of a Windows host. Note that KAPE reads locked system files (the registry hives and $MFT are open and locked while Windows runs) using Volume Shadow Copies and raw NTFS parsing — it gets the live files a normal copy cannot touch. Note also the output is a VHDX container: a single mountable virtual disk that preserves the original paths and timestamps, hashes as one object, and drops cleanly into your analysis workstation. (These Windows artifacts — what each hive, .evtx, Prefetch, and Amcache entry means — are the entire subject of Chapter 16; KAPE collects them, Chapter 16 interprets them.)

Tool Tip. Run KAPE itself from your removable media and send --tdest to that same external drive (or a network share), never to the subject's C:. The --vhdx %m form names the container after the machine, so a fleet sweep produces WEB07.vhdx, WS-014.vhdx, and so on without collisions. Resist the urge to add --module on the live box; collect now, parse later, on your own system.

CyLR: cross-platform collection to a single container

KAPE is Windows-only. CyLR (originally by Alan Orlikoski) is the cross-platform counterpart — a small .NET collector that runs on Windows, Linux, and macOS, grabs the OS-appropriate artifact set, and packages it into a single <hostname>.zip. Crucially for scale and for keeping the subject's disk pristine, CyLR can upload that archive directly to an SFTP collection server, so nothing is written to the subject's local storage at all:

$ sudo /mnt/ir/CyLR -o /mnt/evidence/WEB07
CyLR  Version x.x
Collecting artifacts:
  /var/log/auth.log, /var/log/syslog, /etc/passwd, /etc/shadow,
  /root/.bash_history, /home/*/.bash_history, /var/log/wtmp,
  /etc/crontab, /etc/cron.*, systemd unit files, ...
Creating archive: /mnt/evidence/WEB07/WEB07.zip
Done.

# Or stream straight to a collection server, writing NOTHING to the subject disk:
$ sudo /mnt/ir/CyLR -s 10.20.0.5 -u ir-collector -p '<token>'

For very large estates, the next step up is Velociraptor (Velocidex/Rapid7), which deploys a lightweight agent and lets you run triage collections — and live queries via its VQL language — across thousands of endpoints from one console, returning just the artifacts that match your hunt. Velociraptor, GRR, and the live-response consoles built into EDR platforms (CrowdStrike Real Time Response, Microsoft Defender Live Response) are how enterprise IR teams do volatile collection at fleet scale; the per-host concepts in this chapter are exactly what those consoles automate. The tool landscape is catalogued in Appendix C, and the broader toolkit in Chapter 36.

Why This Matters. Triage is the practical expression of theme five — know your limitations. You cannot image everything; pretending you can is how investigations stall and evidentiary budgets evaporate. Disciplined triage — collect the artifacts that matter from many hosts fast, then image the few that earn it — is not a compromise on rigor. It is the rigor, applied to scale. The examiner who insists on full images of all thousand hosts will still be acquiring when the incident is over and the attacker is long gone.

Documenting live actions for court

You have now altered a running system on purpose, repeatedly. The entire defensibility of that work rests on one thing: documentation so complete that an independent examiner could reconstruct exactly what you did, in what order, at what time, with what result. This is the through-line of the chapter and the reason live response intimidates people who learned dead-box discipline first. The good news is that defensibility is mostly mechanical — it is a logbook and a few good habits, not a talent.

A scripted, hashed, timestamped collector

The single best habit is to script your volatile collection rather than improvise it. A script runs the same commands in the same order every time (repeatable methodology — what a court wants to hear), records a UTC timestamp for each, captures each output to its own file, and hashes every file as it lands. The script becomes part of your discovery: this is exactly what I ran, here is the source, here is the manifest of what it produced and the hash of each item. Here is a compact, correct example you would carry on your toolkit media (Python because it is your primary forensic language in this book; the full reusable version lives in Appendix B):

#!/usr/bin/env python3
"""triage_logger.py — run a fixed battery of live-response commands, capture each
output to its own file, UTC-timestamp it, and hash it into a manifest.
ILLUSTRATIVE: review/adapt; point COMMANDS at TRUSTED binaries on your own media;
write OUT_DIR to EXTERNAL media only — never the subject's disk."""

import csv, hashlib, subprocess, sys
from datetime import datetime, timezone
from pathlib import Path

# (label, argv). Windows examples; swap for ps/ss/lsof/ip on Linux.
COMMANDS = [
    ("system_time",  ["cmd", "/c", "echo %DATE% %TIME%"]),
    ("processes",    ["wmic", "process", "get",
                      "ProcessId,ParentProcessId,CommandLine,ExecutablePath"]),
    ("connections",  ["netstat", "-anob"]),
    ("dns_cache",    ["ipconfig", "/displaydns"]),
    ("arp_cache",    ["arp", "-a"]),
    ("logged_on",    ["quser"]),
    ("net_sessions", ["net", "session"]),
    ("routes",       ["route", "print"]),
]

def sha256(path: Path) -> str:
    h = hashlib.sha256()
    with path.open("rb") as f:
        for chunk in iter(lambda: f.read(1 << 20), b""):   # 1 MiB chunks
            h.update(chunk)
    return h.hexdigest()

def main(out_dir: str, examiner: str) -> None:
    out = Path(out_dir)
    out.mkdir(parents=True, exist_ok=True)        # MUST resolve to EXTERNAL media
    with (out / "MANIFEST.csv").open("w", newline="", encoding="utf-8") as mf:
        w = csv.writer(mf)
        w.writerow(["label", "command", "utc_start", "utc_end",
                    "returncode", "output_file", "sha256", "examiner"])
        for label, cmd in COMMANDS:
            start = datetime.now(timezone.utc).isoformat()
            try:
                proc = subprocess.run(cmd, capture_output=True, timeout=120)
                rc, blob = proc.returncode, proc.stdout + proc.stderr
            except Exception as exc:               # tool missing / blocked, etc.
                rc, blob = -1, f"ERROR: {exc}".encode()
            end  = datetime.now(timezone.utc).isoformat()
            ofile = out / f"{label}.txt"
            ofile.write_bytes(blob)
            w.writerow([label, " ".join(cmd), start, end, rc,
                        ofile.name, sha256(ofile), examiner])
            print(f"[{end}] {label}: rc={rc} -> {ofile.name}")

if __name__ == "__main__":
    if len(sys.argv) != 3:
        sys.exit("usage: triage_logger.py <EXTERNAL_out_dir> <examiner_name>")
    main(sys.argv[1], sys.argv[2])

Be honest about the caveats, because an opponent will raise them: this script itself runs on the subject (it allocates memory and may invoke the subject's binaries unless COMMANDS is pointed at your trusted copies), so it is not footprint-free — nothing is. Its virtue is not invisibility; it is repeatability and self-documentation. It does the same thing every time and emits a manifest with UTC timestamps and per-file hashes, which is exactly the record you will want under oath.

The live-response log

Around the automated manifest sits a human live-response log — the chain-of-custody narrative of the engagement. Every significant action gets a row: UTC time, what you did, the tool/source, the output and its hash, and (where relevant) a witness. This is the document that gets entered into evidence and the document you read from on the stand:

LIVE-RESPONSE LOG  —  Case 2026-0428-IR     Host: WEB-07 (10.20.3.17, VM)
Examiner: J. Okafor, GCFA            Witness: M. Reyes, SOC lead
Authority: IR engagement letter §4 + written mgmt authorization (Exhibit A)
Clock note: subject clock = trusted NTP + 3.1 s  (recorded 02:15:02Z)

UTC time   Action                                           Tool / source       Output (SHA-256)
02:14:55   Photographed console (RDP session, user shown)   phone cam (Exh. B)  IMG_0413.jpg / 4b9c...
02:15:02   Recorded system clock vs. trusted clock          Get-Date / NTP      skew = +3.1 s
02:15:40   Isolated host via EDR (mgmt channel only)         Defender LR         (action logged in EDR)
02:16:30   Acquired physical memory, 16 GiB                  winpmem_mini 3.x    WEB07-mem.raw / a17f...
02:41:55   Captured volatile state (proc/net/dns/arp/users) triage_logger.py    MANIFEST.csv / 7b9d...
02:49:08   Recovered deleted-but-running binary (pid 2317)   cp /proc/2317/exe   kworkerd.bin / e7d2...
02:52:10   Triage artifact collection                       KAPE KapeTriage     WEB07.vhdx / c4e1...
03:05:20   DECISION: live-image C: (BitLocker UNLOCKED;      see decision memo   (rationale recorded)
           power-off would re-lock and lose volume)
03:06:00   Began logical image of mounted, decrypted C:      FTK Imager 4.x      WEB07-C.e01 / 9f3a...

Notice what that log demonstrates without saying it out loud: a deliberate order (memory before state before triage before disk), the two-clock problem solved in line two, the legal authority cited in the header, a witness present, a reasoned decision about acquisition strategy with its rationale preserved, and a hash on every artifact captured the moment it was created. That is what defensible live response looks like on paper. Templates for the live-response log and chain-of-custody forms are in Appendix F; the report that consumes them is Chapter 26, and defending it on the stand is Chapter 27.

Chain of Custody. Live response does not suspend chain of custody — it intensifies it, because there is no pristine original to fall back on. From the first photograph of the screen to the final hash of the disk image, custody of every artifact is unbroken and recorded: who created it, when (in UTC, with documented clock skew), with what tool, where it was stored, and who witnessed it. The artifacts you carry out — the memory image, the triage VHDX, the recovered binary, the volatile-state manifest — are now the originals you protect with Chapter 14's full rigor: hashed, sealed, and tracked. The system was a moving target; the evidence you extracted from it must not be.

Worked example: triaging WEB-07, and a laptop that was still unlocked

Pull the threads together on WEB-07. After isolating the host via EDR and solving the two-clock problem, you image memory first (WEB07-mem.raw, hashed a17f4c9e…). With memory safe, the live state confirms the picture: a kworkerd process masquerading as a kernel thread, owning the outbound 185.220.101.47:443 C2 socket and a :8080 listener, with lsof +L1 revealing it deleted its own executable after launch. You recover the live binary and its config straight from /proc/2317/ before the process can exit.

The decisive artifact, though, is in the memory image — and it illustrates why you fought so hard to capture RAM. The malware is packed on disk: the binary you recovered is encrypted/compressed and reveals nothing to strings. But a running program must decrypt itself to run, so its configuration sits in plaintext in memory. Carving the memory image for the C2 pattern lands on it:

$ xxd -s 0x1f3a2b40 -l 64 WEB07-mem.raw
1f3a2b40: 7b22 6332 223a 2268 7474 7073 3a2f 2f31  {"c2":"https://1
1f3a2b50: 3835 2e32 3230 2e31 3031 2e34 373a 3434  85.220.101.47:44
1f3a2b60: 332f 6761 7465 222c 2022 696e 7465 7276  3/gate", "interv
1f3a2b70: 616c 223a 3630 2c20 226b 6579 223a 2261  al":60, "key":"a
   |                                                  |
   +-- offset into the RAM image                      +-- ASCII rendering
       decrypted C2 config: address, /gate URI, 60-second beacon, embedded key

There is the whole confession in sixty-four bytes: the C2 address (matching the EDR alert and the live netstat), the /gate callback URI, the sixty-second beacon interval you first saw in the alert cadence, and an embedded key — none of which exists in plaintext anywhere on the disk. Power the box off and this evidence never existed. (Carving this systematically and reconstructing the malware's behavior from memory is Chapter 22; analyzing the recovered binary itself is Chapter 32. Tonight you captured and confirmed; the deep analysis is a daylight job on copies.)

Finally the strategy decision. WEB-07's C: is BitLocker-protected and currently unlocked. Powering off to do a clean dead-box image would re-lock the volume and you have no escrowed key. So you make — and record — the call to live-image the mounted, decrypted volume now (WEB07-C.e01), accepting the smear as a documented limitation, and you retain the memory image from which the BitLocker key can be recovered later if a dead-box image is ever taken. Two acquisitions, one reasoned decision, every step logged.

The insider angle, for contrast. Recall anchor case two — the employee suspected of stealing intellectual property before resigning (it threads Chapter 16, Chapter 21, and Chapter 30). Security walks to the employee's desk and finds the laptop powered on and logged in — a gift, and a trap. Reflexively closing the lid or shutting down would re-lock the BitLocker volume; the same encryption logic as WEB-07 applies to a workstation. Instead, the responder works the live volatile layer first: the clipboard holds a file path to a staged archive; open handles show that very archive open in an active process; netstat shows an established upload to a personal cloud-storage IP; and the DNS cache holds the cloud provider's domain. Then memory, then a KAPE triage, then a live image of the unlocked volume. The insider's later claim — "I never touched those files" — collides with a live capture showing the files open and uploading at the moment of collection, and with the $FILE_NAME MFT timestamps (Ch.16/21) that betray the timestomping the employee used to hide the activity. The lesson is the chapter's thesis in miniature: had they pulled the plug out of habit, the encrypted volume re-locks and the live proof — clipboard, open handles, active upload — is gone.

And the ransomware angle, for the recovery reader. When the live system is actively encrypting — the ransomware scenario of Chapter 12 — live response can change the outcome. Many ransomware families generate or hold their per-victim symmetric key in memory while they work. Capturing RAM before the process finishes and exits has, in real cases, let responders recover the encryption key and decrypt files no backup could restore. It is not reliable — many families purge keys aggressively or use schemes that defeat it — but it is a reason that, faced with encryption in progress, you do not always reflexively pull the plug: you weigh isolating-and-capturing memory against the bleeding, and you decide deliberately.

Ethics Note. During a live preview you are looking at a person's screen and files in real time, and you may see things outside your scope — personal, medical, intimate, or, in the worst case, clearly illegal content. The discipline is scope and stop: do not go rummaging beyond your authorization, and if you encounter apparent contraband, stop exploring, preserve and document what is in plain view, and escalate through the proper channel. Where that contraband is child-sexual-abuse material, U.S. law imposes specific preservation-and-reporting duties and forbids you from copying it except as the lawful process directs — handled clinically and never described, with the full legal and well-being treatment (including secondary trauma for the examiner) in Chapter 28. Behind the live host is a real person whose life this evidence may upend; theme six is never more present than when you are watching their desktop in real time.

Common mistakes

• Pulling the plug on an encrypted, unlocked system. The single most expensive error in modern live response. Power-off re-locks BitLocker/FileVault/LUKS/VeraCrypt; without an escrowed key your lawfully seized drive becomes ciphertext. If the running volume is unlocked, capture memory (which holds the key) and consider a live image before anyone touches the power.
• Running tools, then imaging memory. Every command you run pollutes RAM and can evict the attacker's data before your imager reaches it. Image memory first; reconstruct process and network state from the image afterward. The cheap live netstat is corroboration, not a substitute for the memory it displaced.
• Trusting the subject's binaries. A rootkit hooks netstat, ps, tasklist, and ls to hide itself. Run statically-linked trusted tools from your own read-only media, and use the cross-view difference to expose what the subject's tools omit.
• Writing output to the subject's disk. Saving your collection to the subject's C: overwrites the unallocated space and slack you may need to carve later — you destroy evidence to collect evidence. Always write to external media or stream off-box over the network.
• Capturing process names instead of command lines and parentage. A malicious process named svchost.exe is invisible by name; it is exposed by its non-standard parent and its command line. Collect PID, PPID, full command line, and image path, or you have collected nothing useful.
• Forgetting the two-clock problem. Timestamps anchored to an unverified, possibly-skewed subject clock can be attacked wholesale. Record subject time against an authoritative external time, and the skew, as your first logged action.
• Improvising the collection. Ad-hoc typing is unrepeatable and hard to defend. Script the volatile battery so the methodology is identical every time and self-documents into a hashed, timestamped manifest.
• Treating triage as second-rate. Insisting on full images of every host when triage would answer the question wastes the investigation's time and budget. Triage many, image the few that earn it.
• Not hashing immediately. A hash computed hours later, after the artifact has sat on a thumb drive, proves far less than one computed the instant the artifact was created. Hash on completion, in the log, every time.

Limitations: knowing when to stop

Live response is the most powerful tool in this book and the most honestly limited. Hold all of these in view.

You cannot capture without altering. There is no zero-footprint observation of a running system — the memory imager itself overwrites memory; your commands leave Prefetch and shell-history traces; the network stack changes as you work. Live evidence is inherently contaminated by collection in a way dead-box evidence is not. You manage this with minimization and documentation; you do not eliminate it.

A live image is never reproducible. The smear is physics, not error. You cannot re-acquire WEB-07 and match the hash, because the system lived in between. Your hash proves integrity from acquisition forward, not faithful single-instant copying. Say so before you are asked.

Memory may not hold what you hoped. Keys get purged, malware unmaps its plaintext, pages get swapped to disk or zeroed under memory pressure. A memory capture is a snapshot of a heaving sea; sometimes the wave you wanted has already passed. The ransomware key in RAM is a possibility, not a guarantee.

You can collect more than you can defend. It is easy, mid-incident, to wander beyond your legal authority or your scope. The constraint is not technical capability but warrant scope, consent, engagement terms, and ethics (Ch.25, Ch.28). "I could have looked" is not "I was authorized to look."

Triage is sampling, and samples miss things. Collecting the high-value artifacts from a thousand hosts in minutes is the right call at scale, but a clever attacker can hide in the artifacts you did not collect. Triage tells you where to look deeper; it does not promise that a host it cleared is truly clean. When triage says "image this one," believe it; when it says "nothing here," hold that conclusion loosely.

Sometimes the right move is still to pull the plug. If the volume is unencrypted, there is no active connection worth preserving, no key in memory you need, and a real risk that a shutdown-triggered wiper will destroy the disk, the old advice wins: yank the power and image dead-box. The skill is not "always go live"; it is choosing, deliberately and on the record, between live and dead-box for the case in front of you.

Knowing when to stop — when memory has given what it will, when triage has pointed you to the hosts that matter, when the legal scope ends, when "the volatile evidence is insufficient to reach a conclusion" is the honest finding — is as much a part of mastery as knowing how to start.

Progressive project: triage the live system and decide the acquisition strategy

Your Forensic Case File so far contains the assignment, your dead-box acquisition plan, and the hash-verified image work from Chapter 14. Now the case escalates: the subject machine in your investigation is reported found powered on and logged in, with an unknown encryption posture and a suspected active network connection. Add a complete live-response package to the case file.

1. State your authority and the two clocks. Open a live-response log (template in Appendix F). Record the legal/engagement basis for acting live, then record the subject's system time against an authoritative external time and note the skew. These are log lines one and two.
2. Write the acquisition-decision memo (the heart of this step). In one page, decide live vs. dead-box and justify it against this specific machine: Is the volume encrypted and unlocked (live-image or lose it)? Is there volatile evidence — an active connection, a key in RAM, a deleted-but-open file — that power-off destroys? Is there wiper/dead-man risk that argues for a fast power-off after volatile capture? State the order you will collect in, and why. There is no single right answer; there is a defensible, documented answer.
3. Capture in volatility order. Image memory first (WinPmem/AVML/DumpIt, or a hypervisor snapshot if it is a VM), hashing immediately. Then run a scripted volatile battery (adapt triage_logger.py) capturing processes-with-command-line-and-PPID, network connections, logged-on users and sessions, open files (including lsof +L1 / handles), clipboard, ARP, and DNS cache — to external media only.
4. Run a triage collection. Use KAPE (KapeTriage target → VHDX) on Windows or CyLR on Linux/macOS to grab the high-value artifacts to a single container. Do not run parsers on the subject; collect now, parse in later chapters.
5. Seal and log everything. Hash every artifact at creation, enter each in the live-response log with UTC timestamps, and add the decision memo, the log, the manifest, and the artifact hashes to your case file. If you recovered a deleted-but-open file or carved a config from memory, document the recovery path.

Deliverable for the case file: a live-response log, an acquisition-decision memo, a volatile-state collection with manifest and hashes, and a triage container — the evidence base the analytical chapters (16–24) will mine, and that the capstone in Chapter 38 assembles into the final report.

Summary

This chapter took you off the clean workbench of dead-box acquisition and into the field, where the machine is running, time is short, and the richest evidence is the most perishable. You learned the order of volatility (RFC 3227) — registers and cache, then live state and RAM, then temp file systems, then disk, then remote and archival storage — and why it dictates collecting memory before the disk that physically dwarfs it: RAM dies at power-off, while the deleted data on disk waits for years. You confronted the modern pressures that make "pull the plug" sometimes catastrophic — full-disk encryption that re-locks on shutdown, production services and shutdown-triggered wipers, and cloud-tethered, ephemeral state — and the modern answer of isolating rather than powering off. You weighed live imaging against dead-box imaging, internalizing the smear (a live image is a blurred, non-reproducible composite) and the shifted meaning of the hash (integrity from acquisition forward, not bit-for-bit reproducibility). You worked the concrete collection sequence — establishing a trusted toolkit and solving the two-clock problem, then capturing memory, processes with their lineage, network connections, sessions, open files (and the deleted-but-open recovery that hands you a self-deleting malware binary straight from /proc), clipboard, ARP, and DNS caches. You scaled up with triage — KAPE's targets-and-modules, CyLR's cross-platform containers, Velociraptor and EDR consoles for the fleet — collecting the few artifacts that matter from many hosts in minutes, then imaging only the ones that earn it. And throughout, you built the spine of defensibility: a scripted, hashed, timestamped collector and a witnessed live-response log that can account for every byte you changed. Above all, you saw the chapter's thesis proven: the original is still sacred even when you must touch it — reverence simply becomes a logbook instead of a write-blocker.

You can now: - Apply the order of volatility (RFC 3227) to sequence a live collection, and explain why memory generally precedes disk. - Recognize when powering off would destroy evidence — encrypted-and-unlocked volumes, keys in RAM, active connections, wiper risk — and choose, on the record, between live and dead-box acquisition. - Capture volatile data soundly: memory, processes with command line and parentage, network connections, sessions, open files (including deleted-but-open recovery), and the clipboard/ARP/DNS caches, using trusted tools written off-box. - Run targeted triage collection at scale with KAPE and CyLR, and decide which hosts merit full imaging. - Articulate the smear and the shifted meaning of a hash for a live image, and disclose both proactively. - Produce a defensible live-response record — scripted collector, manifest, and witnessed log with UTC timestamps and per-artifact hashes — that survives cross-examination.

What's next. Chapter 16 — Windows Forensics — takes the registry hives, event logs, Prefetch, Amcache, LNK files, and $Recycle.Bin you just collected with KAPE and teaches you to read them: the artifacts that reconstruct what a user did, when, and with which devices — and that quietly expose the employee who thought they covered their tracks.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies (one, two), review the key takeaways, and go deeper with further reading.