Case Study 1 — The Date the Suspect Set

A departing engineer backdated a stolen design file to make it look like two-year-old routine work. The Explorer date said February 2022; the kernel said March 2024. The case did not turn on finding the file — both sides agreed it existed — but on proving when it was created, and the timeline that reconciled the forged clock against the truthful one is what made the answer survive cross-examination.

Background

This is anchor case #2 — the employee who covered their tracks — followed through to its conclusion. A mid-sized turbine manufacturer suspected that jrivera, a mechanical engineer who had given notice, copied proprietary computer-aided-design files to a personal USB device on his last Friday before resigning. The artifacts had already been gathered: in Chapter 16 — Windows Forensics you extracted, parsed, and hashed the registry, .evtx, prefetch, LNK, and Jump List artifacts for jrivera on the verified image WS-ENG-04.E01; in Chapters 18 and 19 you pulled the browser and email records. You had a dozen CSV exports and a dozen true-but-isolated facts. Counsel's question was singular: did he take the files before he left, or is this routine work being misread after the fact?

The defense's entire strategy was visible from the first meeting. They did not dispute that TurbineHousing_v7.sldprt had been on a personal drive. They disputed the dates. The local copy on the Desktop, viewed in Windows Explorer, reported Modified: February 11, 2022 — well before the resignation, consistent with the story that this was old, sanctioned work the employee had always had. If that date held, there was no theft, only a misunderstanding. The case was a fight about a timestamp.

The investigation

You built the timeline the disciplined way, and the discipline is what won.

You established the time standard before merging anything. NTFS, registry, and .evtx sources were already UTC. You read SYSTEM\ControlSet001\Control\TimeZoneInformation, confirmed the workstation's Pacific zone for the reader-facing column, and — critically — measured clock skew: comparing the workstation's send time for an email jrivera sent that Friday against the corporate mail server's Received header showed the machine clock was within about two seconds of true UTC, and there were no event ID 4616 "system time changed" records anywhere on the timeline. The recorded times could be trusted as written. You documented that finding in one sentence, because you knew the defense would ask, "Whose time is that, exactly?"

You resolved the timestomp in the file system itself. MFTECmd on $MFT` placed `$STANDARD_INFORMATION and $FILE_NAME side by side for the disputed file:

TurbineHousing_v7.sldprt  —  MFT timestamps (UTC)        [image WS-ENG-04.E01]
  $SI Born/Mod/MFT/Acc : 2022-02-11 10:00:00.0000000   ← what Explorer shows (forged)
  $FN Born/Mod/MFT/Acc : 2024-03-15 18:58:13.4928130   ← kernel-maintained (truthful)

The contradiction was decisive. The $SI` set claimed creation on 11 February 2022 — and all four values were *byte-for-byte identical* with a *zeroed* 100-nanosecond fraction, the signature of a tool that wrote whole seconds. The kernel-maintained `$FN set placed the file's birth at 18:58:13.4928130 on 15 March 2024, with a realistic, messy sub-second fraction. The $SI "creation" was earlier than the file's own kernel-recorded birth, which is impossible without intervention. You did not delete the forged time from the timeline; you kept it and labeled it, because the act of forging it was itself a dated event in the story.

You corroborated the true time independently. You never rest a conclusion on one artifact. The $Extend\$UsnJrnl:$J change journal held a USN_REASON_FILE_CREATE record for the file's MFT reference dated to the same 2024-03-15 18:58 instant — a second, independent witness to the true birth, and one the cheap stomping tool had not touched.

You read the merged super-timeline as a story. Pivoting from the strongest anchor — the USBSTOR connection — the events clustered into a single Friday-evening sequence, every line sourced and most corroborated by two independent artifacts:

WS-ENG-04  MASTER TIMELINE (UTC) — user jrivera          [image SHA-256 on file]
18:51:07  SanDisk Cruzer Glide connected → drive E:      USBSTOR + MountedDevices + MountPoints2
18:55:32  Browsed E:\ProjectArchive\TurbineHousing\      UsrClass ShellBags
18:58:13  Desktop\TurbineHousing_v7.sldprt CREATED        MFT $FILE_NAME + $UsnJrnl FILE_CREATE  ✔
19:04:00  Opened ...v7.sldprt FROM E: (+3 siblings)        LNK (vol SN 9C2A-77F1) + Jump List
19:20:11  Visited personal cloud-storage upload page       Browser history (Ch.18)
19:25:44  Email to personal account, .sldprt attached      Webmail Sent + Received header (Ch.19)
19:33:18  Device E: removed                                USBSTOR last-removal
──────────────────────────────────────────────────────────────────────────────────────
NOTE  Explorer "Modified 2022-02-11" = $SI, FORGED (zeroed sub-seconds, $SI Born < $FN Born).
      True birth 2024-03-15 18:58:13 per $FN + USN journal. Timestomping flagged; truth anchors it.

At arbitration, the defense made exactly the three moves you had prepared for. They argued the clock might be unreliable — you produced the two-second skew measurement against the mail server and the absence of any 4616. They argued the 2022 date proved old work — you put the $SI` and `$FN columns on one slide and explained, in a sentence a non-technical panel could hold, that the "old" date was the one the suspect had set, and the "new" date was the one the operating system had recorded for itself. They argued temporal proximity was coincidence — you showed the convergence: five independent artifacts agreeing on the device, the volume serial in the LNK matching the connection, the change journal agreeing with $FN to the second. The backdated date, which was meant to be the defense's strongest fact, became the prosecution's: a deliberate, dated act of concealment. The timeline held.

Recovery vs. Forensics. The very same $FILE_NAME attribute and USN journal that here proved a creation time against a forgery are what a 💾 recovery technician reads to decide which version of a recovered file is newest and which shadow-copy snapshot to restore first. One set of kernel timestamps; the examiner reads them to prove the order, the recovery tech to restore the latest — the dual lens the whole book turns on.

The analysis

  1. Establish the time standard before you merge a single event. Reading TimeZoneInformation, measuring skew against an external reference, and confirming no event ID 4616 are not preliminaries you can skip — they are the foundation a cross-examiner attacks first. "I verified the clock against two independent references" is a credibility asset; an unverified axis is a liability.
  2. Trust the kernel's clock over the user's. Explorer, dir, and Get-ChildItem show $STANDARD_INFORMATION`, which any user can forge; `$FILE_NAME is the kernel's bookkeeping and has no documented user-space write API. When the two disagree, $FN is the truth and the disagreement is the finding.
  3. Keep the forgery on the timeline; do not erase it. The backdated $SI` is not noise to be discarded — it is a dated act of concealment that strengthens the narrative. You demote it to "flagged artifact of manipulation" and let the truthful `$FN anchor the sequence.
  4. Corroborate every load-bearing line. $FN` alone is strong; `$FN plus a USN_REASON_FILE_CREATE record at the same instant is unshakable. Convergence across independent clocks is what makes a single artifact's forgery or ambiguity irrelevant.
  5. The case turned on when, not what. Both sides agreed the file existed and was on a personal drive. Finding the file proved nothing; proving its true creation time, against a deliberate forgery, proved everything. That is timeline analysis as the spine of the investigation.

Discussion questions

  1. The defense's strongest fact — the 2022 Explorer date — became the prosecution's strongest fact. Explain the single technical reason this reversal was possible, and write the one-sentence courtroom explanation of $SI` vs. `$FN that a non-technical panel could hold onto.
  2. You measured a two-second clock skew and found no event ID 4616. Walk through how your analysis would have changed if a 4616 had existed at 02:00 that Friday, rolling the clock back three days. What would you have done differently to the timeline, and why does "apply one constant offset" become wrong?
  3. The true creation was corroborated by both $FN and a USN_REASON_FILE_CREATE record. Suppose the USN journal had wrapped and discarded that record before imaging. Name two other artifacts on the master timeline that still place the file's creation inside the Friday-evening cluster, and explain how they constrain the true time even without the change journal.
  4. ⭐ The defense could have argued that file-system tunneling or a restore-from-backup innocently produced a $SI` older than `$FN. Construct that argument at its strongest, then rebut it using the specific evidence in this case (the zeroed sub-seconds, the four identical $SI values, the corroborating cloud-upload and email exfiltration). Why does the pattern, not any lone attribute, defeat the innocent explanation?
  5. The report stated the sequence but asserted no intent — it did not say "he planned the theft for weeks." Explain why "report the sequence, let others argue intent" is both an ethical obligation and a strategic strength on cross-examination, and identify one sentence a careless examiner might have written that the timeline cannot actually support.