In this module

MFT Entry Allocation and Sequence Numbers

14 hours · Module 1 · Free

Operational Objective

MFT entries are not created once and destroyed on deletion. They are allocated, freed, and reallocated in a cycle that can repeat dozens of times over the life of a volume. Each cycle increments the sequence number in the record header — a two-byte counter that starts at 1 on first allocation and increments on every subsequent allocation or deallocation event. This cycle creates both forensic opportunities and forensic pitfalls. The opportunity: a freed MFT entry retains metadata from the previous file until the entry is reallocated, providing a window where deleted file metadata is recoverable. The pitfall: file references throughout NTFS (parent directory entries, $LogFile records, USN Journal entries, hard links) include both the MFT entry number and the sequence number. A reference to "entry 5,000, sequence 7" points to the seventh use of that entry — not the current use if the entry has been reallocated since the reference was created. Misinterpreting stale references leads to incorrect conclusions about file relationships, parent directories, and evidence attribution. This subsection teaches how NTFS allocates and recycles MFT entries, how the sequence number tracks the lifecycle, how to use sequence numbers to detect stale references, and how to estimate the age and reuse frequency of MFT entries for forensic assessment.

Deliverable: Understanding of the MFT allocation lifecycle (allocate → use → free → reallocate), sequence number interpretation, stale reference detection using sequence number comparison, MFT growth behavior, and techniques for recovering metadata from previously allocated files using freed MFT entries.

Estimated completion: 35 minutes

Figure WF1.6 — MFT entry lifecycle showing allocation, freeing, and reallocation. The sequence number increments at each transition. File references include both entry number and sequence number, enabling detection of stale references where the referenced file no longer occupies that MFT entry.

The allocation cycle

When a new file is created, NTFS scans the MFT for a free entry — one with the in-use flag cleared (flags = 0x00). NTFS begins scanning from the beginning of the MFT and uses the first free entry it finds. This allocation strategy means that recently freed entries near the beginning of the MFT are reallocated quickly, while entries at the end of the MFT may remain free for longer.

When NTFS allocates a free entry, it increments the sequence number and sets the in-use flag. The record is then populated with the new file's attributes ($SI, $FN, $DATA, etc.), overwriting whatever data the previous file left in the record. From this point, the MFT entry belongs to the new file.

When a file is deleted, NTFS clears the in-use flag and increments the sequence number. The record's attributes are not zeroed — the previous file's $SI timestamps, $FN filename and timestamps, and $DATA content (if resident) remain in the record. NTFS also updates the volume bitmap to free the file's clusters (for non-resident data) and removes the file's entry from the parent directory's index.

The key forensic window: between the moment a file is deleted (entry freed) and the moment a new file is allocated to the same entry (entry reallocated), the deleted file's metadata is fully recoverable from the MFT record. The length of this window depends entirely on file creation activity on the volume — on a busy system with constant file creation, the window may be minutes. On a stable system with infrequent file creation, the window may be weeks or months.

Sequence number forensics

The sequence number provides three forensically useful data points:

Reuse frequency. A high sequence number (for example, 47) means the entry has been allocated and freed many times. High-reuse entries are typically near the beginning of the MFT, in a region that sees frequent file creation and deletion (temporary files, cache files, browser data). A low sequence number (1 or 2) means the entry has been used once or twice — either it was recently allocated for the first time as the MFT grew, or it is in a region of the MFT that doesn't see frequent reuse.

Stale reference detection. When an artifact (a parent directory reference, a $LogFile entry, a USN Journal record) references an MFT entry by entry number and sequence number, you can verify whether the reference is current by comparing the referenced sequence number against the current sequence number of the MFT entry. If they match, the reference points to the file currently occupying the entry. If the referenced sequence number is lower, the file that was referenced has been deleted and the entry has been reallocated — the reference is stale.

Evidence of previous occupants. When examining a freed MFT entry (sequence number N, flags 0x00), the attributes in the record belong to the file that occupied the entry at sequence N-1. The sequence number tells you this is the most recent previous file, not an older one. On a reallocated entry (sequence number N, flags 0x01), the current file is at sequence N; fragments of the previous file (sequence N-2 or N-1, depending on whether the free state incremented the sequence) may persist in MFT slack.

Compliance Myth: "MFT entry numbers are permanent identifiers for files — entry 5,000 always refers to the same file"

MFT entry numbers are not permanent file identifiers. They are reusable slots in an array. Entry 5,000 might refer to a Word document today, a malware executable next week (after the document is deleted and the entry is reallocated), and a PowerShell transcript next month. The only way to uniquely identify a file across time is the combination of MFT entry number AND sequence number. When your forensic report references a file by MFT entry, always include the sequence number: "MFT entry 5,000 (sequence 3)" is an unambiguous reference. "MFT entry 5,000" is ambiguous — which occupant of that entry are you referring to?

MFT growth and the $MFT zone

The MFT itself is a file (MFT entry 0) stored on the volume. When all existing MFT entries are in use and a new file is created, NTFS extends the MFT by allocating additional clusters and adding new entries. By default, NTFS reserves approximately 12.5% of the volume for MFT growth — this is the MFT zone. The reserved space is not exclusively locked for the MFT; regular files can use it when the rest of the volume is full. But under normal conditions, the MFT zone provides room for the MFT to grow without fragmentation.

The MFT rarely shrinks. Once entries are added to the MFT (even if the files they represent are later deleted), the MFT remains at its expanded size. This is beneficial for forensics — the MFT retains freed entries from deleted files rather than destroying them.

On a volume that has been in use for years with significant file creation and deletion, the MFT may contain thousands of freed entries scattered throughout the table. Each freed entry is a potential artifact. MFTECmd's standard output includes freed entries (marked as "not in use"), and the examiner can filter for these to identify recoverable deleted file metadata.

Practical sequence number analysis

When examining a specific file reference — for example, a parent directory reference in a $FILE_NAME attribute that points to MFT entry 500, sequence 3 — the verification process is:

Navigate to MFT entry 500 (offset 500 × 1,024 in the raw MFT).
Read the sequence number from the record header at offset 0x10.
Read the flags from offset 0x16.

If the sequence number is 3 and the flags indicate in-use, the reference is current — MFT entry 500 is still the directory that the reference points to.

If the sequence number is 5 and the flags indicate in-use, the reference is stale — the directory that the file belonged to (at sequence 3) was deleted, the entry was freed (sequence 4), and a new file was allocated to the entry (sequence 5). The current occupant of entry 500 is a different file entirely. The examiner cannot assume the current file's name or path applies to the referenced file.

If the sequence number is 4 and the flags indicate not-in-use, the entry was freed twice after the referenced file. The current record content belongs to the file at sequence 3 (the freed entry retains metadata from its last occupant). In this case, the reference might still be verifiable — the freed entry's $FN attribute may contain the directory name from sequence 3.

Decision point

MFTECmd reports that a suspicious executable's parent path is "C:\Windows\System32". But you notice the executable's $FN parent reference points to MFT entry 1,847, sequence 5. When you examine MFT entry 1,847 directly, the sequence number is 9 and the record contains a user's Documents folder — not System32.

Your options: (A) Trust MFTECmd's resolved path — the tool processed the entire MFT and resolved the reference correctly. (B) Recognize that the parent directory reference is stale — the sequence numbers don't match (reference says 5, current entry is 9). The file's parent directory at sequence 5 was a different directory than the one currently at entry 1,847. The executable was NOT in System32 — it was in whatever directory occupied entry 1,847 at sequence 5, which no longer exists. The MFTECmd output resolved to the current occupant of the entry, not the original directory.

The correct approach is B. This is exactly the parser limitation discussed in WF0.1. MFTECmd resolves parent references by looking up the entry number, but some versions don't verify that the sequence numbers match. When the parent directory has been deleted and the MFT entry reused, the resolved path points to the wrong directory. Always verify the sequence number when the resolved path seems inconsistent with other evidence.

Try it: Analyze sequence number distribution

Load an MFTECmd output CSV in Timeline Explorer. Add the "SequenceNumber" column to your view.

1. Sort by SequenceNumber descending. What is the highest sequence number in the MFT? This tells you the maximum reuse count for any single entry. 2. Filter for entries where SequenceNumber = 1. These are entries that have been used exactly once — the original file that was allocated to this entry is still the current occupant (or the entry was freed once and never reallocated). Count these entries. 3. Filter for entries where SequenceNumber > 10. These are heavily reused entries — typically near the beginning of the MFT in regions used by temporary files, browser caches, and application scratch data. Examine the file paths — do they confirm high-turnover locations? 4. Filter for deleted entries (InUse = False) with SequenceNumber = 2. These are files that were created (seq 1), then deleted (seq 2), and the entry has not yet been reallocated. These are the most recently deleted files with recoverable metadata. Examine their filenames — any of forensic interest?

This exercise builds intuition for how MFT entry reuse patterns relate to file system activity and helps identify the most promising areas for deleted file recovery.

MFT slack within records

When a file is allocated to a previously used MFT entry, the new file's attributes may not occupy the entire 1,024-byte record. The "used size" field in the record header (offset 0x18) indicates how many bytes are used by the current attributes. Any bytes between the used size and 1,024 are MFT record slack — space that belongs to this record but is not used by the current file's attributes.

MFT record slack can contain remnants of attributes from the previous file. If the previous file had a longer filename, more $DATA content (resident), or additional attributes (ADS, $OBJECT_ID), those bytes may persist in the slack region. This is distinct from the main forensic recovery method (examining freed entries where the entire record contains the previous file's data) — MFT slack analysis applies to reallocated entries where the new file's attributes don't fully overwrite the old ones.

The practical value of MFT slack is limited compared to freed entry analysis and $I30 slack analysis, but in cases where every piece of evidence matters (court testimony, high-stakes investigations), examining the slack region of reallocated entries can recover fragments of filenames, timestamps, or small file content from previous occupants.

You are examining a freed MFT entry (flags = 0x00, sequence number = 8). The $FILE_NAME attribute in the record shows filename "exfiltration_plan.docx" with $FN Created = 2026-02-10T14:30:22.4567890. The $SI Created shows 2025-06-15T09:00:00.0000000 (zero fractional seconds). What do you conclude about this entry?

The entry has been reused 8 times and the current data is unreliable — sequence number 8 means the record has been overwritten too many times to trust.

The entry is freed (not in use), so the attributes belong to the last file that occupied this entry. The filename "exfiltration_plan.docx" is the deleted file's name. The $FN Created timestamp (February 2026) is likely the real creation time. The $SI Created (June 2025 with zero fractional seconds) shows timestomping — the file was actually created in February 2026 but someone set $SI Created back to June 2025. The sequence number of 8 means this entry has been through 8 allocation cycles, but that only affects previous occupants — the current metadata belongs to the 7th or 8th occupant (the most recent file before the entry was freed). This is recoverable deleted file evidence with timestomping indicators.

The sequence number 8 and flags 0x00 indicate the record is corrupted — sequence numbers should only be odd for freed entries and even for allocated entries.

The file was created in June 2025 (per $SI) and the $FN timestamp of February 2026 reflects a metadata update when the file was moved to this directory — $FN Modified and $FN Entry Modified would show the move date.

Operational Artifact — MFT Sequence Number Verification Method

This subsection establishes the sequence number verification method for validating MFT file references. Every cross-reference in NTFS (parent directory references in $FN, file references in USN Journal entries, references in $LogFile) includes both an entry number and a sequence number. Verify both before trusting the reference: if the sequence numbers don't match, the reference is stale and the resolved data (filename, path, timestamps) may belong to a different file than the one originally referenced. Include sequence number verification in your methodology documentation for any investigation where file relationships or directory paths are central to findings. State the entry number, the referenced sequence number, the current sequence number, and whether they match — this demonstrates thorough evidence verification.

You've built the foundations of artifact-level forensic analysis.

WF0 gave you the taxonomy, NTFS architecture, and the five-step methodology. WF1 took you inside the MFT at the binary level — every attribute, every timestamp, every edge case. From here, every artifact category gets the same raw-first treatment.

WF2–WF10: every major Windows artifact decoded at binary level — USN Journal, Prefetch, Amcache, Shimcache, ShellBags, LNK, Jump Lists, SRUM, Event Logs, and the Registry hives
INC-NE-2026-0915 (WF13) — Insider data exfiltration capstone. Work the complete investigation from USB history to OneDrive exfiltration evidence
INC-NE-2026-1022 (WF14) — Ransomware capstone. Three-host triage (FIN01 → IT03 → FS01) across the 72-hour attack chain
The lab pack — 25+ realistic evidence files in 10 formats, simulated KAPE triage pre-populated, both capstones deployable to your own VM
Anti-forensic detection methodology — defeat timestomping, log clearing, and Prefetch deletion with cross-artifact correlation

Unlock with Specialist — £25/mo See Full Syllabus

Cancel anytime

← Previous Next →