Saturday, January 22, 2011

Fun and games with Windows FILETIME and how to efficiently detect timestamp alterations

A student recently asked me some fairly specific questions on how to manually calculate the FILETIME value for a specific date. For the purposes of learning, we went through the manual process of taking a specific date and then calculating the equivalent FILETIME value, not something I recommend.

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.

6 comments:

davehull Saturday, 22 January, 2011  

Great explanation, thank you for the post. In my testing with timestomp, I found it could be used to clone time stamps from existing files, to set times to arbitrary values and to wipe time stamps.

In all but the last case, timestomp produced 64-bit time stamp values.

It's been a few months since I looked at this, but I did investigate the precision as I'd seen others mention this technique for detecting time stamp manipulation.

welshie Sunday, 23 January, 2011  

Great post Lance.

Anonymous Sunday, 23 January, 2011  

A related issue is sorting file-related information by time: is the sorting done on the actual 64-bit value, or is the sorting done on the string that is displayed (which may affected by user preferences)?

In the second case, sorting will not necessarily preserve actual time order, and the item that ends up first in a sequence having the same displayed time stamp is not necessarily the first in time.

John McCash Tuesday, 01 February, 2011  

It might be useful to modify the script to check for files with exact duplicate timestamps. I've seen a number of attackers just change the timestamps of their tools to be the same as kernel32.dll, for instance.
John

John McCash Tuesday, 22 February, 2011  

Hey Lance! Any chance you could do up a script to check for any currently allocated files which have Filename Creation Times between specified values? I'm doing a lot of malware investigations, and I find the Filename Creation Time to be a much better indicator of when a file was created than the Std Info Attribute Creation Time, which is much easier for an attacker to alter. The Guidance script I usually use for this processes the whole disk, and creates a bookmark for every file, which I then have to sort through.
Thanks
John

David Kovar Wednesday, 23 February, 2011  

Greetings,

analyzeMFT does report fraction of a second time values. It also has a switch that turns on flagging MFT entries where the time has no fractional value. This was added at the request of various malware analysts.

-David

Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles