Case Study 1 — The Key Was in the Directory All Along

A departing engineer's laptop arrives full-disk encrypted, and everyone braces for a months-long fight with BitLocker. It opens in under an hour — because in a managed enterprise the recovery key was escrowed to Active Directory the whole time. The lesson is the chapter's quietest and most useful: in the enterprise, encryption is rarely the barrier. Escrow is the friend of the authorized examiner and the bane of the careless insider.

Background

A mid-sized turbomachinery firm suspected a senior mechanical engineer of taking proprietary compressor designs to a competitor he was about to join. Internal signals were strong but circumstantial: a resignation effective in two weeks, a spike in after-hours badge-ins, and an HR report that he had been "tidying up his files." Under the company's authority over its own device — the laptop was corporate property, issued under an acceptable-use policy the engineer had signed — the legal team authorized a forensic examination and engaged you. This is the book's second anchor case, the employee who covered their tracks, and it threads through Chapter 16 — Windows Forensics and Chapter 21 — Timeline Analysis. What none of those chapters dwelt on was the first wall you hit when the laptop reached the bench: the entire system volume was BitLocker-encrypted.

The case agent's first question was the one every examiner now hears: "It's encrypted. Are we stuck?" The honest answer was "Probably not — but let me check the right thing first, in the right order."

The investigation

You acquired the SSD through a hardware write-blocker per Chapter 14 — Forensic Acquisition, computing MD5 and SHA-256; source and image hashes matched, chain of custody intact. Opening the image confirmed the wall: the system volume began with the BitLocker signature, and sampled regions sat at ~7.99 bits/byte of entropy — uniform ciphertext, no $MFT, nothing to carve.

$ xxd -l 16 ENG-LT-44.dd
00000000: eb58 902d 4656 452d 4653 2d00 0200 0800  .X.-FVE-FS-.....
                 └──────────────────┘  "-FVE-FS-" → BitLocker

The temptation, and the most common waste of an openable drive, would have been to extract the header and start a brute-force attack against the passphrase. Instead you asked the productive question first: what protectors are on this volume, and is any of them escrowed somewhere I can lawfully reach? Against the mounted image in a controlled environment, you enumerated the protectors:

$ manage-bde -protectors -get ENG-LT-44 (working copy, volume offset mounted)
Volume ... [OS Volume]
    Key Protectors:
        TPM
        Numerical Password
            ID: {6F1A2C84-9D3E-4B71-AE20-1C8857F0E6BB}
            Password: (escrowed)

Two protectors: a TPM (bound to the original machine, useless to you off-host) and a Numerical Password — the 48-digit recovery password — identified by a Recovery Key ID. The machine was domain-joined, and the firm's Group Policy escrowed BitLocker recovery information to Active Directory. So the key you needed had been sitting in the directory since the day the laptop was provisioned. You retrieved it from the computer object, matching on the Recovery Key ID:

$ Get-ADObject -Filter 'objectClass -eq "msFVE-RecoveryInformation"' `
    -SearchBase (Get-ADComputer ENG-LT-44).DistinguishedName `
    -Properties msFVE-RecoveryPassword
  msFVE-RecoveryPassword : 287402-118910-553301-449086-336710-... (48 digits)
  (child object name encodes Recovery GUID 6F1A2C84-... — matches the protector)

You unlocked a working copy of the image with the recovery password, mounted the decrypted volume read-only, and recorded everything that would matter on cross-examination — where the key came from, who retrieved it, under what authority, and the hashes proving the original was untouched:

DECRYPTION RECORD — Case 2026-0142, Item: ENG-LT-44
  Volume:      BitLocker (XTS-AES-128, "-FVE-FS-")
  Protectors:  TPM ; NumericalPassword (Recovery Key ID 6F1A2C84-...)
  Key source:  AD escrow — CN=ENG-LT-44, msFVE-RecoveryPassword
               retrieved 2026-06-26 14:02Z by J. Okafor, GCFA (domain admin, authorized)
  Action:      unlocked WORKING COPY; mounted READ-ONLY
  Integrity:   encrypted image  SHA-256 = 7f3a91...  (unchanged)
               decrypted volume SHA-256 = 2c84e0...  (recorded for analyzed copy)

Encryption had added perhaps an hour to the case. From there it was ordinary Windows forensics, and the engineer's own anti-forensic effort betrayed him exactly as the anchor case promises. The USBSTOR registry keys recorded a Kingston DataTraveler connected three times in his final week. He had used a tool to backdate the file-access timestamps on the exfiltrated CAD files — but while the $STANDARD_INFORMATION` timestamps were altered, the `$FILE_NAME timestamps in the MFT (which user-mode tools rarely touch) preserved the true sequence: the design files were copied to drive E: at 19:04 on a Sunday, the LNK and $Recycle.Bin artifacts corroborating to the second. A web-history fragment showed a personal cloud-storage upload the same evening. The decrypted drive turned a suspicion into a documented timeline.

The analysis

  1. Check for escrow before you do anything clever. The single most common waste of an openable drive is giving up — or burning weeks on brute force — without querying the escrow. In any managed environment, BitLocker keys live in Active Directory or Entra, FileVault has an institutional key, and LUKS may carry an admin slot. The clever attacks exist for when escrow fails, not before it is checked.

  2. Enumerate protectors, then use the weakest one you are authorized to use. You never attacked "the encryption." You listed the doors — a TPM you could not use off-host and a numerical password you could obtain — and walked through the one that was open. That is the entire method, and it is why a flawless cipher is irrelevant when a recovery key is reachable.

  3. A recovery key is itself evidence. Where the key came from matters as much as what it opened. The decryption record — provenance, authority, retrieval time, the hash of the unchanged original and of the analyzed copy — is what answers the inevitable cross-examination question, "How did you get in, and did it alter the evidence?"

  4. Work the copy, read-only — even when it is ciphertext. The original was sacred from acquisition through decryption. You unlocked a working copy and mounted it read-only; the encrypted original's hash never changed. The book's second theme holds even here, where "the original" is an unreadable wall.

  5. In the enterprise, encryption is rarely the barrier — and convenience is the insider's undoing. The same managed configuration that made the laptop usable (escrowed keys, so a forgotten password is never a catastrophe) made it openable to a lawful internal investigation. The engineer trusted strong encryption to hide the theft; the encryption protected the device, not him, because his employer held a key the whole time.

Discussion questions

  1. The case agent asked "are we stuck?" the moment the drive showed as encrypted. Write the two-minute explanation you would give a non-technical manager of why a corporate BitLocker drive is usually openable while a stranger's personal one usually is not — using the word "escrow" and the idea of multiple key protectors.

  2. You enumerated protectors and found a TPM and a numerical password. Why was the TPM protector useless to you, while the numerical-password protector was the way in? What would have changed if the only protector had been TPM+PIN with no escrow?

  3. Trace the decryption record line by line and explain what each element defends against on cross-examination. Which single line answers "did unlocking the drive alter the evidence?"

  4. ⭐ Suppose the firm's Group Policy escrow had silently broken eight months earlier (as in Chapter 15's Case Study 1), so the recovery password was not in Active Directory. Walk the remaining key-sources in order for this powered-off corporate laptop and state, honestly, where you most likely end up — and what that would have done to the IP-theft case.

  5. The engineer altered $STANDARD_INFORMATION` timestamps but not `$FILE_NAME. Once the drive was decrypted, why did his anti-forensic effort fail, and how does this connect to the book's third theme — every action leaves a trace, and the absence of a trace is itself a trace — which Chapter 30 — Anti-Forensics develops in full?