Index Attributes ($INDX / $i30)

Within the NTFS file system, the contents of a directory are not stored as a simple list. Instead, they are organized in a sophisticated B-tree data structure to allow for efficient sorting and rapid lookups. This structure is stored within special attributes of the directory's MFT record, known collectively as Index Attributes.

The primary index attribute, identified by its attribute type identifier $I30 in forensic tools, essentially serves as the directory's table of contents. It contains an entry for every file and subdirectory residing within that directory.

From a DFIR perspective, the $I30 index attributes are invaluable because, like the MFT, they do not immediately purge information about deleted items. Their internal structure and slack space can retain metadata about files long after their primary MFT records have been overwritten.

Location and Structure

The index information for a directory is stored within its own MFT record. The structure is split based on the size of the directory:

• $INDEX_ROOT: For small directories, all index entries are stored directly within this attribute inside the MFT record itself. This attribute also serves as the root node of the B-tree for larger directories.

• $INDEX_ALLOCATION: For larger directories that cannot fit within the $INDEX_ROOT, the B-tree structure is extended into external clusters on the disk, which are tracked by this attribute.

Each entry within the $I30 index contains a subset of metadata copied from the corresponding file's $FILE_NAME ($FN) attribute in its MFT record.

Stored Metadata

A single entry in a directory's $I30 index typically stores:

• Filename: The name of the file or subdirectory.

• MFT File Reference Number: A pointer back to the MFT record of the file or subdirectory.

• File Size: The logical size of the file.

• MACB Timestamps: A set of timestamps (Modified, Accessed, Changed, Birth) that mirror those from the file's $FILE_NAME attribute.

When a file is deleted, its entry in the parent directory's $I30 index is marked as inactive but is not immediately zeroed out or removed. It remains in the B-tree structure until its space is needed for a new entry, and even then, remnants can persist in the index buffer's slack space.

Forensic Value

Analyzing $I30 attributes, particularly focusing on inactive entries and slack space, can recover evidence that is no longer available in the MFT.

• Recovering Metadata of Deleted Files: This is the primary forensic value. By "carving" the $I30 index structures, forensic tools can extract these inactive entries. This can recover the filename, size, attributes, and $FN timestamps for files whose original MFT records have been completely overwritten and repurposed. This provides definitive proof that a file with a specific name once existed in that directory.

• Corroborating Timelines: The timestamps within $I30 entries provide another source of temporal data, reflecting the file's $FN timestamps. This can be used to corroborate or build timelines of file activity within the specific context of their parent directory.

• Identifying Renamed Files: While $UsnJrnl is the primary source for this, examining the sequence of active and inactive entries in an index can sometimes provide clues about recent renaming activity within a directory.

• Bypassing MFT Tampering: In a hypothetical scenario where an attacker could manipulate an MFT record without triggering other logs, the corresponding $I30 entry in the parent directory might still retain the original, untampered metadata.

Specialized tools are required for effective $I30 analysis. Command-line utilities like INDXRipper or forensic suites like EnCase and X-Ways Forensics have modules designed to parse these complex B-tree structures and extract data from both active and inactive entries.

---

Reflection points (SS Contest)

For a ScreenSharer, $I30 analysis is an advanced technique, but understanding its potential is key when dealing with a suspected evidence-clearing scenario where other artifacts fail.

• The Last Resort for Deleted Files: Imagine a player deletes a cheat, clears the Recycle Bin, and then creates enough new files to ensure the cheat's MFT record is overwritten. The $UsnJrnl might have wrapped, and VSS might be disabled. In this "worst-case scenario," parsing the $I30 index of the directory where the cheat was located (e.g., the Desktop) might be the only way to recover the cheat's filename and prove it ever existed there.

• Proving Existence: The most powerful use in an SS is simple: proving that a file named Vape.exe existed on the user's Desktop at some point. Even without a precise timestamp, this can be enough to contradict a player's claims and support a ban, depending on server rules.

• A Tool for the "Professional" Bypasser: This technique is most effective against players who know how to defeat more common forensic artifacts. It demonstrates a deeper level of investigation that can catch even sophisticated attempts at data destruction.