T1070.006 - Indicator Removal: Timestomp
MFTGuard is a cross-platform, C-based DFIR tool designed to identify NTFS Master File Table records exhibiting signs of anomalous timestamp behavior.
To accomplish this, MFTGuard parses an entire $MFT binary, record-by-record. As each record is being read, the various attribute timestamp values are compared against pre-defined rulesets. If a record is flagged as potentially suspect, that candidate record is stored in a hash table for further analysis. A structured JSON report is created that contains records that warrant further investigation as well as detailed statistics.
The goal of this project is not to automatically declare a file as a definite result of timestomping. Instead, MFTGuard is an investigative triage tool: it reduces the number of MFT records an investigator needs to examine and provides structured evidence that can be correlated with independent forensic artifacts. This not only saves time and resources, it also allows investigators to perform much deeper analysis of MFT records that are sure to require it.
At the moment, only Windows and Linux environments are supported.
The following are required to build MFTGuard from source:
- C compiler with C11 support
- CMake (tested with version 4.4.2)
CMake is used to simplify the process of configuring and generating build files.
- Clone the repository
git clone https://github.com/natesec/MFTGuard.git
- Create a build directory
mkdir build
- Configure the project and build with CMake
cd build
cmake ..
cmake --build .
The resulting executable will be located in the generated build directory.
MFTGuard takes a raw $MFT binary file as input. You can extract such a file easily with a tool such as KAPE. Once installed, you can use the following command on Windows to extract the $MFT:
kape.exe --tsource C: --target "$MFT" --tdest <output-path>
The resulting $MFT file can be provided to MFTGuard for analysis.
You can use MFTGuard to analyze a raw binary $MFT file with:
MFTGuard.exe -f <$mft> [-s <sector-size> -o <output-file>]
Or:
MFTGuard.exe --file <$mft> [--sector-size <sector-size> --output <output-file>]
You can use the -h or --help options to display the usage menu with examples.
The default Windows sector size is 512. This will be suitable for most Windows machines
After a successful scan, a JSON report file is created with the filename mftguard_report.json by default, or whatever filename is specified.
MFTGuard has a few key features that are implemented in the following order:
- Raw MFT parsing:
Parses NTFS
$MFTrecords directly from binary, validating record structures, signatures, boundaries, and metadata before further analysis. - NTFS USA fixup: Validates USA and restores values to the tail of the specified sector size in-place before record contents are interpreted.
- Attribute parsing:
Walks the attribute list for each record and extracts the
$STANDARD_INFORMATIONand$FILE_NAMEattributes using little-endian readers. - Timestamp analysis:
Compares corresponding
$SIand$FNattribute timestamp metadata using anomaly detection rules, with results stored efficiently in the form of a bitmask. - Statistical analysis:
Collects MFT,
$FN, timestamp relationship, and timestamp delta statistics to provide context for detection and threshold finetuning. - Candidate management:
Uses the
uthashlibrary to store flagged records by MFT record number in a hash table, preserving independent copies of record metadata. - Structured JSON reporting:
Uses the
cJSONlibrary to generate a report consisting of statistics and flagged record metadata by iterating over the candidate hash table. Candidates are serialized incrementally to limit memory usage. - Forensic correlation:
Produces findings primed for forensic correlation. Independent artifacts such as the USN Journal,
$LogFile, Prefetch, Amcache, ShimCache, Windows Event Logs are perfect to compare the JSON report findings against. - Performance:
In testing, MFTGuard was able to processes a Windows 11
$MFTfile containing 826,880 records, through complete analysis and the JSON report generation, in about 10 seconds.
The detection rules triggered by each candidate is stored in the form of a bitmask. Each rule is assigned a unique bit position depending on its place in the enum, allowing multiple detections to be represented by a single integer. In the JSON report, this bitmask can be accessed for an object in the candidate array under the field rule_flags, which can be decoded using the following table:
| Rule | Bit | Decimal |
|---|---|---|
RULE_SI_FN_MISMATCH |
0 | 1 |
RULE_TIMESTAMP_ROLLBACK |
1 | 2 |
RULE_ZEROED_TIMESTAMP |
2 | 4 |
RULE_IDENTICAL_TIMESTAMPS |
3 | 8 |
For example: if
rule_flags= 5, that would be 0101 in binary. The set bits are forRULE_SI_FN_MISMATCHandRULE_ZEROED_TIMESTAMP.
MFTGuard began with a much more ambitious goal: develop a timestomping detection tool that could identify suspicious timestamp manipulation with a very low false-positive rate using nothing but the $MFT binary by itself. As development progressed and the tool was tested against real MFT data, this proved to be unrealistic.
NTFS metadata naturally contains a large amount of variation. Differences in $FILE_NAME and $STANDARD_INFORMATION timestamps can occur for many reasons that aren't at all related to malicious timestamp manipulation. Treating individual timestamp discrepancies as evidence of timestomping produced far too many candidates.
To reduce the false-positive rate, I initially explored increasingly restrictive combinations of timestamp relationships and statistical thresholds in an attempt to reduce this noise. Through testing, the estimated false-positive rate was reduced from approximately 22% to 16%. While this represented an improvement in the behavior of the detection rules, it also demonstrated an important limitation: increasingly complex rules applied to the MFT alone could not reliably distinguish malicious manipulation from legitimate filesystem behavior.
Testing against a clean MFT produced the following results initially:
| Detection Condition | Percentage of Records |
|---|---|
| SI/FN timestamp mismatch | 15.66% |
| Zeroed timestamps | 6.00% |
| Identical timestamps | 11.67% |
Candidate scoring was another attempt to decrease the false-positive rate: performing analysis that required iteration of the hash table with populated candidates. All attempted candidate scoring fell short. While testing a score based on clustered timestamps: 29.96% of all candidates (134,177) were in a cluster of 10,000 or more. Analyzing the parent directory of candidates produced a similar result, although slightly more promising: 978 candidates did not share a parent directory with any other candidate. Overall, the candidate scoring system was not particularly useful and also had a very costly toll when it came to resources and time (both parent directory and timestamp cluster evaluation required iteration).
This changed the direction of the project. Instead of trying to detect timestomping, the tool was redesigned around forensic triage and evidence correlation.
The most promising use of MFTGuard is treating the output as a starting point for investigation rather than a standalone detection system. The resulting report provides detailed data that can be correlated with independent forensic artifacts. Sources such as the USN Journal, $LogFile, Prefetch, Amcache, ShimCache, Windows event logs, Sysmon, LNK files, Jump Lists, and application-specific logs can provide additional context about what happened around the timestamps identified by MFTGuard.
The final design philosophy of the project is:
MFTGuard points the way, independent forensic artifacts reveal what actually happened
The biggest lesson from the project was therefore not how to create a more complicated detection rule set, it was learning where the available evidence stops being sufficient, and designing the tool to work effectively within that limitation.
MFTGuard is intended to assist with the analysis of NTFS timestamp behavior. Its output should not be interpreted as definitive proof that timestomping or general timestamp manipulation occurred.
MFTGuard analyzes information contained within the NTFS Master File Table. It may produce false positives due to legitimate filesystem behavior and the inherent complexity of NTFS metadata. Findings should be validated and correlated with independent forensic artifacts and other available evidence before drawing conclusions.
This project is provided for educational, research, and authorized forensic analysis purposes. Only analyze systems, storage media, and forensic images for which you have appropriate authorization. I will make no guarantees regarding the completeness, accuracy, or suitability of MFTGuard for any particular forensic investigation. The tool should not replace established forensic procedures, independent evidence validation, or professional forensic judgment.
MFTGuard uses the following third-party libraries:
Local copies of the applicable license files are included in the repository under the third_party directory.
Licensed under the MIT License.
Third-party dependencies are distributed under their respective licenses.