MFT Entry Allocation and Sequence Numbers

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 recently freed entries near the beginning are reallocated quickly, while entries deeper in the MFT may remain free for longer.

When NTFS allocates a free entry, it increments the sequence number, sets the in-use flag, and populates the record with the new file's attributes ($SI, $FN, $DATA), overwriting whatever the previous file left. From this point, the MFT entry belongs to the new file entirely. However, "overwriting" means the new attributes are written to the record — if the new file uses less space than the previous file (fewer attributes, shorter filename, no ADS), the unused portion of the record retains bytes from the previous file as MFT slack.

Recent research from Sygnia (April 2025) demonstrated an important behavioral difference between Windows versions for MFT slack. On older Windows systems (pre-Windows 10), when a resident file grows and transitions to non-resident storage, the old resident data persists in the MFT record slack after the $DATA attribute is converted to a non-resident data run list. On Windows 10 and later, NTFS zeros the slack area during this transition, eliminating the residual content. This means MFT slack analysis is more productive on older evidence but less reliable on modern systems for recovering data that was once resident.

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 timestamps, filename, and resident data remain intact 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 forensic window between deletion and reallocation depends on file creation activity. On a busy system with constant temp file creation, the window may be minutes. On a stable workstation or file server with infrequent file creation, freed entries near the end of the MFT can remain unallocated for weeks or months. During this window, the deleted file's metadata is fully recoverable.

Entry   Seq  InUse  FileName                    ParentPath
48271   5    True   quarterly_report.docx       .\Users\d.chen\Documents       ◄ Current file (seq 5)
48271   3    False  svchost_update.exe          .\Windows\Temp                 ◄ Previous occupant (seq 3, deleted)
48271   1    False  tmpDB4F.tmp                 .\Users\d.chen\AppData\Local   ◄ Original occupant (seq 1, deleted)

MFT entry 48,271 has been used three times. The current file (sequence 5, in use) is a Word document. The previous occupant (sequence 3, freed) was the attacker tool svchost_update.exe. The original occupant (sequence 1) was a temporary file. The sequence number history reconstructs who used this MFT slot and when.

Sequence number forensics

The sequence number provides three forensic uses.

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 recently allocated for the first time as the MFT grew, or in a region that doesn't experience frequent churn.

The sequence number is a 16-bit unsigned integer with a range of 1-65,535 (NTFS skips 0 when incrementing). In practice, even heavily churned entries rarely exceed sequence numbers in the hundreds. An entry with a sequence number above 1,000 indicates an unusually high level of file creation and deletion at that MFT slot — possibly a temp directory, a browser cache location, or a directory used by an application that creates and destroys files frequently. This can help characterize the volume's usage pattern.

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

This is how you detect parent path resolution errors in MFTECmd. The parser resolves parent directory references by looking up the MFT entry number in $FILE_NAME. If the parent directory's entry has been reallocated to a different directory since the file was created, MFTECmd resolves to the current directory name, not the original. The CyberCX research team documented this issue: when parent entries are reused, USN Journal tools mark the parent path as "UNKNOWN" because the sequence numbers don't match, but MFT parsers that only check the entry number without validating the sequence may silently resolve to the wrong path. Always verify sequence numbers on parent references for files that are central to your investigation.

Previous occupant evidence. When examining a freed MFT entry (flags 0x00), the attributes in the record belong to the file that most recently occupied the entry. On a reallocated entry (flags 0x01), the current file's attributes are present, but fragments of the previous file may persist in MFT slack — the unused bytes between the end marker (0xFFFFFFFF) and the end of the 1,024-byte record. MFT slack can contain remnants of previous attributes that were removed or resized, potentially including filenames and timestamps from earlier occupants.

MFT growth and the $MFT zone

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

The MFT rarely shrinks. Once entries are added (even for files later deleted), the MFT retains them as freed entries. This is beneficial for forensics — the MFT preserves freed entries rather than destroying them. On a workstation in use for three years, the MFT may contain 400,000+ entries with 20,000-50,000 freed entries. Each freed entry is a potential artifact. MFTECmd's output includes all freed entries marked "not in use," and filtering for these is a standard first step in deleted file recovery.

The MFT can become fragmented over time as it grows beyond its initial zone allocation. A fragmented MFT is still fully functional. The MFT's own $DATA attribute contains data runs mapping its clusters, just like any other non-resident file. KAPE and FTK Imager handle MFT fragmentation transparently during extraction.

Recent research from Sygnia (April 2025) demonstrated an important behavioral difference between Windows versions for MFT slack space. On older Windows systems (pre-Windows 10), when a resident file grows and transitions to non-resident storage, the old resident data persists in the MFT record's slack area. On Windows 10 and later, NTFS zeros the slack area during this transition, eliminating residual content. This means MFT slack analysis is more productive on older evidence but less reliable on modern systems for recovering data that was once resident and then grew beyond the threshold.