Deleting a file from a computer does not always mean the complete disappearance of information about it. Its name, location, timestamps, and other metadata may remain in the file system. Thanks to this, specialists can determine which files were previously located on the device and what actions were performed with them.
Such data is an important source of information when analyzing computer security incidents, recovering deleted objects, and investigating digital traces.
Employees of the Malicious Code Research Center of the State Technical Service conducted research to study file data storage mechanisms in Windows operating systems. During the study, the structure and contents of the Master File Table (MFT) were examined, as well as the specifics of information persistence after file deletion.
The Master File Table (MFT) is the primary structure of the NTFS file system, which is used by default in Windows operating systems. The MFT stores information about all files and folders located on the disk. A separate record is created for each object, containing key information about the file. After a file is deleted, its record remains in the MFT for some time, which makes it possible to recover the deleted data.
An MFT record consists of several attributes. At the beginning is the Header (FILE Record Signature), followed by the $STANDARD_INFORMATION (0x10) attribute, which contains timestamps and file attributes, including access permissions. The $FILE_NAME (0x30) attribute stores the name of the file or directory, as well as a reference to the parent directory. The $DATA (0x80) attribute contains the file data or references to the disk area where it is located. If the file size is less than 700 bytes, its data can be stored directly within the MFT record.
Figure 1. MFT record structure in NTFS
Structure of an MFT Record
Each attribute consists of two parts: a Header and Content. The header has the same structure for all attributes and contains information about the attribute type, its size, and name. The content depends on the attribute type and can vary in size.
Attribute data in NTFS can be stored in two ways:
A resident attribute is stored directly within the MFT record alongside its header. This method is suitable only for small attributes.
A non-resident attribute is stored outside the MFT record in disk clusters.
If an attribute is resident, its data is located immediately following the header. If an attribute is non-resident, the header contains information about where its data is located on the disk.
Analysis of the $MFT File in FTK Imager
Figure 2. NTFS image in FTK Imager
Figure 2 shows an image of the NTFS file system in FTK Imager. The left side of the window displays the Evidence Tree, showing the disk image, the NTFS partition, and its main elements. The lower left pane displays basic volume properties, including the Volume Serial Number used for unique identification, while on the right, the NTFS signature is highlighted in hexadecimal representation, confirming the file system type.
Figure 3. $MFT file in FTK Imager
Figure 3 shows the location of the $MFT file in the root directory of the NTFS file system. The Evidence Tree pane shows navigation to the volume's root directory ([root]), which contains NTFS system files. The file list displays the $MFT file, while the properties panel lists its primary characteristics, including object type, file size, and the Start Cluster number, which defines where file storage begins on the disk.
Figure 4. MFT record in hexadecimal representation
Figure 4 shows an MFT record in hexadecimal representation. At the beginning of the record is the byte sequence 46 49 4C 45, which corresponds to the ASCII string FILE and serves as the MFT record signature. At the end of the record, the sequence FF FF FF FF is highlighted, indicating the end of the MFT record. In modern Windows versions, file content is not preserved in the record's unallocated area after being moved out of an MFT record. Instead, unallocated space is filled with zero bytes (\x00).
Analysis of Residual MFT Data
Each MFT record has a fixed size of 1024 bytes. It stores information about a file or directory. If directory data is small, it is stored directly within the MFT record. When the amount of data grows and no longer fits, the data is moved to another location on the disk, leaving a reference to its location in the MFT record. After files are deleted or directory information is moved, part of the metadata may remain in the unused area of the MFT record, known as MFT Slack Space. Information regarding file names, locations, and other metadata can persist in this area. This data makes it possible to establish that a file previously existed in the system and was located in a specific directory, even if the file itself has been deleted.
Figure 5. The analyzed test directory
To investigate residual MFT data, a directory named test was created containing three files: 1a.txt, 2a.txt, and 3a.txt (Figure 5). Since the directory is small, information about its contents is stored directly in the $INDEX_ROOT attribute of the MFT record. Figure 6 displays the file index entries containing their primary metadata, along with the end-of-index entry signature FF FF FF FF.
Figure 6. MFT record before deleting the file 3a.txt
Figure 7. MFT record after deleting the file 3a.txt
After deleting the 3a.txt file, the MFT record for the test directory was re-examined in Figure 7. Analysis revealed changes in the metadata fields of the $INDEX_ROOT attribute, indicating an update to the directory index structure. However, the entry for 3a.txt was partially preserved in the binary data of the MFT record. Between the end-of-index signatures (FF FF FF FF), residual data (MFT Slack) remains, containing part of the deleted file's metadata.
MFT Analysis Using MFTECmd
Figure 8. MFT record in MFTECmd
The MFTECmd utility was used to analyze the $MFT file. Figure 8 shows record 0, which corresponds to the $MFT file. The InUse value in the Flags field indicates that the record is in use by the file system. An IsFree value would mean that the record is unallocated and the file or directory was deleted, though its metadata might still persist. For the $MFT file, the Hidden and System attributes are set, indicating that it is a hidden NTFS system file and is not visible to the user during normal browsing. The STANDARD_INFO and FILE_NAME attributes are also displayed, containing basic information about the $MFT system file.
Four timestamps are stored in the $STANDARD_INFORMATION attribute. They are referred to as MAC(B) timestamps:
- Modified: The time of the last modification of the file content. This value updates when a document is saved. It does not change when renaming or moving a file.
- Accessed (Last Accessed): The time the file was last accessed. It updates when a file is opened or read. In modern Windows versions, updating this timestamp is often disabled, so it is not always accurate.
- Changed (Record Modified): The time of the last modification to the MFT record. This timestamp updates when file metadata changes, such as access rights, attributes, or hard link counts. It is not the file creation time.
- Birth (Created): The file creation time on this NTFS volume. When copying a file, this reflects the time of copying rather than the creation date of the original file.
The Birth time is not stored in all file systems; this timestamp exists only in NTFS. Each file in NTFS contains eight timestamps: four are in the $STANDARD_INFORMATION attribute, and another four are in the $FILE_NAME attribute.
Figure 9. MFT record in MFTECmd
Figure 9 displays the DATA attribute of the $MFT file. The value Resident: False indicates that the file contents are not stored directly within the MFT record, but are placed in separate disk clusters. Their location is defined by the NTFS Data Runs list (DataRuns Entries), which specifies the offsets and number of allocated clusters for storing the file's data. The presence of multiple Data Runs entries indicates that the file data is fragmented across several disk regions.
Figure 10. MFT timestamps in Timeline Explorer
Figure 10 illustrates Timeline Explorer, where two columns are displayed for each timestamp type: Created, Last Modified, Last Record Change, and Last Access. Columns ending in 0x10 contain values from the $STANDARD_INFORMATION attribute, while columns ending in 0x30 contain values from the $FILE_NAME attribute.
$STANDARD_INFORMATION timestamps are accessible via the Windows API and are displayed, for instance, in Windows Explorer. $FILE_NAME timestamps are not directly displayed by built-in Windows tools and are typically used by the NTFS file system itself.
Some of the 0x30 columns remain empty. This means that the timestamp value in the $FILE_NAME attribute matches the value in the corresponding $STANDARD_INFORMATION (0x10) column. Discrepancies between them may indicate timestamp manipulation (timestomping). However, such differences are not proof of timestomping on their own, as they can also occur during normal Windows operations.
Conclusion
Throughout the examination of the MFT, its structure, key NTFS record attributes, and file metadata storage specifics were studied. Practical analysis using FTK Imager, MFTECmd, and Timeline Explorer made it possible to examine the contents of the $MFT file, trace record changes following file deletion, and identify the persistence of residual data within MFT Slack Space. Thus, the analysis demonstrated that the MFT is an essential source of information regarding files, directories, and file system events, making it a primary object of investigation.
