NTFS Forensics: The Master File Table & Recovering Deleted Files

Prerequisites

• DFA-K002: Forensic Imaging

Why This Lesson Matters

When someone deletes a file on Windows, the file does not disappear. The operating system marks the space as available and removes the directory entry — but the data stays on disk until it is overwritten. The NTFS Master File Table keeps a record of every file that ever existed. Knowing how to read it is the skill that turns "the file was deleted" into "the file was deleted at 14:32 UTC and here is its content."

1. NTFS Overview

NTFS (New Technology File System) is the standard file system on Windows. Every piece of information about a file — its name, size, timestamps, and content — lives in the Master File Table (MFT).

Analogy: The MFT is a library card catalogue. Every file has a card (MFT record) that describes where the book (file data) is shelved. When a librarian "removes" a book, they pull the card — but if the book is still on the shelf, you can find it if you know where to look.

2. MFT Record Structure

Each MFT record is 1,024 bytes. It contains attributes — named sections each with a specific purpose.

2.1 MACB Timestamps

NTFS stores four timestamps per file, in both $STANDARD_INFORMATION and $FILE_NAME:

Timestomping: Attackers modify $STANDARD_INFORMATION timestamps with tools like Meterpreter's timestomp to make files look old. But $FILE_NAME timestamps are much harder to modify (requires kernel-level access). If $STANDARD_INFORMATION and $FILE_NAME timestamps differ significantly, the file was probably timestomped.

# View timestamps with The Sleuth Kit
istat -o 2048 disk.img 42    # MFT record number 42
# Shows both $STANDARD_INFORMATION and $FILE_NAME timestamps
# Compare them — large discrepancy = possible timestomping

3. Resident vs Non-Resident Data

Small files (< ~700 bytes) store their content directly inside the MFT record — this is called resident data. Larger files store a pointer to data runs on disk — non-resident.

This matters because: - Resident file content can be extracted directly from the raw MFT - Non-resident files need their data runs followed to reconstruct the content - Deleted non-resident files may still have recoverable data if the data runs were not yet overwritten

# Parse the MFT and extract all resident $DATA attributes
python3 -c "
import struct, sys

with open('$MFT', 'rb') as f:
    while True:
        record = f.read(1024)
        if not record or len(record) < 1024: break
        if record[:4] != b'FILE': continue
        # scan for $DATA attribute (type 0x80)
        offset = struct.unpack_from('<H', record, 20)[0]   # attr offset
        while offset < 1024 - 8:
            attr_type = struct.unpack_from('<I', record, offset)[0]
            attr_len  = struct.unpack_from('<I', record, offset+4)[0]
            if attr_type == 0xFFFFFFFF: break
            if attr_type == 0x80:       # $DATA
                resident = record[offset+8]  # non-resident flag
                if resident == 0:            # resident
                    data_len = struct.unpack_from('<I', record, offset+16)[0]
                    data_off = struct.unpack_from('<H', record, offset+20)[0]
                    print(record[offset+data_off : offset+data_off+data_len])
            if attr_len == 0: break
            offset += attr_len
"

4. Navigating the File System with The Sleuth Kit (TSK)

TSK is the open-source toolkit underlying Autopsy. Its command-line tools give you direct access to NTFS structures.

# List all files including deleted (marked with *)
fls -r -o 2048 disk.img
# Output:
# r/r 42:   Documents/report.docx
# r/r * 87: Temp/malware.exe         ← * = deleted
# d/d 5:    System Volume Information

# Get MFT record details for file 87
istat -o 2048 disk.img 87
# Shows: timestamps, size, data runs, allocated/not-allocated

# Recover the deleted file content (works if data not yet overwritten)
icat -o 2048 disk.img 87 > recovered_malware.exe

# Hash the recovered file
sha256sum recovered_malware.exe

4.1 Finding the Partition Offset

The -o 2048 flag specifies the partition start sector. Find it with:

mmls disk.img
# Output:
# DOS Partition Table
# Offset Sector: 0
# Units are in 512-byte sectors
# Slot  Start       End         Size        Description
# 000: -----       0000000000  0000000001  Primary Table (#0)
# 001: 000:000     0000000000  0000000000  Unallocated
# 002: 000:001     0000002048  0001026047  NTFS (0x07)    ← start = 2048

5. File Carving: When the MFT is Gone

File carving recovers files by their content signatures (magic bytes) rather than filesystem metadata. Use this when: - The MFT was intentionally wiped - The partition table was destroyed - You are working with unallocated space only

# Photorec: recovers 400+ file types from raw disk images
photorec disk.img
# Creates /recup_dir.1/, /recup_dir.2/ etc with recovered files

# Scalpel: pattern-based carver with configurable signatures
scalpel -o /cases/IR-001/carved/ disk.img
# Edit /etc/scalpel/scalpel.conf to enable/disable file types

# Bulk extractor: extracts specific patterns (emails, URLs, credit cards)
bulk_extractor -o /cases/IR-001/bulk/ disk.img

6. Common Mistakes

Mistake 1: Assuming a deleted file is gone. Deletion marks space as available — it does not erase data. Until overwritten, the content is recoverable. Always search for deleted files before concluding data was destroyed.

Mistake 2: Trusting timestamps without checking for timestomping. $STANDARD_INFORMATION timestamps are trivially modified by user-space tools. Always compare them against $FILE_NAME timestamps. Discrepancies suggest manipulation.

Mistake 3: Recovering a file and not hashing it. A recovered file must be hashed immediately. The hash is your proof that the content you are analysing is exactly what was on the disk.

7. Practice Exercises

1. fls -r -o 2048 disk.img shows: r/r * 127: Users/alice/AppData/Local/Temp/payload.exe. What does the * mean? What command recovers the file?

2. istat shows that file 127 has $STANDARD_INFORMATION timestamps all dated 2020-01-01, but $FILE_NAME shows 2026-06-08. What does this suggest? What tool or technique caused this?

3. Describe the difference between file recovery using icat and file carving using Scalpel. When would you use each?

8. Lab

Assessment mode: flag

challenge_spec_id: 330 — NTFS MFT entry analysis

You are given a raw MFT record binary file.

Task: 1. Identify the $FILE_NAME attribute and extract the filename 2. Locate the $DATA attribute — it is resident 3. The resident data contains the flag in PREFIX{...} format

9. Framework Alignment

10. Further Reading

• The Sleuth Kit (TSK) documentation — https://sleuthkit.org/sleuthkit/docs.php
• "File System Forensic Analysis" — Brian Carrier — The definitive NTFS reference book
• MFT Forensics — SANS — Practical NTFS artefact guide available as a free reading room paper

["Describe the purpose of the MFT and identify the five key NTFS attributes by type code and function", "Use fls to list deleted files in an NTFS disk image, istat to inspect an MFT record's timestamps, and icat to recover a deleted file's content", "Detect a timestomping attack by comparing $STANDARD_INFORMATION and $FILE_NAME timestamps from the same MFT record and explain what a discrepancy indicates"]

Prerequisites → Why this matters (library card catalogue analogy) → NTFS and MFT overview → MFT record structure (attributes table) → MACB timestamps and timestomping → Resident vs non-resident data → TSK navigation (fls, istat, icat, mmls) → File carving (Photorec, Scalpel) → Common mistakes → Practice exercises → Lab (flag, spec 330) → Framework alignment → Further reading