courses

NTFS Analysis

NTFS metadata files are hidden from users but are among the best sources of digital evidence. Even when using highly automated forensics tools, an examiner must understand what those tools are doing in order to interpret results accurately and explain them in court.

Two reasons to develop this understanding beyond button-pushing:

  1. Hiding information can suggest “consciousness of guilt,” which can refute a suspect’s claim of innocent mistakes or a malware attack. Hiding files requires deliberate effort.
  2. Forensics is a moving target. Windows and its tools will eventually be replaced. A solid theoretical foundation is needed to continuously update your knowledge as technology evolves.

NTFS Metadata Files

$MFT

The first file record in the Master File Table is the $MFT file — the MFT’s entry for itself. All other file records exist as nonresident content of the $DATA attribute of $MFT. By processing the header of that $DATA attribute, you can find the disk locations (cluster addresses) of all other file records.

The $MFT file’s $BITMAP attribute stores the allocation status of every file record: a 1 bit indicates an allocated record; a 0 indicates a free (deleted or never used) record. Deleting a file sets its MFT record’s bit to 0.

The $STANDARD_INFORMATION attribute of the $MFT file stores the date and time the file system was created, and is not updated during normal operation. This is relevant if a suspect formatted a drive after a court order was issued to seize it — an attempt to destroy evidence that is itself potentially incriminating.

$MFTMirr

Because so much of NTFS operation depends on the MFT, corruption of the MFT would be catastrophic. $MFTMirr mirrors the first four metadata file records — $MFT, $MFTMirr, $LogFile, and $Volume — and is always stored at the physical midpoint of the volume, far from the primary MFT.

If the start of the MFT is corrupted or overwritten, a recovery tool can find $MFTMirr at the volume midpoint, use it to locate $MFT, use $LogFile to restore the file system to a safe state, and use $Volume for version and status information.

Forensically, $MFTMirr can help recover data from partially overwritten or damaged volumes. Any differences between $MFT and $MFTMirr when both are accessible may indicate deliberate manipulation of the file system.

$Boot

The $Boot file contains the boot sector of the file system. Its nonresident $DATA attribute must be located at sector 0 of the volume, and contains:

A backup copy of the boot sector is sometimes stored in the unused space between the end of the file system and the end of the volume.

$BitMap

The $BitMap metadata file (not to be confused with the $BITMAP attribute of the $MFT file record) defines the allocation status of every cluster on the volume. Its $DATA attribute is a bitmap organized by disk position:

When a file is deleted, its clusters are marked as unallocated in $BitMap — but the data in those clusters is not overwritten. Until those clusters are reused for new data, the deleted content remains recoverable. $BitMap is thus a quick guide to where on the disk to search for recoverable content.

$DATA

Every file has at least one $DATA attribute (possibly empty). Unnamed $DATA is the primary file content. Named additional $DATA attributes are Alternate Data Streams (ADS) — locations where data can be hidden. Directories do not normally have $DATA attributes, but technically can.

$ATTRIBUTE_LIST

$ATTRIBUTE_LIST contains the locations of all other attributes when a file record has too many attributes to fit in a single 1 KB record (non-base file records). Non-base entries contain pointers back to the base entry.

NTFS Indexes

NTFS indexes allow the file system to locate files efficiently. Directory indexes are the most forensically significant. Every directory has an index containing a $FILE_NAME attribute and a pointer to the file record for each file it contains. The index is stored in the $INDEX_ROOT attribute (for small directories) and additionally in $INDEX_ALLOCATION (for large directories).

Indexes implement a B+ tree, enabling files to be sorted and searched efficiently by name or size. Directory indexes must remain balanced — whenever entries are added or removed, the index is re-sorted.

Key Attribute Details

$STANDARD_INFORMATION

Present for all files and directories (except non-base file records). Contains:

Timestamps are critical for reconstructing timelines, but have limitations:

Ownership information can help link a file to a specific user account. However, ownership enforcement is voluntary unless encryption is used. If the file system is mounted by a non-Windows OS, files can be placed anywhere and ownership information can be forged. An investigator can truthfully state only that “someone with access to this computer placed these files here.”

$FILE_NAME

Contains the filename (UTF-16 encoded to support international character sets), the file size, a pointer to the parent directory’s file record, and its own set of timestamps (Created, File Modified, MFT Modified, Accessed).

Forensic significance:

$SECURITY_DESCRIPTOR

Stores the access control list (ACL) and security properties. Determines who is permitted to read, write, or execute the file.

File Deletion in NTFS

Understanding what happens when a file is deleted is essential to understanding how to recover deleted files. The following steps describe what NTFS does when deleting C:\Examples\file1.dat:

  1. Process $INDEX_ROOT and $INDEX_ALLOCATION of the root directory to find the “Examples” directory record. Update the root directory’s last accessed time.
  2. Process $INDEX_ROOT and $INDEX_ALLOCATION of “Examples” to find file1.dat’s index entry and its MFT record number.
  3. Mark file1.dat’s MFT record as no longer in-use. Remove file1.dat from the “Examples” directory index and rebalance the B-tree. Update timestamps on “Examples”.
  4. Clear the “in-use” flag in file1.dat’s file record header and clear the corresponding bit in the $BITMAP attribute of $MFT (the MFT record allocation bitmap).
  5. Process the headers of file1.dat’s nonresident attributes to find the clusters storing its content. Set the corresponding bits to 0 in the $BitMap metadata file (the cluster allocation bitmap).

Throughout all steps, the file system journal ($LogFile) is updated in case of system failure.

Critically, the actual data is never overwritten. The file record is marked unallocated; the clusters are marked unallocated. Until those locations are reused by new files, the content remains physically present on disk and recoverable.

Deleted File Recovery

Deleted file recovery is perhaps the most important application of file system forensics. Deleted files may be relevant both for their contents and because attempting to delete files can constitute illegal destruction of evidence (if the suspect knew they were under investigation).

Recovery When Metadata Are Intact

If the MFT file record has not been reallocated and the content clusters have not been overwritten, recovery is straightforward:

  1. Scan the MFT for file records marked as not in-use.
  2. Read the $FILE_NAME attribute to reconstruct the file’s path.
  3. For small files with resident $DATA, read the content directly from the record.
  4. For large files with nonresident $DATA, follow the pointers in the attribute header to the clusters on disk.

Many forensics tools (such as Autopsy) perform this automatically and display deleted files alongside live files in the directory from which they were deleted. This process is sometimes marketed as “undelete” — it is a trivial operation, and free tools handle it well.

Anti-forensics: Secure Deletion

Standard deletion does not overwrite data. Secure deletion tools explicitly overwrite the clusters corresponding to a deleted file with random data, making recovery much harder. The Gutmann (1996) paper suggested that multiple overwrite passes were needed to defeat magnetic recovery, but this concern applied to 1980s-era MFM/RLL drives. It does not apply to modern high-density drives (post-~2001). NIST SP 800-88 Rev. 1 (2014) states that a single overwrite pass is sufficient for sanitizing modern magnetic media; the multiple-pass approach provides no measurable additional protection on current hardware. Apple’s secure deletion feature historically offered multiple passes but removed it from macOS Sierra (10.12) for SSDs, where overwriting is unreliable anyway.

The presence of secure deletion tools on a suspect’s machine is forensically relevant — it indicates awareness and intentional behavior. For truly sensitive data on drives used for classified purposes, physical destruction is the appropriate disposal method.

File Carving

If the MFT record for a deleted file has been overwritten but the data clusters have not, the file can still be recovered through file carving — searching raw disk sectors for known file signatures without relying on file system metadata. File carving is covered in the next chapter.

Further Reading