Case Study 1 — The Drive That Locked Itself

A corporate fraud investigation hinged on a single laptop — found powered on, logged in, and fully readable. A well-trained responder, acting on a decade-old reflex, shut it down "to transport it safely." By the time it reached the lab, the most valuable evidence in the case had become an unreadable wall of ciphertext. Nothing was wrong with the responder's intentions; everything was wrong with the procedure.

Background

A mid-sized logistics company suspected its accounts-payable manager of routing payments to shell vendors. Internal audit had a paper trail pointing at the manager's corporate laptop: spreadsheets, a personal email client, and a vendor-management application thought to hold the smoking-gun records. The company engaged an outside examiner and, in parallel, sent a junior corporate-security analyst to secure the device while the examiner was still two hours away.

The analyst found the laptop powered on and logged in at the manager's desk, screen unlocked, the vendor application open. By every measure that mattered, the evidence was right there and readable. The analyst had been trained well — for 2014. The training said: secure the device, do not poke around (you might alter timestamps), and bring it in for proper imaging. So the analyst did the careful, conscientious thing. They performed a graceful shutdown "to avoid corrupting anything," bagged the laptop, logged it into evidence, and waited for the examiner.

The fatal detail: the laptop's system volume was protected by BitLocker with a TPM-plus-PIN protector. The company's policy was supposed to escrow recovery keys to Active Directory — but a Group Policy misconfiguration eight months earlier had silently stopped the backup. This machine's recovery key existed nowhere the company could reach it.

The TPM-plus-PIN configuration is the cruelest version of this trap. The Trusted Platform Module will release the Full Volume Encryption Key only to the same physical machine, and only after the correct PIN is entered at boot — so the key cannot be extracted from the chip, and it never leaves the host. While the manager was logged in, the OS held that key in RAM and decrypted every read transparently; the analyst was looking at plaintext all afternoon without realizing the plaintext existed only because the machine was on. Nothing about the unlocked screen advertised that a power cycle would seal it shut.

What happened

When the examiner attached the drive through a write-blocker and tried to acquire it, the tooling reported the volume as encrypted and locked. The acquisition still succeeded — a write-blocker happily images ciphertext — but the resulting .e01 was exactly that: a 512 GB block of high-entropy bytes.

EXAMINER LOG — excerpt
14:20  Imaged subject SSD via write-blocker -> SUBJECT-AP.e01  (SHA-256 verified)
14:41  Mounted image for analysis.
       Volume 2 (480 GB): BitLocker, status LOCKED.
       Entropy ~7.99 bits/byte across sampled regions -> ciphertext.
14:48  Attempted unlock:
         - recovery key in Active Directory ........ NOT FOUND (escrow broken)
         - TPM-bound FVEK ......................... unavailable (off-host)
         - user PIN ............................... unknown
         - memory image (FVEK recoverable) ........ NONE CAPTURED (host powered off)
       CONCLUSION: volume not decryptable with available material.

The image was lawfully obtained, perfectly hashed, and completely useless. The Full Volume Encryption Key that had been sitting in the laptop's RAM — transparently decrypting every read the manager made all day — was purged the instant the analyst clicked Shut down. The TPM would only release the key to the same machine after a successful PIN entry, which no one had. There was no escrowed recovery key. And no one had captured memory, so there was no image from which a tool like bulk_extractor, Elcomsoft Forensic Disk Decryptor, or Passware could recover the key later.

What followed was a scramble that only confirmed the loss. The examiner queried Active Directory for the recovery key and found the escrow blank. They asked IT to check Microsoft Entra (Azure AD) and the MDM console — nothing; the policy break had affected both. They considered compelling the manager to produce the PIN, but that raised Fifth Amendment questions a civil investigation could not resolve quickly, and the manager, now represented, declined. They even checked whether a printed recovery-key sheet had been filed during deployment; it had not. Every avenue led back to the same wall: the only copies of the key that had ever mattered lived in the TPM (bound to a machine no one could unlock) and in the RAM (gone). The image sat in the evidence locker as a monument to a single avoidable click.

The case did not collapse — investigators reconstructed part of the scheme from the email server and the vendor application's server-side database, both outside the laptop. But the local spreadsheets, the personal-email artifacts, the browser history, and the document metadata — the richest and most direct evidence — were gone. The matter settled for a fraction of the exposure, on a thinner record than it should have had.

The analysis

1. Power-off is not a neutral act on an encrypted system. The dead-box reflex — "secure it, don't touch it, image it properly" — was correct in the era it was taught and is still correct for an unencrypted or already-locked device. On a running, unlocked, encrypted machine it does the one thing you cannot undo: it throws away the key. Technology changed; the procedure had to change with it.

2. The order of volatility has an invisible top entry: the decryption key. Above registers and RAM, on any unlocked encrypted host, sits the FVEK — dying at power-off. Treat an unlocked encrypted volume as the most perishable thing in the room, because losing it is the only loss in this chapter that is usually permanent.

3. Verify key escrow before you decide to power off — and assume it is missing. The company believed recovery keys were escrowed to AD; a quiet policy break had made that false for eight months. The defensible posture is to treat the recovery key as unavailable until proven otherwise, which pushes every decision toward capturing the live, decrypted state while you still can.

4. The correct play was live capture, in volatility order. Record authority and the two clocks; isolate the machine (it was on the corporate network); image memory first (preserving the FVEK and the live state); collect lineage-aware process, network, and open-file state; run a KAPE triage; and — because the volume was unlocked and might re-lock — take a live logical image of the mounted, decrypted volume. A smeared live image of readable data beats a pristine dead-box image of ciphertext every time.

5. Training is part of the toolkit, and it goes stale. The analyst was not careless; they executed outdated training flawlessly. Organizations that seize modern devices must teach the encryption-aware decision tree before sending anyone to "secure" a running machine — because the most expensive mistakes in live response are made by careful people doing the wrong correct thing.

Discussion questions

1. Write the step-by-step sequence the analyst should have followed from the moment they found the laptop unlocked, in volatility order, naming the tool you would use at each step and where its output would go.

2. The analyst's stated reason for shutting down was "to avoid corrupting anything." How would you explain to a non-technical manager why that instinct, though reasonable, destroyed more evidence than it protected?

3. ⭐ Suppose memory had been captured before power-off. Outline how an examiner could recover the BitLocker FVEK from that memory image and use it to decrypt the dead-box .e01 later. What must have been true at the moment of capture for this to work, and what is the honest probability caveat? (Encrypted-device forensics is Chapter 29.)

4. What legal-authority questions arise when imaging a live, logged-in corporate machine versus seizing a powered-off one — consent, acceptable-use policy, scope — and where would you record the basis? (See Chapter 25.)

5. Design a one-page "first responder finds a running machine" decision card your organization could laminate and hand to non-examiners. What three questions must it force the responder to answer before they touch the power button?