01The question
In what order and over what period were the files on the server changed, and is there evidence that Windows event logs were cleared around that time?
02Background
A fictional company, Kuzey Makine, imaged a file server after users reported that documents would no longer open. The examination is a timeline reconstruction for the incident report. It stays at the level of what the system's own records show happened to the files; it does not reconstruct intrusion technique.
03Constraints
- The server had been powered off before imaging, so no live memory was available.
- Some operational event-log channels had rolled over, limiting the window they covered.
04Evidence received
05Examination method
Build a file-change timeline from NTFS journals
The $UsnJrnl:$J and $MFT were parsed to list, in order, the creation, rename and overwrite of files across the affected shares. The characteristic pattern — large numbers of files overwritten and renamed with a new extension in a short span — defined the start and end of the encryption window with 100 ns resolution.
$UsnJrnl:$J (USN change journal)$MFT (NTFS Master File Table)NTFS $STANDARD_INFORMATION vs $FILE_NAMETimestamp decoder
Recover pre-incident state from shadow copies
Volume Shadow Copies from before the window were mounted read-only to recover original file contents and their timestamps, giving a baseline to compare against the encrypted state. The last shadow copy before the window bounded the earliest possible start.
Test whether event logs were cleared
The Security log was read for event 1102 (audit log cleared) and the System log for 104 (log cleared). A clear event, the sudden absence of entries before a time with normal entries after, and a record-number discontinuity were each checked. Clearing was inferred only where more than one of these agreed.
Windows XML Event Log (EVTX)Timestamp decoderEvent 1102Event 104
Normalise to UTC and cross-check the clocks
All times were converted to UTC. The $MFT/$UsnJrnl times, event-log times and shadow-copy creation times were compared for consistency, so that a single corrected timeline could be presented with each event's source artifact named.
Windows XML Event Log (EVTX)$UsnJrnl:$J (USN change journal)Local time to UTCtimebases
06Findings
Established
The file-encryption window began and ended within a defined span on one night, with thousands of files renamed and overwritten in order.
BasisThe $UsnJrnl and $MFT give an ordered, high-resolution record of the changes; shadow copies bound the start.
Probable
The Security event log was cleared shortly before the encryption window.
BasisEvent 1102 is present and a record-number discontinuity agrees; but a rolled-over channel limits full corroboration.
07Limits
- A cleared or rolled-over log limits the timeline; the absence of entries is reported as a gap with its cause.
- This timeline describes what happened to the files and logs; it does not establish who did it or how initial access occurred.
- File-system timestamps can be altered; where only $STANDARD_INFORMATION was available it was compared with $FILE_NAME.
08Report excerpt
The $UsnJrnl records a continuous run of rename+overwrite operations on the shares between 23:12 and 23:47 UTC on 2026-…, ending when free space ran low. Security event 1102 (log cleared) is recorded at 22:58 UTC with a record-number discontinuity. We present the clearing as probable because the System channel had rolled over and could not independently confirm it.
09Lessons
- The NTFS change journal is the strongest source for the order and span of a mass file change.
- Infer log clearing only when more than one independent sign agrees.
- Keep the timeline to what the records show about the files; leave attribution and cause to where the evidence supports them.