Skip to content

Understanding File-System Analysis

File-system analysis uses structures and journals created by a file system to reconstruct files, directories, metadata, and changes over time.

What you will learn

By the end, you should be able to distinguish common NTFS evidence sources, explain timestamp limitations, and choose corroborating records.

What is file-system analysis?

Core concept

NTFS records information about files and directories in structures such as the Master File Table, USN Change Journal, directory indexes, and transaction log. Each structure answers different questions and retains data for different periods.

MFTUSN Journal$LogFileDirectory indexesTimestamps

Keep in mind: A timestamp records a particular file-system event, not a complete account of user intent. Clock changes, copying, extraction, and application behaviour can affect it.

01MFT recordNTFS metadata describing a file or directory02USN recordA journal entry describing a type of change03Index entryDirectory metadata that may retain current or deleted references

Evidence sources

$MFTFile identity, paths, attributes, sizes, and timestamps
$UsnJrnlChange reasons and sequence information
$LogFileNTFS transaction activity used for recovery
$I30 indexesDirectory entries and possible remnants

The four sources in plain language

Think of these sources as four different views of the same file system. They overlap, but each is designed to answer a different kind of question.

The file catalogue$MFT

What it is: NTFS's main list of files and folders. Each entry describes an item, even when the file's content is stored elsewhere.

Use it for: Finding a file's name, parent folder, size, attributes, record number, allocation state, and recorded timestamps.

Think: “What is this item, and where does NTFS say it belongs?”
The change diary$UsnJrnl

What it is: A rolling journal that notes that a file or folder changed and records reason flags such as create, rename, overwrite, or delete.

Use it for: Following a partial sequence of changes, connecting related activity, and checking whether an item was renamed or removed.

Think: “What changed, and in what sequence?”
The recovery notebook$LogFile

What it is: NTFS's short-lived transaction log. Windows uses it to return the file system to a consistent state after an interruption.

Use it for: Examining recent, low-level NTFS operations and adding detail when reconstructing file-system activity.

Think: “What did NTFS recently try to change?”
The folder contents list$I30 / INDX

What it is: The index NTFS uses to keep track of the entries inside a directory. Unused index space can sometimes retain old entries.

Use it for: Checking which names appeared in a particular folder and finding possible references to deleted files or directories.

Think: “What was listed inside this folder?”

A record is not an explanation of intent

These sources describe file-system activity, not who intended it or why. They can also be incomplete because records are reused or overwritten. Correlate them with each other and with independent evidence before drawing a conclusion.

Try it: choose the right source

For each question, choose the source that gives you the strongest starting point. In a real investigation you would normally use more than one source.

Question 1 of 4You need a file's record number, parent folder, size, attributes, allocation state, and recorded timestamps. Where should you start?
Question 2 of 4You want to follow whether a file was renamed and then deleted, and the order in which those changes occurred. Where should you start?
Question 3 of 4A file is gone, but you want to know whether its name may still appear in the unused space of a particular directory's index. Where should you look?
Question 4 of 4A system lost power. You need recent, low-level NTFS transaction activity around the interruption to help reconstruct what the file system was doing. Where should you start?

Why it matters

Reconstruct paths

Metadata connects file references, parent directories, names, and attributes.

Follow changes

Journals can show create, rename, delete, and other change reasons.

Identify remnants

Deleted records and indexes may retain useful references after file removal.

Build timelines

Normalised metadata can be correlated with application and operating-system artefacts.

How file-system analysis works

  1. PreserveWork from a verified image or acquired source artefact.
  2. IdentifyConfirm the volume, NTFS version, relevant paths, and time context.
  3. ParseUse suitable tools for MFT, journals, logs, and indexes.
  4. CorrelateConnect record numbers, sequence numbers, parent references, paths, and timestamps.
  5. ValidateCompare findings with file content and independent artefacts.

Use structures together

  1. 1AnchorStart from a path, record, hash, or time.
  2. 2TraceFollow identifiers across file-system sources.
  3. 3CorrelateAdd application and system artefacts.
  4. 4QualifyExplain gaps, reuse, and timestamp limits.

File-system tools in SUSA

File metadata

Master File Table ($MFT)

Choose interactive record examination or structured export according to the scale and purpose of the review.

Change history

USN Change Journal

Acquire the journal from the evidence source, then parse its reason flags and sequence information into structured output.

NTFS transactions

Transaction Log ($LogFile)

Examine low-level NTFS transaction activity while accounting for log reuse, incomplete context, and retention limits.

Directory metadata

Directory Indexes ($I30 / INDX)

Parse supplied directory indexes or carve index records from raw data when investigating current and deleted references.

Evidence access

Acquisition and file recovery

Copy locked NTFS system files or extract files directly from an NTFS volume into a separate controlled destination.

Continue learning