In this section
$INDEX_ROOT and $INDEX_ALLOCATION — Directory Analysis
Scenario
In the insider threat scenario (INC-NE-2026-0915), the departing engineer deleted files from a staging directory after copying them to USB. The MFT entries for those files were eventually reallocated. But the staging directory's $I30 slack still contains the filenames and timestamps of the deleted files, proving they existed in that directory. The directory's metadata survived even though the files' own metadata did not.
How NTFS stores directory contents
A directory in NTFS is an MFT record with $INDEX_ROOT and (for larger directories) $INDEX_ALLOCATION attributes. The directory does not contain files. It contains an index of $FILE_NAME copies organized as a B-tree sorted by filename. Each index entry is a complete copy of the child file's $FN data: MFT reference, parent reference, four $FN timestamps, file size, flags, and filename.
When you list a directory (dir, Explorer, Get-ChildItem), the system reads the directory's index attributes and extracts metadata from the index entries. It does not read each child file's MFT record — the index entries contain all the information needed for a directory listing (filename, size, timestamps). This is why large directory listings are fast: the data is pre-indexed in the parent directory.
The B-tree organization means index entries are sorted by filename. When NTFS adds a new file to a directory, it inserts the entry into the correct sorted position in the tree, potentially splitting nodes and rebalancing branches. When NTFS removes a file (deletion), it removes the entry from the tree and may merge nodes. Both operations leave forensic traces: insertions push existing entries to make room (potentially overwriting slack from earlier deletions), and removals leave gaps that become slack space.
For small directories (under ~15-20 files, depending on filename lengths), the entire index fits in $INDEX_ROOT, which is resident in the directory's MFT record. No $INDEX_ALLOCATION exists. For larger directories, $INDEX_ROOT becomes the root node of the B-tree, and child nodes are stored in $INDEX_ALLOCATION records: 4,096-byte blocks allocated in disk clusters.
The duplication of $FN data in both the file's MFT record and the parent directory's index is forensically valuable. If the file's MFT record has been reallocated, the directory's index entry may still contain the original filename and timestamps. If the index entry was removed (file deleted), the file's MFT record may still have the data. The two sources corroborate when both exist and provide backup when one is destroyed. This redundancy is not by design for forensics — it is an NTFS performance optimization that happens to create forensic opportunity.
$I30 slack — recovering deleted file evidence
Anti-Pattern
Assuming deleted files leave no trace in the parent directory
When a file is deleted, NTFS removes its index entry by reorganizing the B-tree. But the bytes that formed the deleted entry are not zeroed. They become slack space within the index record. On directories with infrequent file creation (archive folders, project directories, shared drives), deleted entries persist for months. Tools like INDXParse and MFTECmd carve these entries from slack, recovering filenames, timestamps, and MFT references for files whose own MFT records are gone.
When NTFS removes an index entry, it slides entries forward or restructures the B-tree, but never zeros the vacated bytes. The deleted entry's $FILE_NAME structure persists in the slack at the end of the index record or in place as partially overwritten data.
This is what a carved $I30 slack entry looks like in MFTECmd output:
The file Manufacturing_Specs_2026.7z was deleted from the staging directory. Its MFT entry (48,271) was reallocated (current sequence is 5, the entry's sequence was 3). The file's own metadata is gone. But the directory's $I30 slack preserves the filename, creation timestamp, and 45.6MB size, proving a compressed archive was staged in that directory.
The persistence of $I30 slack entries depends on directory activity after the deletion. On a directory that doesn't experience frequent file creation (archive folders, completed project directories, restricted network shares), deleted entries can persist for months because no new entries are being inserted into the B-tree to overwrite the slack. On a temporary directory with constant file creation and deletion (like %TEMP% or browser cache directories), slack entries may be overwritten within hours as new files are continuously added and removed.
This makes $I30 analysis particularly valuable for investigating access to restricted or archival directories where file churn is low. The staging directory in an insider threat case, the restricted share in an access dispute, the project folder on a file server — these are exactly the directories where $I30 slack entries persist longest because they don't see frequent file creation.
The forensic value of $I30 slack extends beyond filenames and timestamps. Each carved entry also contains the file size at the time the directory entry was created, the file flags (Hidden, System, Archive), and the MFT reference with sequence number. The MFT reference lets you check whether the file's own MFT record is still available. If the sequence numbers match, you can recover the full MFT metadata. If they don't match, the $I30 entry is your last remaining evidence of that file's existence in that directory.
MFTECmd with the --de flag parses $I30 slack automatically. Specialized tools like INDXParse provide more granular control over the carving process and can recover partially overwritten entries that MFTECmd skips. For critical evidence, run both tools and compare results.
Index entry structure
Each index entry contains: the child's MFT reference (8 bytes: 6-byte entry number + 2-byte sequence number), entry length (2 bytes), $FN content length (2 bytes), flags (4 bytes, bit 0 = sub-node exists, bit 1 = last entry sentinel), and the embedded $FILE_NAME content. The $FN content is identical to the data in the child file's own $FN attribute: parent reference, four timestamps, sizes, flags, namespace, and filename.
The sequence number in the index entry's MFT reference is important for verification. When you find a carved $I30 entry for a deleted file and want to check whether the file's MFT record is still available, compare the sequence number in the index entry against the current sequence number of that MFT entry. If they match, the MFT record still belongs to the same file and you can recover its full metadata including $SI timestamps, $DATA attribute, and any ADS. If the current sequence is higher, the entry was reallocated and the file's MFT metadata is gone — but the $I30 entry itself is your evidence.
$I30 analysis should be performed on every investigation involving deleted files, even when MFT analysis has already recovered deleted entries. The two sources are complementary: the MFT record contains the full attribute set (timestamps, data, security descriptor), while the $I30 entry provides independent confirmation that the file existed in a specific directory. When both sources are available, they corroborate each other. When only one survives (the MFT entry was reallocated but the $I30 entry persists, or vice versa), the surviving source is your evidence.
Investigation Principle
$I30 slack provides evidence independent of the file's own MFT record. A filename carved from directory slack proves the file existed in that directory, even if the file's MFT entry has been reallocated to a completely different file. For insider threat investigations, this is often the evidence that survives the longest — the subject deletes the files, the MFT entries are reused, but the staging directory's index slack preserves the proof.