Case Study 2 — The Helpful Admin

A departing engineer is suspected of taking proprietary designs to a competitor. Before anyone calls a forensic examiner, a well-meaning systems administrator powers on the laptop "to take a look" and copies some files off "to preserve them." His good intentions contaminate the evidence and hand the opposing side an argument it should never have had. This is the contrast to Case Study 1: the same low-level world of deleted files and timestamps, but a forensic matter — where what you can prove matters as much as what is true, and where the first responder's reflexes decide the case.

Background

A senior mechanical engineer at a mid-sized manufacturer gives two weeks' notice on a Friday and announces he is joining a direct competitor. Over the weekend, the IT systems administrator — diligent, loyal, and entirely untrained in forensics — notices something while doing routine cleanup. In the engineer's final days he had plugged a personal USB drive into his workstation several times, opened dozens of proprietary CAD files he had no current project reason to touch, and, the night before his last day, downloaded and run a popular "PC cleaning" utility. The admin's stomach drops. He believes the engineer took the company's designs.

Wanting to help, and wanting to act, the admin does what feels responsible. On Monday morning he carries the laptop to his desk, boots it into Windows, logs in with the local admin account, and starts looking. He opens the engineer's Documents folder and double-clicks several CAD files to confirm they are the sensitive ones. He browses the Recent Items list. Then, worried the evidence might "disappear," he copies a few dozen files he considers important onto a network share "to preserve them," and for good measure drags the whole user profile folder onto an external drive he had lying around. He writes nothing down. He uses no write blocker — he has never heard of one. He takes no hash of anything. Satisfied he has secured the evidence, he emails legal: "I've saved everything important off his laptop. It's all here."

This is the second phone call from Chapter 1 — corporate IP theft, a matter that will plausibly end in litigation — being handled, in its critical first hours, as if it were a casual IT recovery. Everything the admin did was well-intentioned. Almost all of it was damaging.

What went wrong

The trouble is that a running computer is not a static object; it writes to itself constantly, and every boot, login, and double-click changes the very evidence you are trying to capture. Consider what the admin's "look" actually did, at the level this book teaches you to see.

Booting the laptop wrote to dozens of system files: it updated logs, refreshed the registry, generated fresh Prefetch entries, and advanced the clock on the operating system's own activity. Logging in created a new session and timestamps. Double-clicking each CAD file to "confirm" it updated that file's last-access time — overwriting the very timestamps an examiner would later use to establish when the engineer himself last touched it, and replacing them with Monday's date under the admin's account. Browsing Recent Items and opening folders seeded still more artifacts. Dragging the profile to an external drive copied files without preserving their original metadata, so the copies now carry the copy's timestamps, not the originals'.

Timeline fragment (reconstructed later, painfully):

  Fri 16:50  engineer's last legitimate logoff
  ----------------------------------------------  <- evidence frozen HERE would have been ideal
  Mon 08:14  laptop powered on by admin           (system files written)
  Mon 08:15  admin login                          (new session artifacts)
  Mon 08:22  design_revB.sldprt  ACCESS time -> Mon 08:22  (was: the engineer's last access)
  Mon 08:31  user profile copied to E:\           (copies carry Monday timestamps)
  Mon 09:05  "I've saved everything" email to legal

When legal does retain a forensic examiner a week later, she faces a contaminated scene. The crucial last-access timestamps on the most important files now read Monday, under the administrator's account, not the engineer's final days. The "preserved" copies on the network share are forensically near-worthless: no source hash, no write blocker, no record of how they were made, original metadata gone. There is no chain of custody for the laptop — it sat on the admin's desk, powered on, accessible to anyone, for a week. And every defense attorney's favorite question is now available for free: "Isn't it true that after my client left, your administrator logged into this laptop, opened these files himself, and copied things around — and you cannot actually prove what state the machine was in when he left?"

Chain of Custody. Custody does not begin when the examiner arrives; it begins at the first moment someone recognizes evidence might matter. Here, that moment was Saturday, when the admin first suspected theft. From then on, the correct move was to stop touching the device, secure it powered-off in a locked location, write down who had it and when, and call someone who images before they analyze. An unbroken record from that first moment is what lets you stand in court and say the evidence is the same as it was when the engineer set it down. The week of undocumented, powered-on access is exactly the gap opposing counsel needs.

What a clean response would have looked like

The examiner salvages what she can — and this is the quietly reassuring half of the story. Even with the contamination, much survives, because of a theme from Chapter 1: anti-forensics rarely beats a thorough examiner. The engineer's "PC cleaner" deleted his browser history and recent-files lists, but the cleaner's own execution left Prefetch and AmCache records proving the tool ran, and when. The USB device's serial number is still carved into the registry's USBSTOR key, fixing when the personal drive was attached. And the timestamps the engineer himself altered to disguise his activity show the classic tell: his tampered $STANDARD_INFORMATION` times disagree with the parallel `$FILE_NAME times NTFS keeps quietly alongside them — and the disagreement is itself proof of tampering. The technical case is, in the end, recoverable.

But it is recoverable despite the response, not because of it, and it now comes burdened with the admin's contamination as a permanent asterisk. Had the matter been treated with forensic rigor from Saturday — laptop powered off and secured, chain-of-custody log opened, the drive imaged through a write blocker and hashed before anyone analyzed anything — the same artifacts would have told the same story with none of the doubt. The lesson is not that the admin destroyed the case. It is that he made an unambiguous case arguable, for no benefit, by acting before he understood which discipline he was in.

The analysis

  1. Powering on a suspect machine changes it — irreversibly. A live operating system writes to itself on every boot, login, and file open. The instant you suspect a device holds evidence, the correct action is to stop, not to "take a quick look." Every interaction spends evidence you cannot get back.

  2. Good intentions contaminate. The admin was loyal and trying to protect the company. Forensics is unforgiving of intent: the evidentiary value of an action depends on what it did to the data, not on why you did it. "I was trying to help" preserves nothing and excuses nothing on cross-examination.

  3. Forensic rigor is the correct default the moment a matter could go legal — and IP theft always could. This is the war-story lesson from Chapter 1, lived from the other side. You can always choose not to invoke rigor you have; you can never retroactively add the rigor you skipped. When the discipline is unclear, lean toward the one that preserves your options.

  4. Chain of custody starts with the first responder, not the expert. The week the laptop sat powered-on and unlogged on the admin's desk is an unfillable gap. Custody, documentation, and "hands off until imaged" are not the examiner's job alone — they are everyone's job from the first suspicion onward.

  5. Anti-forensics rarely beats a thorough examiner — but careless forensics can beat your own case. The engineer's cleaner and timestomping failed against Prefetch, AmCache, USBSTOR, and the $FILE_NAME`/`$STANDARD_INFORMATION mismatch. The real threat to the case was never the suspect's evasion; it was the friendly contamination from inside the company.

Discussion questions

  1. The admin's single most damaging action was double-clicking files to "confirm" they were sensitive, which overwrote their last-access timestamps. Explain precisely why those timestamps mattered to the case, and what the examiner could and could not reconstruct after they were overwritten.

  2. Contrast this case with Case Study 1. Both involve deleted files and NTFS timestamps, yet one keeps no chain of custody and the other's whole value depends on it. Articulate the single underlying difference that drives every divergence in how the two jobs are handled.

  3. Write the one-page "first response" instruction you would give to every non-forensic IT administrator in an organization: what to do, and what not to do, in the first hour after suspecting a device holds evidence. Limit it to what a layperson can reliably follow under stress.

  4. The engineer ran a "PC cleaner" to cover his tracks, yet the tool's own execution became evidence against him. Explain how an anti-forensic action can strengthen a case rather than weaken it, and connect this to the chapter's third principle.

  5. ⭐ Suppose the examiner concludes that, because of the contamination, she cannot prove the engineer's last-access dates to a forensic standard, even though the surviving artifacts strongly suggest the theft occurred. How should she phrase this in her report, and what does Chapter 1's principle "know your limitations" demand she resist — both the temptation to overstate certainty for a client who wants a clean win, and the temptation to understate a genuine finding out of excess caution?