What can a live capture of a running host give you that an offline disk image cannot?
answer
- two captures, two different sources
- what never touched the disk
- an unlocked volume's key location
- one is repeatable, one is not
basics
~20 sOnly a running host still holds decryption keys, decrypted mounted volumes, running processes and network state in memory. Power it off and an image of the same disk is ciphertext, or silent, for all of it.
solid answer
~50 sA dead capture means powering the machine off and imaging the storage as an inert object: a stable source you can protect from writes, examine repeatedly, and read in full including unallocated space, file slack and deleted remnants. What it cannot give you is anything that only ever existed in RAM. On a full-disk-encrypted laptop that is most of the case - the volume key exists in memory only while the volume is unlocked, so once power goes the image is ciphertext unless someone holds an escrowed recovery key. The same is true of any container the user mounted: its plaintext is reachable through the mount point only while it is mounted. Live capture also holds process state, loaded modules and open sockets that were never written to disk. The price is that it perturbs the host and is a single observation nobody can repeat.
go deeper
Be ready to name what exists only in RAM — decryption keys, decrypted mounted volumes, running processes, network state — and to say plainly that powering the machine off destroys all of it.
Explain why an image of a full-disk-encrypted machine is ciphertext without a key, and what the dead capture buys in exchange: a fixed source you can protect from writes and read below the filesystem.
Show that you decide per case rather than by habit, and that you treat a live capture as a single unrepeatable observation whose footprint you document while you make it.
Own the standing position: which parts of the estate justify a live-response capability at all, and what evidence loss the organisation knowingly accepts where the answer is reimage and move on.
## The two acquisitions A **dead** (static, offline) acquisition means the machine is powered off and its storage is treated as an inert object. You attach the drive — or the whole machine in an offline boot — to an examination setup, read it end to end, and work from the copy. A **live** acquisition means collecting from the machine while it is still running: memory, process state, network state, and files that are only reachable through the running operating system. These are not two flavours of the same thing. They see different worlds, and choosing one closes the door on part of the other. ## What only the running machine holds **Encryption keys.** This is the decisive one on modern endpoints. Full-disk encryption — BitLocker, FileVault, LUKS — protects the volume at rest. While the volume is unlocked, the key that decrypts it is a structure in RAM. Cut the power and that structure is gone; the disk image you take afterwards is ciphertext. On a corporate laptop this is usually survivable, because corporate deployments escrow a recovery key to Active Directory, Entra ID or an MDM, and you can unlock the image later. What is *not* survivable is encryption the user chose themselves: a container mounted with a passphrase that was never escrowed anywhere. When that key dies with RAM, the contents are unreadable forever, no matter how perfect the image is. **Mounted plaintext.** A mounted container or network share presents plaintext through a mount point. Copy the files out while it is mounted and you have them; image the disk after power-off and you have an encrypted blob. **Process and network state.** Running processes, their loaded modules, their command lines, and the sockets they hold exist as kernel and user-space structures. Code that was injected into another process and never touched the filesystem exists nowhere else at all. **Things deliberately never written down.** Credentials in memory, decrypted configuration, staged data assembled in RAM before transfer. ## What only the powered-off disk gives you **A source that stops moving.** A dead capture can be protected against writes at the source and re-imaged; two acquisitions of the same drive produce the same result. That reproducibility is the reason dead capture was the default for decades. **Everything below the filesystem.** A live logical collection walks the filesystem through the running OS and sees files the OS is willing to show it. An image of the whole device includes unallocated clusters, file slack, deleted-file remnants, shadow copies and partitions the OS never mounted. **No footprint you have to explain.** A live collection runs code on the machine and leaves traces of itself. A dead acquisition does not. ## Why 'live capture changes the machine' is not a disqualifier The common misconception is that a live acquisition is somehow inadmissible or unsound because it alters the host. It is not. Live acquisition is routine and accepted; the standard is that the alteration is minimised, understood and *documented*, not that it is absent. What actually destroys the value of a live capture is an undocumented one — nobody can then separate the responder's artefacts from the intruder's, and any confident claim about the timeline becomes contestable. The honest framing of the trade is: a live capture buys you evidence that will otherwise cease to exist, and costs you reproducibility plus a footprint you must account for. A dead capture buys you a fixed, complete, repeatable source, and costs you everything that lived only in memory. ## In practice it is rarely either/or On a running machine you believe is compromised, the usual answer is *both*: collect from the live system first, then power it off and image the storage. The sequencing question is what separates responders — every second the machine stays up is a second the running state is still available and also a second in which it keeps changing. But the decision that governs everything else is the one this question asks: know what each acquisition can and cannot ever give you, so that pulling the power is a choice with a known cost rather than a reflex that quietly ends the case.
- If the laptop uses BitLocker and the image is ciphertext, is the case over?Usually not. Corporate full-disk encryption normally escrows a recovery key — BitLocker to Active Directory or Entra ID, FileVault to an MDM — so the volume can be unlocked from the image afterwards. What is genuinely unrecoverable is encryption the user chose themselves: a container mounted with a passphrase nobody escrowed dies with RAM, which is why its mounted plaintext is the thing you race for.
- What does a dead capture give you that a live one does not?A source that stops changing. You can protect it from writes, acquire it twice and get the same result, and reach unallocated space, file slack and deleted remnants that a live collection walking the filesystem never sees. A live capture is an observation of a moving system; a dead one is a repeatable examination of a fixed object.
- Does running a collection tool on the host make the evidence unusable because you changed it?No. Live acquisition is routine and accepted; the requirement is that the change is minimised and documented, not that it is absent. What sinks a live capture is an undocumented one, because nobody can then tell your artefacts apart from the intruder's and every claim you make about the timeline becomes arguable.
A dead capture is a photograph of an office after everyone has gone home. A live capture is walking through it while people are still working: you see the open doors and the conversations that vanish when the lights go out, but you cannot take the same walk twice.
saying these in an interview costs you the question
- Says a disk image contains everything memory does
- Assumes imaging the disk defeats full-disk encryption
- Thinks a live capture is inadmissible because it modifies the host
- Treats a live collection as something you can simply redo
- Believes a locked screen means the volume is locked