Chapter 15 — Exercises
A mix of concept checks, hands-on labs ("capture this," "interpret this output," "build the log," "calculate and verify the hash"), and judgment calls — because live response is at least as much decision as technique, and the decisions are made under time pressure with no answer key in the room. (answer in Appendix) = worked solution in Answers. ⭐ = stretch. Do every lab on your own workstation — never a production or evidence machine — and write all captures to external media so you practice the off-box discipline from the start. Practice memory images and live-response VMs are catalogued in Appendix J.
Group A — The order of volatility
The order of volatility is the spine of the chapter: when you cannot collect everything at once — and on a live box you never can — you collect in order of how fast each thing disappears.
15.1 List the tiers of RFC 3227's order of volatility from most to least volatile, and give one concrete artifact for each tier. Then answer two follow-ups: (a) what single decision is the ladder designed to make easy under pressure, and (b) what does "collect top-down" actually mean for the sequence of tools you run? (answer in Appendix)
15.2 Disk unallocated space can hold the deleted files that make or break a case, yet it sits near the bottom of the order of volatility. (a) Explain why that placement is correct. (b) Tie your answer to the theme deleted ≠ destroyed. (c) Name one thing you, the responder, could do that would suddenly move unallocated space up the urgency list by threatening to overwrite it.
15.3 A colleague argues: "The process table is tier 2 and full RAM is tier 3, so I should always capture the process list before I image memory." (a) Lay out the two legitimate schools of thought on what to grab first. (b) Critique the colleague's reasoning specifically — what does each tasklist/netstat actually cost you against fileless malware? (c) Identify the one condition under which a quick netstat/ss snapshot before the memory image is genuinely justified, and explain why it is the exception rather than the rule.
15.4 ⭐ Tier 1 — CPU registers and L1/L2/L3 cache — is, for practical purposes, uncapturable by software running on the same CPU. (a) Explain why, in terms of what a capture tool must execute and what that execution does to the very state it is trying to read. (b) Name one situation in which a hypervisor or specialized hardware (e.g., a snapshot from outside the guest) can capture state that in-guest software cannot, and explain why the observer effect is smaller there.
Group B — When (not) to pull the plug
For most of forensic history the advice was blunt: pull the plug. Four modern realities can turn that reflex into the worst decision of the investigation.
15.5 For each system below, state whether your default is (a) pull the plug, (b) graceful shutdown, or (c) do not shut down — capture live — and justify each in one sentence: (answer in Appendix) - (i) a desktop, powered on, volume unencrypted, no active network connections, but a credible risk of a shutdown-triggered wiper; - (ii) a laptop, powered on and logged in, BitLocker volume currently unlocked, no escrowed recovery key; - (iii) a production database server mid-transaction, suspected compromise, EDR host-isolation available; - (iv) a kiosk PC, powered on, unencrypted, no network, no evidence of compromise, where you simply need a clean image for a routine HR matter.
15.6 A first responder is about to "just close the lid" of a suspect's running, logged-in laptop to transport it safely. (a) Describe concretely what may happen to the evidence between the desk and the lab if the volume is encrypted. (b) Write the ordered list of what they should do instead, from the moment they see the unlocked screen. (c) Explain why "I didn't touch anything, I just closed the lid" is not the careful, conservative act it feels like.
15.7 Define the containment-versus-preservation tension in your own words. (a) Explain why EDR host isolation resolves it better than physically yanking the network cable. (b) Name two EDR products from the chapter that can isolate a host while keeping it reachable for collection. (c) State what the fallback is when EDR isolation is not available, and the one thing you must do before you take that fallback.
15.8 ⭐ A workstation is enrolled in mobile device management (MDM), holds OAuth tokens and session cookies in memory, and has a cloud drive mounted with placeholder (online-only) files. Identify three distinct ways that either pulling the network cable or leaving it connected could destroy or alter evidence, then propose a collection sequence that minimizes the combined risk. Note which evidence will require a separate legal process to reach, and which chapter owns that topic.
Group C — Live vs. dead-box, and the smear
A dead-box image is a sharp photograph of a still subject. A live image is a long-exposure photograph of a moving one — it comes out blurred, and that blur has consequences you must disclose.
15.9 Explain "smearing" in a live image in your own words. (a) Walk through why it happens, using a concrete example of two sectors captured forty minutes apart from a system that kept writing. (b) Explain why a live image can never be re-acquired to the same hash. (c) Contrast this, point-by-point, with a dead-box image (single point in time, reproducible hash, equality proof).
15.10 A dead-box image and a live image are each hashed with SHA-256. For each, state precisely what the hash proves and does not prove. (a) Why is "integrity from the moment of acquisition forward" the correct, defensible claim for a live image? (b) Why is "bit-for-bit copy of the original" not a claim you can make for it? (c) Why does disclosing this limitation first, in your report, strengthen rather than weaken your position? (answer in Appendix)
15.11 (Calculate.) During analysis you find the decrypted C2 configuration at offset 0x1f3a2b40 in the 16 GiB WEB07-mem.raw image. (a) Convert the offset to decimal bytes. (b) Express it in MiB into the image. (c) Approximately what percentage of the way through the 16 GiB image is it? (d) If you captured the host's memory again five minutes later, would the same config appear at the same offset? Explain in one sentence. Show your arithmetic.
15.12 (Verify the hash.) At capture, WEB07-mem.raw was hashed SHA-256 = a17f4c9e…2c4. A week later you recompute the hash of the same image file and get the identical value — but a fresh memory capture of the (since-rebooted) host gives a different hash. (a) Explain why both results are exactly what you should expect. (b) State what each one does and does not prove about integrity. (c) A junior colleague says "the different hash means someone tampered with the evidence." Correct them in one or two sentences.
Group D — Capturing volatile data
Two ground rules are absolute throughout: run trusted tools, and write output off the box.
15.13 (Lab.) On your own workstation, capture physical memory with a free imager — WinPmem on Windows or AVML on Linux — writing the image to an external drive, and hash it immediately. Capture a second image and hash that. (a) Record both hashes and explain the difference in one sentence. (b) Identify, from your imager's own output, the footprint it announced (e.g., a driver loading, a temp file written). (c) What chapter principle have you just demonstrated in your fingers? (d) Now time the capture and note the image size against your installed RAM — if the image is meaningfully smaller than physical RAM, give one reason that is normal (hint: reserved/memory-mapped device ranges) rather than evidence of a failed capture. (answer in Appendix)
15.14 (Interpret tool output.) You run a trusted netstat -anob on the live host and see:
Proto Local Address Foreign Address State PID
TCP 10.20.3.17:49774 185.220.101.47:443 ESTABLISHED 4812
[svchost.exe]
TCP 10.20.3.17:8080 0.0.0.0:0 LISTENING 4812
[svchost.exe]
TCP 10.20.3.17:3389 10.20.3.9:51220 ESTABLISHED 1284
[TermService]
(a) Identify two red flags attached to PID 4812 and explain what is anomalous about each, given how a genuine svchost.exe behaves. (b) How does PID 4812 let you corroborate this network view against the process view you captured separately? (c) The :3389 line is a remote-desktop session from 10.20.3.9 — name one other volatile artifact you would check to decide whether that session is also suspicious, and why.
15.15 (Interpret tool output and recover.) On a Linux host your trusted lsof +L1 returns:
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)
(a) What does NLINK 0 plus (deleted) tell you? (b) Why is the data still recoverable even though the directory entries are gone? (c) Why is the process name itself a clue — what is it imitating, and how does that line up with the earlier netstat? (d) Write the exact commands to recover the running binary and its open config out of /proc before the process exits, and to hash what you recovered into the evidence manifest.
15.16 (Interpret tool output — sessions.) You run a trusted quser and net session on the Windows host:
C:\> quser
USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME
svc_backup rdp-tcp#3 3 Active . 09/14 19:41
administrator console 1 Active none 09/14 08:02
(a) Which logon is the anomaly, and why is who the account is supposed to be the key to spotting it? (b) What does an interactive RDP session by this account suggest about the stage of an intrusion? (c) Name two additional commands (Windows or Linux) you would run to capture the history of logons, not just the current ones, and say what last -F adds that quser cannot.
15.17 (Lab / judgment — trusted toolkit.) (a) Name five binaries you would carry, statically linked, on read-only media for a Linux live response, and explain in one sentence why "statically linked" matters on a possibly-compromised host. (b) Explain in one sentence why you cannot trust the subject's own copies. (c) Describe the cross-view difference technique step by step and state exactly what a discrepancy between the two views proves — and why that ties to the theme the absence of a trace is itself a trace.
15.18 (Calculate — the two-clock problem.) At one instant, a host's system clock reads 19:43:00 local while your synced phone reads 23:39:54Z. The host is configured for UTC-04:00. (a) Compute the host-derived UTC. (b) Compute the skew relative to true UTC and state whether the subject clock is fast or slow, in seconds. (c) Write the single log line you would record as the engagement's clock note. (d) In one sentence, explain why this must be your first or second logged action rather than something you reconstruct later.
15.19 ⭐ (Lab — the small caches.) Capture the three caches the chapter highlights — clipboard, ARP cache, DNS resolver cache — on your own machine, using the OS-appropriate commands for both Windows and Linux. Your DNS-cache capture will look something like this:
PS C:\> Get-DnsClientCache | Select-Object Entry,RecordName,Data | Format-Table
Entry RecordName Data
----- ---------- ----
cdn.example.com cdn.example.com 203.0.113.44
gate.bad-c2.example gate.bad-c2.example 185.220.101.47 <-- resolved, now idle
(a) Write the exact command for each cache on each OS. (b) For each cache, state one investigative question it can answer after the network connection that produced it has already closed. (c) Which of the three most often still contains a C2 or exfiltration domain name even when the connection itself is long gone, and why? (d) In the sample above, the connection to 185.220.101.47 has already closed — explain what the lingering cache entry still proves and how it corroborates a netstat that no longer shows the socket.
Group E — Triage at scale
The breach that brought you in rarely involves one host. Full-imaging the fleet is not going to happen; triage is how you turn "a thousand suspects" into "these six, image them."
15.20 An EDR alert lights up 40 endpoints, and you cannot rule out 1,000 more. (a) Estimate the raw storage and the rough time cost of full-imaging 1,000 machines at 500 GB each. (b) In three or four sentences, explain why disciplined triage is "the rigor applied to scale," not a shortcut, and what triage actually decides for you. (c) Name the failure mode of the examiner who insists on full images of all 1,000 hosts. (answer in Appendix)
15.21 Explain KAPE's Targets vs. Modules split. (a) Define each. (b) Why do you run Targets only on a live subject and run Modules later on your own workstation? (c) Name five artifact types bundled in the KapeTriage compound target. (d) State two advantages of the VHDX output container over a loose folder of copied files. (e) KAPE reads files that are locked while Windows runs (the registry hives, $MFT) — by what two mechanisms does it get them?
15.22 (Lab.) (a) Write the KAPE command line to collect the KapeTriage target from C: on host WS-014 to external drive E:, producing a VHDX named after the machine — and state where you would not send --tdest, and why. (b) Write the CyLR equivalent for a Linux host that streams the collection to an SFTP collector without writing anything to the subject's disk. (c) Why must you resist the urge to add --module to the live KAPE run? (d) After collection, KAPE reports a SHA-256 for the WS014.vhdx container — what do you do with that hash immediately, and what does it let you prove three months later when you mount the container for analysis?
15.23 ⭐ Walking KAPE to each box does not scale to a 5,000-endpoint estate. (a) Name the class of tool that does, and give one concrete example from the chapter. (b) Explain how an agent-based collector changes the live-response workflow. (c) Show that the same per-host concepts from this chapter (trusted collection, off-box output, hashing on completion) still apply — just automated — rather than being replaced.
Group F — Documentation and defensibility
The entire defensibility of live work rests on documentation so complete that an independent examiner could reconstruct exactly what you did, in what order, at what time, with what result.
15.24 (Build the log.) Reconstruct a live-response log — header plus at least six rows — for a hypothetical engagement. Include: stated legal/engagement authority in the header, the two-clock line, EDR isolation, memory capture with its hash, the scripted volatile collection with a manifest hash, and a recovered deleted-but-open binary with its hash. Use UTC timestamps and the column layout from the chapter (UTC time · action · tool/source · output + SHA-256). (answer in Appendix)
15.25 (Write the memo.) Draft a one-paragraph acquisition-decision memo for a laptop found powered on with an unlocked, un-escrowed BitLocker volume and a suspected active upload in progress. (a) State your decision (live vs. dead-box). (b) State the order in which you will collect. (c) Give the specific reason power-off is the wrong first move on this machine. (d) Name the one artifact whose capture would still let a dead-box image be decrypted later if you took one.
15.26 Critique this claim: "Scripting the collection makes it footprint-free." (a) Separate what is true from what is false. (b) Name the two virtues a scripted collector actually provides that ad-hoc typing cannot. (c) Explain why those two virtues are exactly what a court wants to hear, in the language of "repeatable methodology."
15.27 ⭐ (Cross-examination drill.) Opposing counsel says: "You admit you changed the evidence with your own commands, and that your memory image can never be reproduced. Why should this jury trust any of it?" Write a 4–6 sentence answer that (i) concedes what is genuinely true, (ii) distinguishes the system you altered from the evidence you extracted, (iii) grounds your method in a published standard, and (iv) explains how your contemporaneous log distinguishes your footprints from the intruder's. (Testimony craft is Chapter 27.)
Group G — Progressive project: triage and decide the acquisition strategy
15.28 Your Forensic Case File already holds the assignment and the Chapter 14 dead-box plan. The subject machine is now reported found powered on and logged in, encryption posture unknown, with a suspected active network connection. Open a live-response log (template in Appendix F), record your authority and the two clocks as lines one and two, then write the one-page acquisition-decision memo: live vs. dead-box, the order you will collect in, and why, argued against this specific machine. Remember the chapter's thesis — there is no single right answer, only a defensible, documented one.
15.29 Capture in volatility order. Image memory first (WinPmem/AVML/DumpIt, or a hypervisor snapshot if it is a VM), hashing immediately. Then run an adapted triage_logger.py (from Appendix B) 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 — all to external media. Finally run a KAPE (KapeTriage → VHDX) or CyLR triage container. Add the manifest and per-artifact hashes to the case file. Do not run parsers on the subject. Note in your log which command pointed at your trusted binary versus the subject's, and why that distinction matters.
15.30 ⭐ Seal, log, and stress-test. (a) Assemble the live-response log, the decision memo, the volatile-state manifest, and the triage container into the case file. (b) Write a half-page reflection naming the single artifact you would defend hardest on the stand and why. (c) Identify one thing about your collection an opposing expert could attack, and write the exact sentence you would use to take that attack off the table proactively in your report. (d) Note where each piece feeds the capstone in Chapter 38.
Self-check. You have mastered this chapter when you can (1) sequence a live collection by volatility and say why memory comes before the disk that dwarfs it; (2) look at a running, logged-in, possibly-encrypted machine and choose — on the record — between live and dead-box without flinching; (3) capture memory, lineage-aware process state, network state, sessions, and the deleted-but-open file soundly, writing every byte off-box and hashing on completion; and (4) hand a stranger your live-response log and have them reconstruct exactly what you did, when, and with what result. If any of those four still feels improvised rather than disciplined, redo Groups D and F before moving on. Next, Chapter 16 — Windows Forensics teaches you to read the registry hives, event logs, and Prefetch you just collected.