Case Study 2 — Impeached: The Report That Fell Apart on Cross

The same kind of insider IP-theft case as the chapter's anchor — a departing designer, a USB drive, CAD files — but told from the cautionary side. The artifacts were real and the suspect was probably guilty; the examination was sloppy, and a competent cross-examiner turned each shortcut into reasonable doubt. A correct finding, reported carelessly, is worth little.

Background

A mid-sized product-design studio suspects a departing senior designer copied proprietary fixtures and CAD assemblies to a personal thumb drive in their final week, then ran a cleaner to hide it. The matter is civil — a trade-secret claim — and headed for a deposition and likely trial. The studio's outside counsel retains a junior examiner who has the right tools (the EZ suite, RegRipper, Autopsy) and the right instincts about where to look, but who is in a hurry and has never been cross-examined. The examiner images the workstation, parses artifacts, finds what looks like a clean exfiltration story, and writes a confident eight-page report concluding that the designer "stole the files and ran CCleaner to cover it up." On paper it reads like the anchor case. In the deposition, the defense's expert — and then the defense's attorney — take it apart.

What happened on cross-examination

The findings were not fabricated; they were overstated, mis-sourced, and under-qualified. Four shortcuts did the damage.

Shortcut 1 — A ShimCache timestamp reported as an execution time. The report stated: "stage.exe was executed on the workstation at 14:07:11 on March 14." The only basis was a single ShimCache (AppCompatCache) entry. On cross, the defense expert established two facts the examiner had not disclosed: the stored timestamp is the file's $STANDARD_INFORMATION modified time, not an execution time; and on Windows 10 a ShimCache entry does not prove execution at all — only that the system saw the file. The examiner had no Prefetch, no UserAssist, and no BAM entry for stage.exe to corroborate. The "execution" finding collapsed into "the file was present," and the attorney let the jury hear the examiner concede it.

WHAT THE REPORT SAID         WHAT SHIMCACHE ACTUALLY SUPPORTS
"stage.exe executed at  →    "a file named stage.exe was present on the system;
 14:07:11 on Mar 14"          the recorded time is its $SI modified time, not a
                              run time, and ShimCache (Win10) does not prove it ran"

Shortcut 2 — A dirty hive parsed without its transaction logs. To time the USB mount, the examiner had extracted only SYSTEM from the image and parsed MountPoints2 and the USBSTOR properties, reporting a last-arrival time of "Thursday 16:20." The defense expert re-extracted the hive with SYSTEM.LOG1 and SYSTEM.LOG2, replayed the transaction logs, and showed the primary and secondary sequence numbers in the original had not matched — the hive was dirty. The replayed, current state put the relevant last-write a full day later. Now the studio's own two reports disagreed with each other about when, and the examiner could not explain the discrepancy from the stand. A correct method (replay the logs) would have produced one consistent time; the shortcut produced an impeachable contradiction.

Shortcut 3 — Per-user artifacts attributed to the wrong account. The report cited a UserAssist entry for CCleaner64.exe and a ShellBags path on drive E: as proof that the designer ran the cleaner and browsed the drive. But the examiner had pulled those artifacts from the wrong hive — they came from the Administrator profile's NTUSER.DAT and UsrClass.dat, used by IT during provisioning, not from the designer's profile. UserAssist, ShellBags, LNKs, and $Recycle.Bin\<SID> are per-user; attribution depends entirely on which hive the artifact lives in. The defense framed it bluntly: the studio's own expert had put the IT department's activity into the designer's mouth. The genuine designer-profile artifacts existed and would have supported the claim — but the report had cited the wrong ones, and the credibility damage spread to every other finding.

Shortcut 4 — "Browsed" and "opened" inflated to "copied" and "stole." The strongest real evidence — a LNK pointing at E:\Fixtures\ClampJig_v4.sldprt with a removable-drive volume serial, and ShellBags for E:\Fixtures\ — proves the file was opened from and the folder was browsed on a removable device. It does not, by itself, prove the files were written to that device. The report's word "stole" asked the artifacts to carry a conclusion they could not. The defense expert agreed the evidence was "consistent with copying" but established that opened-from and browsed are not copied-to, and that no write-event or destination-side artifact had been examined. The honest finding — files were accessed from a removable device in a tight window, which is consistent with but does not by itself prove copying — would have survived. The overstatement did not.

A fifth, quieter problem compounded the rest: the chain-of-custody worksheet did not record a hash for one extracted hive, so the defense could question whether the parsed file matched the imaged evidence. The conclusion the examiner could have defended — that a departing employee accessed proprietary files from a personal device in their final week, with several findings stated to their limits — was probably true. But the deposition transcript was full of concessions, the studio's leverage evaporated, and the matter settled on poor terms.

The bitter epilogue is what makes this a cautionary tale rather than a simple acquittal. When the studio's insurer commissioned a senior examiner to re-work the image from scratch, the underlying story held up: the designer's own NTUSER.DAT (not the Administrator's) carried the UserAssist and MountPoints2 entries, the SYSTEM hive replayed with its logs gave a single consistent USB last-arrival time, and the $SI`/`$FN contradiction on two .sldprt files survived every check. A careful report would likely have anchored a favorable settlement. The evidence had been there all along; the first examiner simply spent its credibility on shortcuts. That is the lesson in one line — in this discipline, you are not paid to be right in private; you are paid to be defensible in public. The re-examination cost the client a second fee and the leverage of a confident first impression, neither of which a clean initial workflow would have surrendered.

The analysis

  1. A right answer reported wrong is a lost case. The artifacts pointed at the suspect; the examination — overstated, mis-sourced, under-qualified — is what failed. Forensic value lives in defensibility, not in being privately correct.
  2. Never report a ShimCache time as an execution time. It is a $STANDARD_INFORMATION modified time, and on Windows 8+ ShimCache does not prove execution. Pair presence artifacts (Amcache, ShimCache) with execution artifacts (Prefetch, UserAssist, BAM) before you write "it ran."
  3. Dirty hives must be replayed. Unequal sequence numbers mean the latest changes live only in .LOG1/.LOG2. Extract the logs with the hive and use a parser that replays them, or your timestamps may be both wrong and contradicted by the other side's correct ones.
  4. Per-user artifacts are only as good as their attribution. UserAssist, ShellBags, LNKs, and $Recycle.Bin belong to whichever profile's hive they came from. Cite the SID/profile every time; one mis-attributed hive can poison an entire report's credibility.
  5. Match the verb to the artifact. Browsed (ShellBags) and opened (LNK/Jump List) are not copied or stolen. State findings at the level the data supports and disclose the gap; correlation is a legitimate, powerful argument only when it is labeled as correlation.

Discussion questions

  1. Re-write the report's central sentence ("stole the files and ran CCleaner to cover it up") into one or two sentences that the defense expert in this case could not have impeached — preserving the real evidentiary weight while stating its limits.
  2. The genuine designer-profile artifacts existed but were never cited. Walk through exactly how the examiner should have confirmed which NTUSER.DAT/UsrClass.dat belonged to the suspect before quoting any per-user artifact.
  3. For each of the four shortcuts, name the specific corroborating artifact (covered in this chapter) the examiner could have added to convert a weak claim into a defensible one.
  4. ⭐ Contrast this case with Case Study 1: both examiners found true things, but one finding held up and the other did not. Identify the single habit most responsible for the difference, and propose a one-page pre-deposition checklist that would have caught all four shortcuts here.
  5. The chain-of-custody worksheet was missing a hash for one extracted hive. Connect this to the book's second theme (the original is sacred) and to the admissibility standard discussed in Chapter 27 — Expert Testimony: how can a small custody gap undermine technically sound analysis?