Fun and games with Windows FILETIME and how to efficiently detect timestamp alterations
During the long manual calculation, it reminded me how precise the FILETIME timestamp value is that is used on NTFS volumes. Lets review what the FILETIME value on NTFS consists of. The FILETIME value represents the number of 100-nanosecond intervals that have transpired since January 01, 1601 at 00:00:00 GMT. To put this into perspective, there are 10,000,000 100-nanosecond intervals in one second. If a person creates a file on January 01, 1601 at 00:00:01hrs, then the value stored on disk will be 0x989680 (10,000,000 decimal). That is extremely precise and I think most of us are aware of this precision, but forget about it since we never see a timestamp displayed in our tool of choice, with that amount of precision.
During my discussion with the student and manually converting the dates on paper, it struck me that there really isn't a forensic tool to show the fraction of a second time value. I then suddenly realized that there also isn't a hacker tool that lets the user specify a fraction of a second when modifying a file's timestamp. All the tools I have seen (filetime.exe, timestomp.exe, etc..) in the past only allows the user to specify a time down to a one-second granularity.
What does all this geek speak mean? Well, if a time manipulation tool was used, then that means the precise FILETIME value that is stored has to be divisible by 10,000,000 (one second) since it is not storing a time value that includes a fraction of one second.
This past week I finally got around to writing an EnScript to manually parse the MFT, since I cannot use the values EnCase shows since they only show a 1-second granularity. Once I was done, I modified a file using a common timestamp manipulation tool and then ran the EnScript against an evidence file with over 100,000 files.
The result? over 25,000 files had at least one timestamp that used a value that was precise only to a second, but no fraction as I expected. After a little thinking, I realized that a file that was once on a FAT partition and then copied to an NTFS partition would not have the precision timestamp normally used by NTFS since FAT is not that precise. After a quick test by taking a file and then copying it from a FAT32 partition to a NTFS partition, I confirmed that the date fields that are passed to the new volume were in fact accurate only to the second. But, I also saw some of the other timestamps, like the created date/time used the exact time the file was created on the NTFS volume when the file was copied and that it used the typical precise FILETIME timestamp.
After a little modification of the EnScript to look and compare multiple timestamp values and a quick run against the same 100,000 file evidence, four files were quickly isolated as being modified. One was the file I modified and three others appeared to be part of a specific application that had been installed with no relation to the file I modified. After manually looking at the MFT record for those other three files, I cannot explain why those specific files have only a one-second resolution timestamp, but there must have been some type of copy process used that lost the precision that is typically used.
The point of this blog post is to discuss and point out that an examiner should be familiar how the time values are stored on NTFS volumes AND the need to examine these dates manually, since many of the common forensic tools do not display the dates with any precision beyond one second, when there is any suspicion of tampering.