$I30 Forensics Cheat Sheet

What it is

Every NTFS directory keeps a sorted index of the names it contains so that lookups are fast. That index is stored in attributes named $I30: $INDEX_ROOT (resident inside the directory's MFT record, used on its own for small folders) and, once the folder grows, $INDEX_ALLOCATION (non-resident INDX records, typically 4 KB each) plus a $BITMAP marking which INDX records are in use. Each index entry embeds a copy of a $FILE_NAME structure for a child: name, parent reference, sizes and four timestamps.

The forensic value comes from slack: when entries are removed or the B-tree is rebalanced, old entries often remain in the unused tail of an INDX record. Parsing that slack can list files that were deleted from a folder, sometimes long after their $MFT records were reused.

Location

Windows version	Location	Notes
XP to 11 (every NTFS volume)	`$INDEX_ROOT:$I30` in the directory's MFT record	Resident; small folders only; limited slack
XP to 11	`$INDEX_ALLOCATION:$I30` of the directory	INDX records (signature `INDX`), where slack entries are found
XP to 11	`$BITMAP:$I30` of the directory	Which INDX records of the allocation are in use

Forensic tools such as FTK Imager show the allocation stream as a file named $I30 inside each folder. The same INDX structure is used by other NTFS indexes ($Secure:$SDH and $SII, $ObjId:$O, $Reparse:$R), which are not file-name indexes.

What it proves

A name existed in this folder: each active entry is a live child; each slack entry is a name that was once indexed there.
Deleted and renamed files: slack entries keep the old name, sizes and timestamps of files removed or renamed, including files emptied out of a staging folder or the Recycle Bin.
Point-in-time metadata: slack entries preserve the timestamps a file had when its entry was last written, which can predate later changes.
It does not prove who created or deleted the file, when the deletion happened (the index keeps no deletion time), or that the file was opened or executed.

Key fields

Field	Meaning
File reference	MFT entry and sequence number of the child; a mismatch with the current record means that record now holds another file
Parent reference	Directory that owns the index
Created / modified / record changed / accessed	Four timestamps copied into the entry
Allocated size, logical size	Sizes at the time the entry was written
Flags	File attributes (directory, hidden, system, archive…)
Namespace	Win32, DOS (8.3), Win32 and DOS, or POSIX name
File name	Name of the child
Offset / slack flag	Where the entry sits in the INDX record and whether it came from slack

Timestamps

Timestamp	Set when	Format	Pitfalls
Four entry timestamps (active entry)	The entry is created or updated by NTFS	FILETIME, UTC	Although stored in a `$FILE_NAME` structure, testing shows they usually mirror the file's `$STANDARD_INFORMATION` values; access time and size can lag behind the MFT record
Four entry timestamps (slack entry)	Last time the entry was written before it fell into slack	FILETIME, UTC	A snapshot, not a deletion time; some recovered entries were seen matching `$FILE_NAME` rather than `$SI` values
INDX record	No time field of its own	-	Use the parent folder's timestamps and the USN journal to bound when changes happened

These index copies are a third set of timestamps next to the $SI and $FN of the file record (see $SI vs $FN), which makes them useful when checking for timestomping.

Retention and clearing

Slack entries survive until NTFS reuses that space in the INDX record, typically when new names are added to the same folder. Folders with little churn keep old entries longest.
Folders with many files (System32, browser caches) rebalance constantly, so slack there is overwritten quickly.
Deleting and recreating a folder gives it a new index; the old INDX clusters then become unallocated space and can still be carved by their INDX signature.
Wiping tools that rename before deleting leave the random names, not the original ones, in slack.

Collection

KAPE target: none. FileSystem and $MFT do not collect $I30 streams; take a disk image or export the streams of the folders you care about.
Velociraptor (Windows.Triage.Targets): none. Use the Windows.NTFS.I30 artifact with AlsoUpload to upload raw $I30 streams for selected directory globs.
Built-in: there is no Windows command that reads index slack. Use a raw-NTFS tool (FTK Imager "Export files" on the $I30 entry, Velociraptor, a forensic image) and note which folders you exported.

Velociraptor artifact: Windows.NTFS.I30
  DirectoryGlobs = C:\Users\*\Downloads
  SlackOnly      = true
  AlsoUpload     = true

Parsing tools

MFTECmd (Eric Zimmerman): MFTECmd.exe -f E:\export\$I30 --csv E:\out lists active and slack entries with a FromSlack column and MFT references.
Velociraptor: Windows.NTFS.I30 carves entries (optionally slack only) directly on a live endpoint.
INDXParse (Willi Ballenthin, open source): INDXParse.py -d includes slack entries, CSV or bodyfile output.
Indx2Csv (Joakim Schicht, open source): parses $I30 INDX records, and also the $O and $R indexes.
dfir_ntfs (Maxim Suhanov): ntfs_parser --indx <image> <offset> out.csv extracts $I30 entries for every directory of a raw image with full paths.

Investigation tips

Run the Velociraptor artifact or MFTECmd on Downloads, Desktop, %TEMP%, \ProgramData\ and \Users\Public\: slack there often keeps names of dropped tools and exfiltration archives.
Compare a slack entry's MFT reference with the current $MFT record: same entry number but a higher sequence number proves the record was reused after the deletion.
A slack entry whose timestamps differ from the live $SI of the same file can show timestamps before they were changed.
Match slack names against the USN journal (FileDelete, RenameOldName) to date the deletion, and against $LogFile for very recent changes.
For folder-level browsing history, combine with ShellBags, which also record folders that no longer exist.

$I30 index attributes

Tools