Case Study 2 — The Plug They Should Not Have Pulled

A small firm's only copy of its critical files sits on a BitLocker-encrypted laptop that arrives at the recovery shop still running and unlocked — with the key sitting in RAM, waiting to be lifted. A junior technician, following the "always image the disk first" reflex, shuts it down to attach a write-blocker. In that one act the recoverable becomes the genuinely unrecoverable.

Background

A two-partner architecture studio loses its office manager suddenly. The manager's Windows laptop holds the only current copy of the firm's active project files, billing records, and a client contract database — none of it backed up anywhere the partners can find. The system drive is BitLocker-encrypted. The recovery key was never escrowed: it is not in a Microsoft account, not in Active Directory (the firm has no domain), and not on the slip of paper anyone can locate. The passphrase/PIN is unknown.

Crucially, when the partners bring the laptop to a local data-recovery shop, it is still powered on and logged in — left running at the desk, screen unlocked. The encrypted volume is mounted. This is the best possible starting condition: while the machine runs with the volume mounted, the BitLocker Full Volume Encryption Key (FVEK) is held in RAM so the OS can read the disk transparently. A clean memory capture, followed by bulk_extractor or aeskeyfind to recover the AES key schedule, would very likely have produced the FVEK — and an FVEK turns the "unrecoverable" volume into a fully readable one, no passphrase required. The data was, at that moment, recoverable.

What happened

The intake technician is junior, competent with disks, and has internalized the most important rule in recovery wrong. Trained that the original is sacred and that you image first, work on the copy, the technician reaches for the reflex that is correct for almost every job that crosses the bench: power the machine down, pull the drive, attach it to a hardware write-blocker, and make a forensic image. So that is what happens. The laptop is shut down cleanly and the drive is imaged.

On the next boot — needed to confirm the imaging — the laptop stops at the BitLocker recovery screen demanding a 48-digit recovery key nobody has. The drive image, made faithfully and hashed correctly, is a perfect copy of a wall of ciphertext. The volume is sealed.

WHAT WAS TRUE AT INTAKE              WHAT WAS TRUE AFTER POWER-OFF
─────────────────────────────       ──────────────────────────────────────
Machine running, volume mounted      Machine off; BitLocker re-locked
FVEK present in RAM                   FVEK gone — DRAM cleared at power-off
aeskeyfind/bulk_extractor → key      No memory image was ever captured
Disk readable via recovered key      Disk = ciphertext; no key, no recovery
STATUS: recoverable                  STATUS: genuinely unrecoverable

The shop's senior examiner reviews the case the next morning and sees immediately what was lost. The order of volatility (RFC 3227), the same principle that governs forensics, governs this recovery job exactly: RAM is near the top of the ladder, the disk near the bottom. The correct sequence was memory first, disk second — capture RAM to external media, extract the FVEK, then power down and image the disk, now decryptable with the recovered key. The technician inverted the order, and unlike almost every other mistake in recovery, this one has no remedy. You can re-image a disk a hundred times; the memory state that held the key existed once and is gone.

The examiner is honest with the partners about the remaining options, and about why each fails:

  • Brute-force the passphrase? BitLocker's key derivation is deliberately expensive, and a human-chosen PIN/passphrase of any real length is not feasible to exhaust. Not a path.
  • Find the 48-digit recovery key? It was never escrowed. The partners search the manager's email, cloud accounts, and physical files; it is not there. Without it, or the passphrase, the cryptography holds — exactly as designed.
  • Attack the encryption itself? Strong, correctly-implemented full-disk encryption with no key is, for practical purposes, unbreakable. This is the book's fifth theme at its hardest: some data is genuinely unrecoverable.
  • Cold-boot remanence? The window closed the instant the machine powered down and the DRAM cleared; there was no chilled-RAM procedure in place, and planning around remanence is never a professional default.

The data is lost. The cause was not a failed tool or a corrupt sector — it was a procedure run in the wrong order on the one kind of evidence that cannot be re-acquired.

Recovery vs. Forensics. This is the mirror image of the chapter's anchor case and of Case Study 1. There, examiners captured memory from a live, unlocked machine and the FVEK seized from RAM kept an entire case readable. Here, a recovery shop powered off a live, unlocked machine and the FVEK that would have saved the client's data evaporated. Same artifact, same rule, opposite outcome — and the only variable was whether someone captured RAM before pulling the plug.

Limitation. Once the machine was off and the FVEK gone, no amount of skill or tooling could recover the volume. Recognizing that — and saying so plainly rather than billing the client for futile brute-force attempts — is itself a professional duty. Knowing when to stop is part of knowing the craft.

The analysis

  1. The order of volatility governs recovery, not just forensics. RAM is the most perishable source; the disk is stable. When a live machine holds something only RAM can give you — here, the encryption key — you capture memory before power-off, then image the disk. The technician applied the right principle ("image first") to the wrong layer.
  2. A mounted encrypted volume means the key is in RAM — capture it. The single best moment to defeat full-disk encryption is while the volume is mounted on a running machine. A memory capture plus aeskeyfind/bulk_extractor recovers the FVEK and makes the disk readable without the passphrase. Power-off slams that window shut.
  3. Memory is the one evidence you cannot re-acquire. Every other mistake in this book has a do-over: re-image the disk, re-run the parser, re-extract the hive. A lost memory state has none. That asymmetry must change how you sequence a live machine.
  4. Strong encryption with no key is a real wall — say so. When the key is gone and none is escrowed, the honest finding is "unrecoverable," not a month of doomed brute-forcing. The fifth theme is a feature of professional judgment, not an admission of failure.
  5. Prevention is the lesson that lands hardest. Escrowing the BitLocker recovery key (to a Microsoft account, AD, or a printed slip in a safe) and keeping a current backup would have made this a non-event. The recovery shop's after-action note to the partners is as much about key escrow and backups as about what went wrong on the bench.

Discussion questions

  1. Write the correct intake procedure for a running, unlocked, encrypted machine brought in for data recovery, as a numbered sequence. Identify the exact step the technician skipped and the exact step they performed out of order.
  2. The technician was following a rule that is correct for almost every recovery job ("image the disk first; the original is sacred"). Explain why that rule, applied to a live encrypted machine, produced the opposite of its intent — and how you would teach the exception without undermining the rule.
  3. After power-off, the senior examiner ruled out brute force, recovery-key search, attacking the cipher, and cold-boot remanence. For each, state the one-sentence technical reason it fails, so a client understands why "unrecoverable" is a finding and not a shrug.
  4. ⭐ Compare this cautionary recovery with the success in Case Study 1. Both involved a live machine and a decision about power. Identify the single habit that separated the good outcome from the bad one, and draft a three-line "live machine" decision card a bench technician could tape to the workstation to encode it.
  5. The same "capture RAM before power-off" rule appears in the chapter's ransomware-adjacent contexts (anchor case #3). Describe a second, non-encryption scenario in which powering off a live machine before capturing memory would destroy evidence that no disk image could recover, and explain what would be lost.