Case Study 2 — The File That Was Modified Before It Was Created

A departing engineer backdates a stolen design document to make it look untouched for a year, and Windows Explorer dutifully shows the faked date. But NTFS records every file's timeline twice, and the liar edited only one copy. This is the forensic mirror of Case Study 1: the same MFT structures, read not to restore a file but to prove what happened — and to prove someone tried to hide it.

Background

A mid-size hardware firm believes a senior engineer, three days from joining a competitor, has taken a proprietary control-board design. The engineer had legitimate access to the file, rev9_control_board.sch, in the ordinary course of work, so mere possession proves nothing. Management's question to the forensic examiner is narrower and harder: can you show the file was staged for exfiltration around the resignation, rather than simply sitting where it always had?

This is the book's second anchor — the employee who covered their tracks — and the file system itself is the witness. The workstation is Windows 10, a single NTFS volume on a SATA hard drive (not an SSD, a fact that will matter for what survived). The examiner does the front end by the book: the drive is acquired through a hardware write-blocker, imaged to an .E01, hashed, and every step that follows runs against the verified working copy. Nothing is ever read from the live machine.

Recovery vs. Forensics. Case Study 1 read an MFT/inode to get bytes back; here the examiner reads the same kind of structure as sworn testimony. Every field of the MFT record is evidence: the two timestamp sets, the parent reference, the sequence number, the journal entries. The deliverable is not a working file — it is a defensible statement of what happened and when, sourced to a hashed image. Same bytes; opposite purpose.

The investigation

Explorer tells a tidy, exculpatory story. Right-clicking the staged copy on the engineer's desktop shows a "Date modified" of more than a year earlier — long before any competitor was in the picture. If the examiner stopped there, the case would collapse. But Explorer shows only the $STANDARD_INFORMATION` (`$SI) timestamps, and $SI` is the set any user-space tool can rewrite with a single, unprivileged API call. So the examiner pulls the raw MFT record with `istat` and compares `$SI against the second, kernel-written timestamp set, $FILE_NAME` (`$FN):

$ istat -o 2048 workstation.E01 47021

MFT Entry: 47021    Sequence: 3    In-use: Yes
$FILE_NAME: rev9_control_board.sch    Parent: 41877  (\Users\<user>\Desktop\_archive)

$STANDARD_INFORMATION Times:
Created:        2025-02-03 09:11:40 (EST)
File Modified:  2025-02-03 09:11:40 (EST)   <- the date Explorer shows
MFT Modified:   2026-06-22 23:48:02 (EST)
Accessed:       2026-06-22 23:48:02 (EST)

$FILE_NAME Times:
Created:        2026-06-22 23:47:55 (EST)   <- file first appeared here
File Modified:  2026-06-22 23:47:55 (EST)
MFT Modified:   2026-06-22 23:47:55 (EST)
Accessed:       2026-06-22 23:47:55 (EST)

The contradiction is stark and damning. The $FN` set says this filename first existed in the `_archive` folder at **23:47:55 on June 22, 2026** — three days before the resignation. The `$SI set claims the file was created and last modified in February 2025 — sixteen months earlier than the $FN` "created" time. A file cannot be modified before it exists. That ordering — `$SI modified earlier than $FN` created — is a logical impossibility under normal operation; it occurs only when someone rolls `$SI back by hand. The $SI` times are also suspiciously clean (whole-second, identical created/modified), while the `$FN times carry the kernel's precise, distinct values — a second classic tell. The examiner is no longer looking at a file's history; they are looking at the fingerprints of a cover-up.

A single artifact, however persuasive, is not a finding. The examiner corroborates against the file system's own diary, the **$UsnJrnl`**, read from its `:$J stream:

USN  reason flags (chronological, file ref 47021)
23:47:55  FILE_CREATE                 rev9_control_board.sch   (parent 41877)
23:47:55  DATA_EXTEND | CLOSE
23:48:02  BASIC_INFO_CHANGE | CLOSE   <- $SI timestamps rewritten here

The change journal independently confirms the same sequence: the file was created in the staging folder at 23:47:55, and seven seconds later its basic info — the $SI timestamps — was deliberately altered. The journal corroborates the timestamp contradiction with an independent record of the very act of backdating. (USB device history in the registry and a cloud-upload artifact, examined under the same engagement, place the file on a removable device minutes later — but those belong to Chapter 16 and the timeline work of Chapter 21; the file system alone already proves staging and tampering.)

Legal Note. Timestamps persuade juries because "when was this created?" is intuitive — but they are attackable on cross, because they reflect a system clock that can be wrong, skewed, or changed. What makes this finding robust is not one timestamp but the internal contradiction between two independently maintained sets plus a third corroborating source. "The metadata says X" is a hypothesis; "the $FN` set, the impossibility of modified-before-created, and the `$UsnJrnl all agree on X" is a finding. The standards for admitting this analysis live in Chapter 25.

The report states only what the artifacts support: the file rev9_control_board.sch first appeared in the user's _archive staging folder at 23:47:55 on June 22, 2026; its $SI` timestamps were altered seven seconds later to display a February 2025 date; and the `$SI/$FN` contradiction, corroborated by the `$UsnJrnl, indicates deliberate backdating. The examiner is careful not to over-claim motive beyond what the evidence shows — but here, unlike Case Study 1's TRIM puzzle, the evidence does establish a deliberate act, because timestomping does not happen by accident.

The analysis

  1. NTFS records the truth twice; liars usually edit one copy. $STANDARD_INFORMATION` and `$FILE_NAME carry independent timestamp sets. Backdating tools touch the $SI` set Explorer shows and leave the `$FN set — the harder-to-reach one — telling the truth.

  2. $SI` is forgeable; `$FN is kernel-written. Any user-space tool can rewrite $SI` with one API call, but `$FN is normally written only by the kernel on create, move, or rename and is not exposed to those calls. That asymmetry is the entire reason the contradiction exists.

  3. "Modified before created" is impossible — and impossibility is proof. A $SI` modified time earlier than the `$FN created time cannot arise from normal operation; only manual rollback produces it. Round $SI` values against precise `$FN values are a second, corroborating tell.

  4. Proving the cover-up can be more damning than the act. Possession of the file was innocent; backdating it was not. Demonstrable tampering speaks to consciousness of guilt and is often the more persuasive evidence — theme #3: the attempt to erase a trace is itself a trace.

  5. Corroborate before concluding. The examiner refused to rest on the timestamp contradiction alone and confirmed it with the $UsnJrnl. One artifact is a hypothesis; independent agreement across artifacts is a finding that survives cross-examination.

Discussion questions

  1. Why is $FILE_NAME` harder to forge than `$STANDARD_INFORMATION? Name what writes each set and what user-space tools can and cannot touch, then explain why an examiner who only checked Explorer's dates would have cleared the engineer.

  2. Walk through, in your own words, exactly why a $SI` "modified" time that is *earlier* than the `$FN "created" time is a logical impossibility under normal file-system operation — and what single action produces it.

  3. The examiner corroborated the timestamp contradiction with the $UsnJrnl before writing the conclusion. Drawing on the Legal Note, explain why a careful examiner never rests a courtroom claim on a single artifact, and what cross-examination would do to a report that did.

  4. ⭐ Contrast intent across the two case studies: Case Study 1's deletion was an accident, this one a deliberate cover-up. How does the presence of intent change what you look for in the file system, and why does anti-forensic activity — covered in Chapter 30 — so reliably leave its own traces?

  5. The deliverable here is "a defensible statement of what happened and when," while Case Study 1's was "the customers' files back." Both investigations read the same kind of structure (a file's metadata record). Explain why identical structures serve opposite goals, and what each discipline trusts that record to tell it.