$I30 — NTFS Directory Index

When a file is deleted from an NTFS directory, its parent directory’s $I30 index entry is marked as unused but the bytes — filename, size, timestamps — persist in the page slack until overwritten by a new directory entry. This guide covers the internal structure, acquisition, parsing, anti-forensics resilience, and investigative applications of the $I30 directory index artifact.

What Is $I30?

Every directory on an NTFS volume maintains an index of the files and subdirectories it contains. This index is stored in an attribute named $I30 — named after its index type, $I30 for filename. The index is organized as a B-tree data structure, which allows the NTFS driver to perform fast lookups, insertions, and deletions as files are created, renamed, and removed within the directory.

The B-tree is composed of 4,096-byte index pages (matching the default NTFS cluster size). Each page contains multiple index entries, and each index entry stores a copy of the file’s metadata at the time it was added to the directory. This includes the filename, file size, parent directory MFT reference, and four timestamps (Created, Modified, MFT Modified, Accessed). These values are independent of the timestamps stored in the file’s own MFT record — they reflect the state of the file at the moment the directory index entry was created or last updated.

NTFS uses two attributes to store the directory index depending on directory size:

• $INDEX_ROOT (attribute type 0x90) — A resident attribute stored directly within the directory’s MFT entry. Used for small directories where all index entries fit within the MFT record (typically fewer than ~20 files depending on filename lengths). This attribute is always present and serves as the root node of the B-tree.
• $INDEX_ALLOCATION (attribute type 0xA0) — A non-resident attribute that stores additional index pages (called INDX records) when the directory grows beyond what fits in $INDEX_ROOT. Each INDX record is a 4,096-byte page with its own header, update sequence array, and set of index entries. Large directories may have hundreds or thousands of INDX pages.

Location & Format

Physical Location

The $I30 index is not stored in a single file. It is distributed across the MFT entries of every directory on the volume. Each directory’s MFT record contains an $INDEX_ROOT attribute (resident, always present) and, for larger directories, an $INDEX_ALLOCATION attribute (non-resident, stored in INDX pages scattered across the volume). There is also a companion $BITMAP attribute that tracks which INDX pages are currently in use.

INDX Page Structure

Each INDX page is a 4,096-byte record with a fixed header followed by a variable number of index entries. The header begins with the magic signature INDX (bytes 49 4E 44 58), followed by an update sequence array (USA) for integrity verification, and offsets indicating where index entries begin and where free space starts.

Index Entry Structure

Each index entry within an INDX page contains a copy of the file’s $FILE_NAME attribute, which includes the filename and a full set of timestamps. This is the data that persists in slack space after deletion.

What It Reveals

The $I30 directory index answers a specific class of investigative questions that other artifacts either cannot answer at all or can only answer after the MFT record has been recovered. The following questions are directly answerable from $I30 slack space analysis:

• What files once existed in a specific directory? — Slack space entries retain the full filename (up to 255 characters, UTF-16LE) even after the file has been deleted and its MFT entry reallocated. This is the primary forensic value of $I30.
• What was the original filename before a rename operation? — When a file is renamed, the old index entry becomes slack and a new entry is created. Both the old and new filenames may coexist in the same INDX page, revealing the rename history.
• When was the file originally created in this directory? — The Created timestamp in the index entry reflects the $FILE_NAME creation time, which is set when the file is first placed in the directory and is not modified by subsequent file content changes.
• What was the file size at the time of the directory entry creation? — Both the allocated size (cluster-aligned) and real size (actual bytes) are stored, allowing reconstruction of how large the file was.
• Which parent directory contained the file? — The parent MFT reference field identifies the exact directory, establishing the file’s location in the directory tree at the time of the index entry.
• Did files with suspicious names ever exist in staging directories? — Slack entries in %TEMP%, ProgramData, or user Desktop directories may reveal tooling filenames (mimikatz.exe, procdump64.exe, rclone.exe) that no longer exist on disk.
• Were files copied to a USB-connected drive? — $I30 entries on a mounted USB volume retain filenames of files that were copied to the device, even if the device has since been wiped or reformatted (if the INDX pages survived).
• Did anti-forensics tools miss directory-level evidence? — Because no widely distributed cleanup tool targets INDX page slack, $I30 analysis frequently recovers evidence that survived CCleaner, Eraser, SDelete, and manual deletion.

Forensic Use Cases

1. Anti-Forensics Bypass — Recovering Deleted File Evidence

The most common forensic use of $I30 is recovering evidence of files that have been deleted and whose MFT entries have been reallocated. A subject deletes files from a directory, empties the Recycle Bin, runs CCleaner, and even uses Eraser on specific files. The MFT entries are gone. Prefetch shows no relevant executables. But the parent directory’s INDX pages still contain slack entries with the original filenames, sizes, and creation timestamps. The investigator extracts these entries and reconstructs a list of files that once existed in the directory.

2. Timeline Reconstruction — File Creation Sequences

By parsing $I30 entries (both active and slack) across multiple directories, an investigator can build a timeline of file creation activity. The Created timestamps in $I30 entries are $FILE_NAME timestamps, which are more resistant to timestomping than $STANDARD_INFORMATION timestamps. If an attacker uses a timestomping tool to backdate files, the $I30 Created timestamp may still reflect the true creation time because most timestomping tools only modify $STANDARD_INFORMATION.

3. Ghost Vendor Fraud Detection

In our CASE #287 investigation, a CFO created fictitious vendor directories, generated fraudulent invoices and wire confirmations, submitted them for payment, then deleted all evidence and ran anti-forensics tools. The MFT was clean. $I30 slack space in the parent directories retained 63 file entries across three ghost vendor directories, including filenames like Meridian_Invoice_Q3_2025.pdf and Apex_Wire_Confirmation_Sept.pdf. The filenames alone were sufficient to subpoena bank records and recover $2.1M in fraudulent payments.

4. Malware Staging Directory Analysis

Threat actors frequently stage tools in temporary directories (%TEMP%, C:\ProgramData, C:\Windows\Temp) before execution. After execution, the tools are deleted. $I30 slack in these staging directories may reveal filenames such as mimikatz.exe, PsExec.exe, nc.exe, procdump64.exe, or renamed variants. Even if the file content is unrecoverable, the filename and size combination (e.g., a 1.2 MB file named m.exe in %TEMP%) provides strong investigative leads.

5. USB File Copy Detection

When an NTFS-formatted USB device is connected and files are copied to it, the destination directories on the USB volume create $I30 entries for each copied file. If the USB device is later recovered (even after user-level deletion of the copied files), $I30 slack analysis on the USB volume reveals which files were placed on the device. This is critical in insider threat cases where the subject claims no files were copied to removable media.

Acquisition Methods

Full Forensic Image (Preferred)

# Create a forensic image using dc3dd (or dd / ewfacquire)
dc3dd if=/dev/sdb hof=/evidence/case287/disk.raw hash=sha256 log=/evidence/case287/acquisition.log

# Or using FTK Imager CLI
ftkimager.exe \\.\PhysicalDrive1 C:\Evidence\disk --e01

# Mount the image read-only for analysis
mount -o ro,noexec,nodev,loop /evidence/case287/disk.raw /mnt/evidence

KAPE — Targeted MFT and $I30 Collection

:: Collect $MFT, $I30, $UsnJrnl, and $LogFile
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target !SANS_Triage

:: The !SANS_Triage target collects:
::   $MFT (contains $INDEX_ROOT for every directory)
::   $I30 INDX pages (via $INDEX_ALLOCATION extraction)
::   $UsnJrnl:$J (change journal for correlation)
::   $LogFile (NTFS transaction log)

:: For targeted $I30 extraction from a specific directory:
icat.exe \\.\C: [MFT_ENTRY_NUMBER] > C:\Evidence\target_dir_i30.bin

FTK Imager — Live System Extraction

# In FTK Imager:
# 1. Add Evidence Item > Physical Drive > select the target drive
# 2. Navigate to [root] > $MFT
# 3. Right-click > Export Files > save to evidence folder
# 4. For specific directories, navigate to the directory in the file tree
#    and export the $I30 attribute via the hex viewer

# Using RawCopy for $MFT extraction (bypasses NTFS locks)
RawCopy.exe /FileNamePath:C:\$MFT /OutputPath:C:\Evidence\

Parsing Tools & Analysis

Parsing with Indx2Csv

:: Extract INDX pages from a forensic image using icat (TSK)
:: First, find the MFT entry number for the target directory
ifind -n "Users/CFO/Documents/Meridian Partners" /evidence/disk.raw

:: Output: 48291 (example MFT entry number)
:: Extract the $INDEX_ALLOCATION attribute (type 0xA0)
icat -o 2048 /evidence/disk.raw 48291-160 > /analysis/meridian_i30.bin

:: Parse with Indx2Csv
Indx2Csv.exe /InputFile:C:\Analysis\meridian_i30.bin /OutputFile:C:\Analysis\meridian_i30.csv

:: The CSV output includes columns:
::   FileName, FileSize, ParentMftRef, CreatedTimestamp,
::   ModifiedTimestamp, MftModifiedTimestamp, AccessedTimestamp,
::   IsSlackEntry (TRUE/FALSE)

Parsing with The Sleuth Kit (fls)

# List all files (including deleted) in a specific directory
# -r = recursive, -d = deleted entries only, -p = full path
fls -rdp -o 2048 /evidence/disk.raw 48291

# Output (deleted entries prefixed with *):
# r/r * 48305:  Users/CFO/Documents/Meridian Partners/Meridian_Invoice_Q3_2025.pdf
# r/r * 48306:  Users/CFO/Documents/Meridian Partners/Meridian_Wire_Oct.pdf
# r/r * 48312:  Users/CFO/Documents/Meridian Partners/Meridian_PO_4419.docx

# Generate a bodyfile for timeline analysis
fls -rd -m "C:" -o 2048 /evidence/disk.raw > /analysis/i30_bodyfile.txt

# Convert bodyfile to timeline with mactime
mactime -b /analysis/i30_bodyfile.txt -d > /analysis/i30_timeline.csv

Python INDX Record Parser

import struct
import datetime

def filetime_to_dt(ft):
    """Convert Windows FILETIME (100-ns since 1601-01-01) to datetime."""
    if ft == 0:
        return None
    return datetime.datetime(1601, 1, 1) + datetime.timedelta(microseconds=ft // 10)

def parse_indx_page(data):
    """Parse a 4096-byte INDX page and extract index entries."""
    magic = data[0:4]
    if magic != b'INDX':
        return []

    # Index entry area starts at offset 0x18 + value at 0x18
    entry_offset = 0x18 + struct.unpack_from('<I', data, 0x18)[0]
    entry_size   = struct.unpack_from('<I', data, 0x1C)[0]
    alloc_size   = struct.unpack_from('<I', data, 0x20)[0]

    entries = []
    pos = entry_offset
    while pos < 0x18 + alloc_size:
        entry_len = struct.unpack_from('<H', data, pos + 8)[0]
        if entry_len == 0:
            break

        flags = struct.unpack_from('<I', data, pos + 0x0C)[0]
        if flags & 0x02:  # Last entry marker
            break

        # Extract $FILE_NAME fields
        mft_ref    = struct.unpack_from('<Q', data, pos)[0] & 0xFFFFFFFFFFFF
        parent_ref = struct.unpack_from('<Q', data, pos + 0x10)[0] & 0xFFFFFFFFFFFF
        created    = filetime_to_dt(struct.unpack_from('<Q', data, pos + 0x18)[0])
        modified   = filetime_to_dt(struct.unpack_from('<Q', data, pos + 0x20)[0])
        real_size  = struct.unpack_from('<Q', data, pos + 0x40)[0]
        name_len   = struct.unpack_from('<B', data, pos + 0x50)[0]
        name_ns    = struct.unpack_from('<B', data, pos + 0x51)[0]
        filename   = data[pos + 0x52 : pos + 0x52 + name_len * 2].decode('utf-16-le')

        is_slack = pos >= (0x18 + entry_size)  # Beyond active entries = slack

        entries.append({
            'mft_ref': mft_ref, 'parent': parent_ref,
            'filename': filename, 'size': real_size,
            'created': created, 'modified': modified,
            'slack': is_slack
        })
        pos += entry_len

    return entries

Sample Output — Slack Entry Recovery

Source      MFT Ref  Filename                                  Size        Created              Modified             Slack
INDX #12   48305    Meridian_Invoice_Q3_2025.pdf               284,672     2025-07-14 09:31:02  2025-07-14 09:31:02  [SLACK]
INDX #12   48306    Meridian_Wire_Oct.pdf                      156,288     2025-10-02 14:18:44  2025-10-02 14:18:44  [SLACK]
INDX #12   48312    Meridian_PO_4419.docx                      89,344      2025-09-11 11:05:17  2025-09-11 11:05:17  [SLACK]
INDX #14   48401    Apex_Wire_Confirmation_Sept.pdf             192,000     2025-09-18 16:42:33  2025-09-18 16:42:33  [SLACK]
INDX #14   48402    Apex_Invoice_2025-08.pdf                   341,504     2025-08-22 10:11:09  2025-08-22 10:11:09  [SLACK]
INDX #18   48510    Stratos_Consulting_Agreement.pdf           445,184     2025-06-03 08:55:21  2025-06-03 08:55:21  [SLACK]
INDX #18   48511    Stratos_Payment_Schedule_Q2.xlsx           72,448      2025-06-03 09:01:48  2025-06-03 09:01:48  [SLACK]

Retention & Persistence

$I30 slack space retention is fundamentally different from time-based artifacts like SRUM (30–60 days) or Prefetch (last 1,024 entries). $I30 entries persist until the specific INDX page position is overwritten by a new directory entry. This is not time-based — it depends entirely on directory activity.

Anti-Forensics Resilience

$I30 directory index slack is one of the most resilient forensic artifacts on an NTFS volume. Every widely distributed tool that claims to “securely delete” a file operates on the file’s data content and MFT record. None of them zero the 4,096-byte index pages of the parent directory.

MITRE ATT&CK Detection Mapping

$I30 analysis provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Study

References

1. Joakim Schicht, “Indx2Csv — NTFS $I30 Index Parser” — https://github.com/jschicht/Indx2Csv
2. Flatcap, “Linux-NTFS Documentation — Directory Index” — https://flatcap.github.io/linux-ntfs/
3. Eric Zimmerman, “MFTECmd — MFT and Directory Entry Parser” — https://ericzimmerman.github.io/
4. FireEye (Mandiant), “INDXParse — NTFS Index Record Parser” — https://github.com/williballenthin/INDXParse
5. Brian Carrier, “The Sleuth Kit — File System Forensic Analysis” — https://sleuthkit.org/
6. SANS Institute, “NTFS $I30 Index Attributes and Slack Space for Digital Forensics” — https://www.sans.org/blog/
7. 13Cubed, “NTFS Directory Indexing — $I30 Forensic Analysis” — https://www.13cubed.com/
8. ForensicArtifacts.com, “Windows NTFS $I30 Artifact Definition” — https://github.com/ForensicArtifacts/artifacts
9. Microsoft, “NTFS Technical Reference — Index Attributes” — https://learn.microsoft.com