File System Fragmentation Mapping and Time-Lining
You often can’t trust a standard “MAC times” timeline when an adversary timestomps $STANDARD_INFORMATION, renames files, or deletes entire directories. This guide teaches you how to map the physical fragments of a file across the disk and reconstruct a resilient chronology from NTFS internals and low-level journals-so you can explain what really happened even when typical metadata is gone.
At a high level, you will:
- Identify the file system geometry (cluster size, offsets) and extract unallocated space for carving. Tools like fsstat and blkls from The Sleuth Kit (TSK) provide those fundamentals fsstat manual and blkls manual. (sleuthkit.org)
- Carve for file signatures to find fragments independent of the file system’s directory structures (e.g., PhotoRec’s header/structure carving) PhotoRec documentation. (cgsecurity.org)
- Map carved fragments and known files to physical clusters (LCNs) and virtual cluster numbers (VCNs) using NTFS runlists and APIs that expose VCN↔LCN mappings (FSCTL_GET_RETRIEVAL_POINTERS) Microsoft FSCTL_GET_RETRIEVAL_POINTERS and RETRIEVAL_POINTERS_BUFFER. (learn.microsoft.com)
- Correlate fragments with NTFS metadata records (MFT), the Update Sequence Number (USN) Change Journal, and the NTFS transaction log ($LogFile) to build a timeline not reliant on potentially manipulated MAC times USN Change Journals overview, USN record structure, and $LogFile analysis tooling. (learn.microsoft.com)
Why this works: NTFS separates “what data sits where” (runlists mapping VCNs to LCNs) from file names and times. It also appends low-level summaries of changes into the USN Journal ($Extend$UsnJrnl) and records transaction details in $LogFile. Even when $MFT timestamps are forged, those other structures often retain independent evidence of creation, writes, renames, and deletes USN Change Journal records behavior and NTFS attribute types including $STANDARD_INFORMATION and $FILE_NAME. (learn.microsoft.com)