Imaging a Failing BitLocker Drive Under Court Pressure
A departing engineer is suspected of taking source code. Her company laptop has a 500 GB NVMe drive, BitLocker-encrypted and TPM-bound, with the recovery key escrowed in Intune. SMART reports 214 reallocated sectors and 3 uncorrectable errors. Using a hardware write blocker, an examiner runs ddrescue and produces an image with a 12 GB unreadable region. A second pass at a different block size yields a slightly different image hash. The case agent wants a single 'clean' hash to present in court, wants the laptop returned to IT for reissue next week, and proposes simply booting the machine and copying the user profile because 'the files are what matter'. A USB mass-storage device was reportedly connected the week before she resigned.
1. The agent demands one clean hash. How do you respond, and what exactly do you deliver?
Read the worked answer
Explain that a single clean hash is an artefact of healthy media, not a measure of examiner competence. On a drive with uncorrectable sectors, each pass reads different sectors successfully, so image bytes and therefore whole-image hashes legitimately differ. Promising a clean hash would mean either concealing the errors or fabricating a result.
What to deliver: the image file; the ddrescue mapfile and log, which record every good, bad and retried block; the SMART report captured before and after acquisition; the hash of the image plus the hash of the mapfile; and a written statement of the unreadable ranges. Run a second pass into a separate image, then a third pass restricted to bad areas with a smaller block size and retry settings, and keep every intermediate mapfile. Where two passes agree on a region, note that corroboration; where they disagree, mark it as unreadable rather than picking the convenient value.
Also document the write blocker model, firmware, connection path and start/end timestamps, and hash the source drive before and after if it remains readable. Present the acquisition as a documented, reproducible process with bounded uncertainty. Courts and opposing experts accept 'these 12 GB could not be read, here is the effort made' far more readily than a suspiciously perfect hash from a failing disk. Offer a supplementary acquisition attempt with a different tool if the agent wants independent corroboration.
2. The agent proposes booting the laptop and copying the user profile. Explain why that fails, and set out the correct handling including BitLocker.
Read the worked answer
Booting the original destroys the evidence it is meant to collect. It updates last-access timestamps and prefetch, writes to the pagefile and registry, may trigger BitLocker recovery events, and gives anyone with residual access a window to remove material. Copying the profile also excludes precisely what this case turns on: deleted files in unallocated space, $MFT and $UsnJrnl records, jump lists and link files, browser download history, Volume Shadow Copies, and the USBSTOR and setupapi records that tie the specific USB serial number to this host. A logical file copy cannot show that a file was copied to removable media.
Correct handling: keep the original write-blocked and unpowered as evidence. Image the encrypted volume as acquired. Then, using the escrowed recovery key obtained through a documented request, decrypt a working copy, not the original, and hash before and after decryption so the transformation is auditable. Analyse the decrypted copy with forensic tooling, confirm the USB serial from registry artefacts and correlate it with the DLP and endpoint telemetry. Return the laptop to IT only on written release after analysis and only with a mandatory reimage; never reissue it as-is. Note that TPM-bound BitLocker means the key release path itself should be logged, since it is a point a defence expert will examine.