Case Study 2 — The Repair That Overwrote the Proof

A company suspected a departing sales director of copying the client database on the way out. Well-meaning IT "preserved" the evidence by working on the live machine — and in doing so destroyed most of what a forensic examiner could have recovered. The mirror image of Case Study 1: every common mistake in the chapter, with a legal bill attached.

Background

A regional distributor's top sales director gave two weeks' notice to join a competitor. A manager, worried the director had taken the proprietary client list and pricing database, asked the internal IT technician to "look at the laptop and see what they deleted." The technician was capable and conscientious — and had never been trained in forensics. What followed was a sequence of entirely reasonable-looking actions, each of which wrote to the very disk that held the answers.

Three weeks later, after the director had started at the competitor, the company's lawyers opened a litigation matter and sent the laptop to an outside forensic examiner. By then the question was no longer only "what did the director take?" but "what did our own IT department destroy, and can the other side use that against us?"

None of this came from malice or even ordinary incompetence. The technician did exactly what a help-desk instinct dictates: turn the machine on, look around, try to fix what seems broken. That instinct is correct for a jammed printer and catastrophic for potential evidence — which is precisely why this scenario recurs in incident response more than almost any other. The discipline that would have saved the case is the very one Case Study 1's card recovery used without a second thought: image first, then touch only the copy. The two cases are mirror images separated by a single decision made in the first five minutes.

The investigation

The examiner did the one thing the chapter insists on and the IT technician had not: imaged the drive first, to an .E01, recorded MD5 and SHA-256, and worked exclusively on the copy. Reconstructing the technician's actions from system artifacts told a grim story:

Reconstructed sequence of WRITES to the original disk
─────────────────────────────────────────────────────────────
1. Powered on, booted Windows normally       -> boot + service writes,
                                                 Prefetch updated
2. Logged into the user's account             -> profile load, registry
                                                 hives written, temp files
3. Emptied the Recycle Bin "to read names"    -> $Recycle.Bin entries freed,
                                                 clusters marked reusable
4. Ran Disk Cleanup                           -> temp/cache purged; freed
                                                 clusters reused
5. Downloaded + INSTALLED a free undelete     -> tool written to C:\, MFT
   tool onto C:                                  records allocated for it
6. Recovered "found" files to C:\Recovered    -> recovered data written
                                                 ONTO the source volume
7. Ran chkdsk /f because "the disk was slow"  -> journal replay, structures
                                                 rewritten, clusters realloc.
─────────────────────────────────────────────────────────────

The damage was exactly what the chapter's "Common mistakes" section predicts. The database export the case turned on — a clients_2026Q2.csv and a staging folder the director had created, copied to a USB device, and then deleted — had left MFT records whose $DATA data runs once pointed straight at the data. But:

• Installing the undelete tool and writing recovered files to C:\Recovered reused dozens of freed MFT records and freed clusters — including the ones describing and holding the deleted export. The maps were overwritten by the very act of trying to recover them.
• chkdsk /f replayed the journal and reallocated clusters, finishing off regions that step 6 had missed.
• Normal boot, login, Recycle Bin emptying, and Disk Cleanup each wrote across the volume, steadily consuming the free space where deleted content had survived.

What the examiner could still establish was real but thin. Residual $FILE_NAME attributes and file-system journal traces showed that files named like the export had existed and been deleted, and Windows artifacts showed a USB mass-storage device had been connected in the relevant window (the deeper USB-history and timeline techniques live in Chapter 16 and Chapter 21). But the contents of the exported database — the thing that would have proved what was taken — were gone, overwritten on the company's own machine by its own staff.

A second, quieter loss compounded the first: the timeline itself was now polluted. Because the technician had booted the machine, logged in, emptied the Recycle Bin, and run two cleanup utilities, the access and modification timestamps that an examiner uses to reconstruct when the director acted were overwritten with the technician's own activity from three weeks later. Where an early image would have frozen the machine's state on the day of the resignation, the laptop the examiner received recorded mostly the story of its own mishandling. The examiner could not even cleanly separate "files the director deleted" from "files the cleanup tools removed," because both now sat in the same churned free space.

Legal Note. Opposing counsel argued the company had spoliated its own evidence and asked the court to view the gaps skeptically. The examiner's honest finding — we can show files were deleted and a removable device was attached, but the deleted contents were overwritten by post-incident activity on the original drive — was far weaker than the finding an image-first examination could have produced. Spoliation turns on intent and the duty to preserve, not on who pressed the keys; "our IT person was only trying to help" is not a defense that impresses a court.

The analysis

1. Image first, or you forfeit the undo. This is the single decision that separates this case from Case Study 1. With an image, every later misstep is reversible — discard the working copy, re-derive a clean one. Without it, the first wrong write is permanent. The technician never made a copy, so there was nothing to fall back to.

2. Recovering onto the source overwrites the unrecovered. Writing C:\Recovered onto the same volume being recovered is the textbook self-inflicted wound: the recovered files land on the free clusters that still held the not-yet-recovered deleted data. Always recover to a different device.

3. Powering on and logging in is writing, not "looking." There is no read-only way to "just check" a live Windows machine by using it. Boot, login, Prefetch, registry, temp files, and Disk Cleanup all write. To a forensic examiner, "I only looked at it" describes dozens of writes to the evidence. The only safe way to look is to remove the drive (or boot a forensic environment that never touches it), attach it through a write-blocker, and image it — after which you may look all you like, forever, on the copy.

4. A reused MFT record cannot be un-reused. Once the record's $DATA runs are overwritten by a new file, NTFS undelete has nothing left to read, and carving is the only hope — a poor one for a fragmented or already-overwritten CSV. The export's map was destroyed at step 5; nothing downstream could bring it back.

5. The absence of a trace is a trace — but a weaker case, and a self-inflicted one. The examiner could prove deletion occurred from residual metadata, yet could not prove what was taken. Working forensically by default — image, hash, document, hands off the original — costs almost nothing; skipping it cost this company its best evidence and handed the other side a spoliation argument. Same action, two purposes: image-first is identical whether the job is "get my photos back" or "prove what happened."

Discussion questions

1. List, in order, every write the IT technician caused from the moment they pressed the power button. Mark which were strictly avoidable and which were inherent to using the machine at all.
2. The export's MFT record was reused at step 5. Could signature carving (Chapter 7) recover the clients_2026Q2.csv contents? Explain why success is unlikely here specifically.
3. ⭐ Distinguish, with precision, "we cannot recover the file's contents" from "the file was never deleted." What residual artifacts let the examiner support the first claim, and how should the report word it to avoid overclaiming what the evidence supports?
4. At the first moment of suspicion, what should the manager have instructed? Draft a three-step instruction that any non-forensic employee could follow without destroying evidence.
5. This chapter says "image first, even for recovery." Explain how this purely forensic, litigation-bound case and Case Study 1's purely commercial card recovery are governed by the identical opening move — and why that convergence is the chapter's central discipline.