The Forensic Value of MFT Slack Space in Modern Windows Systems
Slack space within the MFT is a largely unexplored, hidden part of the NTFS file system, often overlooked by digital forensics software. However, it holds critical data for forensic investigations. This blog explores MFT slack space and provides practical information on how to leverage it in investigations.
Introduction
In the NTFS file system, the Master File Table (MFT) is a critical structure that stores a significant portion of the file-system metadata and also the content of small files. Each file in the file system occupies at least one record in the MFT, which contains the information associated with it.
An MFT record is typically 1024 bytes in size. While this may not seem like much, it is sufficient for most files and in many cases, a substantial part of this space remains unused. This unused disk space within the MFT is referred to as MFT Slack Space. Unlike File Slack Space (often simply called “slack space”), MFT slack space is not usually exposed by digital forensics software.
In recent versions of Windows, the file system actively overwrites MFT slack space, making certain residual data that existed within it on older Windows systems unavailable in modern systems. Does this mean MFT slack space is irrelevant for forensic analysis of modern Windows Systems? Not quite.
File metadata of deleted – and even securely wiped files – can still be found in MFT slack space, even on modern Windows 10 and 11 systems. Recovery of this file metadata has proven invaluable during real-world incident response engagements, but unfortunately, it is not supported most publicly available digital forensics tools and often has to be done manually.
This blog post examines MFT slack space in both legacy and modern Windows systems, detailing the types of recoverable data, demonstrating relevant tools and techniques for analysis, and emphasizing its importance in modern Windows forensic investigations.
File Content in MFT Slack Space
MFT slack space may contain remnants of a file’s content from an earlier point in its lifetime. On older Windows systems, such as Windows XP and Windows 7, these remnants can sometimes be recovered long after the file itself is deleted, or even securely wiped.
To demonstrate this, I have created an empty text file named File.txt on a Windows 7 virtual machine and added the following content to it:
Using istat from The Sleuth Kit, the file is shown to have four attributes. The last attribute, $DATA, stores the file’s content. Since the content is only 367 bytes, the $DATA attribute is resident – meaning that the content is stored directly inside the file’s MFT record:
Examination of the file’s MFT record in raw binary format reveals the file’s content (highlighted in red), residing between the record header (‘\x46\x49\x4C\x45’ marked in blue), and the record end signature (‘\xFF\xFF\xFF\xFF’ marked in green):
Next, I appended the rest of the poem to the text file:
This caused the file size to grow to 7,003 bytes (~7 KB), exceeding the MFT record’s 1024-byte size limit. As a result, the $DATA attribute has become non-resident, and the file content was relocated to two disk clusters (409704 and 414961) outside the MFT:
Examining the binary data now, the record end signature has shifted upwards, indicating that the record has shrunk in size – it no longer stores the file content. While the new file content now resides outside of the MFT, most of the old resident content was not overwritten, and can still be found below the record end signature – in the unused, slack area of the record:
This residual content in MFT slack space may persist even after the file has been deleted and its allocated disk clusters have been overwritten. This highlights the forensic value of MFT slack space analysis on older Windows systems.
A Change in Behavior in Newer Windows OS versions
When repeating this test on a more recent Windows version, NTFS exhibits different behavior. On a Windows 10 virtual machine, as file content grows and moves out of the MFT, no residual data remains in the slack area of the file’s MFT record. Instead, the slack area is filled with NULL bytes (\x00):
File Metadata in MFT Slack Space
Like files, directories also have records in the MFT. A directory’s MFT record stores information and metadata about the files it contains. For smaller directories, this data is stored directly within the MFT. Once it grows beyond the 1024-byte limit, this data is moved out of the MFT.
When directory information is stored outside the MFT, it is sometimes inaccurately referred to as “$I30 files”, and some forensics tools can extract and parse it. However, when directory information is resident within the MFT, it is typically not exposed by forensics software.
File metadata that is resident within a directory’s MFT record may end up in the slack area of the record when files are deleted or moved out of the directory. This residual file metadata in MFT slack space can be recovered and used to prove a file existed on a system, in a specific directory.
Through research and incident response engagements, we have found that in MFT records of directories, residual data in the slack area of the record is preserved across all Windows OS versions, including Windows 10 and 11. To demonstrate this, I have created an empty directory named ‘Files’ on a Windows 10 virtual machine and created three text files inside it:
Since the directory only contains three files, the directory information is small enough to be stored in the MFT directly. Examination of the binary data of this directory’s MFT record reveals entries for the three text files, highlighted in different colors for clarity. These entries are called index entries, and they contain file metadata – including the filename, file size and a full set of MACB (modified, accessed, entry-change, and born) timestamps for each file in the directory:
Next, I deleted “3.txt” and examined the directory’s MFT record again:
The record shrank in size, causing the record-end signature (marked in green) to move upwards. The previous record-end signature (marked in grey) was preserved. Between these two end-signatures lies residual data from the entry of “3.txt”, which no longer exists in the file system.
While a part of this index entry was overwritten, the file metadata it contained is still intact – including the filename, file size and the full set of timestamps.
Analysis Approaches
Parsing the MFT
Two notable open-source MFT parsers – Eric Zimmerman’s MFTECmd and Maxim Suhanov’s dfir_ntfs – are capable of recovering file metadata from MFT slack space. These tools go over the record of every single directory in the file system, which is obviously not possible to do manually.
However, these tools are not without limitations. Directory entries in MFT slack space are often partially overwritten, making it challenging to reliably identify and recover the file metadata within them. Different tools approach this challenge in different ways, with varying levels of success.
Tool Comparison: MFTECmd vs. dfir_ntfs
Running MFTECmd in debug mode against the MFT extracted from the testing virtual machine used earlier, we observe the following output for the MFT record of the “Files” directory:
MFTECmd detects a “possible slack index entry”, and only outputs the filename – “3.txt”.
On the other hand, dfir_ntfs – as of version 1.1.19 – is able to recover the file name, the full set of timestamps and the file size from this entry as well. This is attributable to Suhanov’s November 2024 update, which improved the detection mechanism for partially overwritten entries like this one:
Manual Analysis
For a single, specific directory of interest, manually analyzing the slack area of its MFT record using a hex editor is a feasible approach. This method has proven invaluable during real-world incident response engagements, allowing us to recover critical information from MFT slack space that, at the time of writing, is not outputted by publicly available digital forensics tools.
As an example, consider this partially overwritten MFT record for a malicious ‘iexplore.exe’ executable identified during an incident response engagement. As of this writing, neither dfir_ntfs nor MFTECmd are capable of extracting the timestamps and file size embedded within this entry, which were essential for reconstructing the timeline of the incident:
Keyword Search
Searching a filename of interest, such as “3.txt”, as a Wide Character string in an MFT file is another method for locating residual data in MFT slack space that may not be outputted by your MFT parser. However, this method will fail in case the filename itself is partially or completely overwritten.
A keyword search can fail even when a filename is in the allocated space of an MFT record, as a result of NTFS’s fixup mechanism.
Harel Segev, Incident Response Expert. (2025, March 30). The Forensic Value of MFT Slack Space in Modern Windows Systems, Sygnia.
https://sygnia-stg.prpl.global/blog/the-forensic-value-of-mft-slack-space/
Related Resources
By clicking Subscribe, I agree to the use of my personal data in accordance with Sygnia Privacy Policy. Sygnia will not sell, trade, lease, or rent your personal data to third parties.