courses

Introduction to File System Forensics

File system forensics is the subfield of computer forensics that deals with evidence related to file system events — file creation, deletion, and duplication. It covers finding hidden files, recovering deleted files, determining creation, modification, and last access times, and determining file ownership. It pertains to the examination and analysis phases of a digital forensics investigation.

It is very difficult to interact with a computer without leaving some kind of record in the file system.

Note that file system forensics is not concerned with file contents — it is concerned with the files themselves: where they are stored, how they are stored, when they were last accessed, and whether deleted or hidden files can be recovered. Operating system forensics and application forensics are separate disciplines.

This course focuses on NTFS (New Technology File System), used by all modern versions of Microsoft Windows, because it is the most commonly encountered file system in practice. Every file system type is different; a forensic examiner should be familiar with all major ones, plus any system they are specifically going to analyze.

Master Boot Record (MBR)

Before NTFS itself, there is the Master Boot Record — a data structure that exists outside the file system and partition structure.

When a computer is powered on, the processor comes online along with the BIOS or UEFI firmware. The firmware searches for a Master Boot Record in the first sector of each connected drive.

The Master Boot Record (MBR) is stored in the first sector of a drive. It contains:

The partition table can describe multiple partitions with different operating systems. The MBR is forensically relevant because some malware modifies it for its own purposes (e.g., bootkits).

Introduction to NTFS

NTFS was developed by Microsoft in 1993. It is used in Windows NT, 2000, XP, Vista, 7, 8, and 10. A successor — ReFS (Resilient File System) — was introduced in Windows Server 2012 but has not yet been widely adopted.

Two notable internal features of NTFS:

Boot Sector

After the boot loader hands off to an NTFS partition, the first thing read is the boot sector. It contains:

Metadata Files

In NTFS, everything is a file — including the metadata files that describe the file system itself. They have the same structure as any other file. Metadata file names begin with $.

File Purpose
$MFT Master File Table — records of every file and directory on the volume
$MFTMirr Mirror of the first critical MFT entries, stored at the volume midpoint for recovery
$LogFile Transaction log for metadata changes; enables recovery from incomplete writes
$BadClus List of bad clusters, so the file system avoids writing to them
. Root directory; the top of the B-tree directory hierarchy
$Secure Database of frequently used access control lists (ACLs)

Master File Table (MFT)

The Master File Table is the heart of NTFS. Every file and directory on the volume has a 1 KB entry (a file record) in the MFT. Each record contains attributes that define the characteristics of the file, including the file data itself if it fits.

The MFT is represented as a hidden file called $MFT in the file system.

MFT File Record Attributes

In NTFS, a file is a collection of attributes stored in its file record. Each attribute has a header (name, size, type) and content. The record is 1 KB, and multiple attributes of the same type are permitted.

Resident vs. Nonresident Attributes

Large files always have nonresident $DATA attributes.

Standard Attribute Types

Attribute Contents
$STANDARD_INFORMATION Owner, creation time, link count, flags (read-only, compressed, encrypted)
$FILE_NAME Filename (UTF-16), parent directory pointer, timestamps, file size
$DATA Actual file contents; every file has at least one
$SECURITY_DESCRIPTOR Access control list (ACL) and security properties
$INDEX_ROOT, $INDEX_ALLOCATION, $BITMAP Implement the B+ tree for directory indexing

Alternate Data Streams (ADS)

NTFS permits multiple $DATA attributes per file record, provided each has a distinct name. The first $DATA attribute is unnamed; any additional ones are called Alternate Data Streams (ADS).

ADS were introduced for compatibility with the HFS file system (macOS). Windows uses them internally to store hidden document properties (e.g., marking files downloaded from the internet). However, they can be abused to hide arbitrary data — including executable code — because:

To access an ADS from the command line:

notepad Public_File.txt:HiddenStream

For example, malware could be stored as an ADS of calc.exe. Task Manager would show only calc.exe, and a hash of the file would match the legitimate calculator binary. An attacker could then execute calc.exe:malware to run the hidden payload.

ADS are detectable by forensics tools such as The Sleuth Kit. They represent a weak form of hiding compared to rootkit-level techniques — but weak hiding is still hiding, and its presence may be relevant evidence.

Non-base File Records

File records have a fixed 1 KB size. If a file has so many attributes (or such a fragmented nonresident $DATA attribute) that their headers no longer fit in a single record, non-base file records are allocated. The base record contains an $ATTRIBUTE_LIST attribute pointing to all non-base records, and each non-base record contains a pointer back to the base.

Encryption

Encryption prevents unauthorized parties from reading private data. For forensic investigators, encrypted files present two options:

  1. Brute-force the key: feasible only if the key is weak or the encryption algorithm is flawed. Against modern algorithms (e.g., AES-256) with strong keys, brute-forcing is computationally infeasible. Using a forensic image of the disk helps, because failed login lockouts can be bypassed by reverting to the image.

  2. Find the key by other means: suspects sometimes write down passwords, reuse account credentials as encryption keys, or store credentials in browser password managers (which forensics tools can often recover). Social engineering is another avenue.

Legal note: It is not settled whether decrypting encrypted files is lawful if the search warrant does not explicitly authorize it. Investigators must ensure their warrant includes a provision for decryption, or the resulting evidence may be ruled inadmissible.

Examining a Disk Image with The Sleuth Kit

The concepts above become concrete when you work on an actual image. The following commands use TSK (see The Sleuth Kit for full coverage).

Step 1 — list partitions and find the NTFS offset:

mmls evidence.dd

DOS Partition Table
      Slot    Start       End         Length      Description
001:  -----   0000000001  0000002047  0000002047  Unallocated
002:  000:000 0000002048  0000206847  0000204800  NTFS (0x07)

The NTFS partition starts at sector 2048. Use this as the -o value for all subsequent commands.

Step 2 — confirm file system details:

fsstat -o 2048 evidence.dd

This shows the NTFS version, cluster size, MFT location, and last mount time — confirm these match expectations before proceeding.

Step 3 — list files including deleted entries:

fls -r -p -o 2048 evidence.dd | head -30

r/r 36-128-3:  $MFT
r/r 37-128-1:  $MFTMirr
r/r * 51-128-1: Users/alice/Documents/report.docx
d/d 52-144-4:  Users/alice/Downloads

The * prefix marks deleted entries. Inode 51 is a deleted file; recover it with:

icat -o 2048 evidence.dd 51 > recovered_report.docx
file recovered_report.docx

Why deleted data is recoverable: deleting a file in NTFS (and most other file systems) only marks its MFT record and data clusters as “available” — it does not zero the underlying sectors. The actual bytes remain on disk until the operating system allocates those clusters for a new file and overwrites them. Until that happens, tools like icat can read them directly by inode number.

Step 4 — check for Alternate Data Streams:

fls -o 2048 evidence.dd | grep ":"

File names containing : are ADS entries. An ADS on an executable or a system file is worth investigating — it may be hiding a payload.

Further Reading