Sunday, February 1, 2009

Detecting timestamp changing utilities

Harlan Carvey recently posted an update on his blog, and he included a link on Time based forensics and it reminded me about a post I wanted to make.

I was just working a case this past week where I ran into some "anti-forensics". Now, some of you know my position on "anti-forensics" and the soapbox I usually climb onto when that word gets brought up. I am not really a subscriber to the word "anti-forensics". There are certainly tools that attempt to make it more difficult to detect wrongdoing, but "anti-forensics"? c'mon.. Anyway I digress….

So in this case, I ran into an attacker who changed some timestamps on some executables to try and hide their presence. The attacker placed the executables in a system folder and named them very similar to legitimate executables (mistake #1). The attacker then used a utility to change the timestamps of the executables to show a creation date in 2001 (mistake #2 & #3). So this is more an "anti-sysadmin" technique than anti-forensics.

As most of you are aware, the $MFT tracks (4) four datestamps, created, accessed, written & entry modified. There are at least two places in each MFT record that that contains these stamps, the Standard Information Attribute (SIA) & the Filename Attribute (FNA). The timestamps from the SIA are the ones EnCase (and all other tools) shows you in the table pane (upper-right). The second set is somewhat redundant. All four timestamps in the FNA are typically stamped with the same date/time that refers to when the file is created on that volume. There are undocumented circumstances as to when the timestamps in the FNA are changed; the most notable one is renaming a file. Anyway, absent those circumstances, when you look at an MFT record of a file, you will typically see the creation date of that file on that volume in the standard place (SIA) and it will be displayed to you in the created column in EnCase. An exception to this is when you CUT and PASTE (aka move) a file from one volume to another. The creation date on the original volume “sticks” and is also used on the new volume. But when a file is copied (aka downloaded, pushed, transferred, etc.) the creation date on that new volume will reflect the date it was copied. This is nothing new and the standard caveats apply here).

Now, when that file lands on the new volume, that second set of timestamps are also initialized with the date it was copied onto the volume. The attacker, trying to by sly, thinks he will change the timestamps so it "blends" in with other files, so he/she uses a tool to alter the timestamps, like "stamp", "filetouch", "timestomp" or any of the other timestamp modifying tools. The tool changes whatever timestamp you want; created, accessed, written or entry modified. But the tool only changes the timestamps in the SIA, not the FNA.

What you have now is what we call a "BIG RED FLAG". You now have a creation timestamp in the SIA that predates the one in the FNA, how is that possible? Now, there are times when this can occur naturally without any malice. The most common is when the file was contained in an archive that preserves the original datestamps. Microsoft CABS are one of those types of archives that can do this so you have to look at the file(s) carefully and the surrounding files to assess "is this normal?".

I did a presentation on this topic a few years ago at the DOD cyber conference. Here are two screenshots that show examples:

Below is an EnScript that will bookmark the timestamps from the SIA and FNA and also write to the console just the created dates for a quick compare. Select whatever files you want the two sets of timestamps from and then run this EnScript, then check the bookmarks:

You can see in the example above that the first set is from the SIA and reference dates in 2006. The second set all show January 15, 2009. This is actually the date this file was created on the volume. In this case I used "filetouch" to set the timestamps back.

Download EnScript here

* Comments on mistakes:

#1 - system folder? This has got to be the first place any forensic examiner will look? how about something interesting? System Volume Information?

#2 - 2001? How many files on a Windows 2003 server have a creation date of 2001???

#3 - setting the timestamp back in the first place. The proceedure I describe above clearly shows the alteration. Hiding in plain sight is a better tactic.


Jason Koppe Sunday, 01 February, 2009  

Is there anything preventing those tools from also modifying the FNA?

Lance Mueller Sunday, 01 February, 2009  

There is no automated tool that I am aware of that has that ability. A hex editor will work! ;) But I suspect the API to get to the datestamps in the FNA is not exposed.

Anonymous Friday, 06 February, 2009  

As far as I know, Microsoft fully exposes MFT in SDK. Just do search on MSDN

Anonymous Tuesday, 03 March, 2009  

Why not just use a digital timestamp (AKA trusted timestamp) like these at to prevent this issue?

Lance Mueller Tuesday, 03 March, 2009  


You're missing the point. We all know tools and tricks tricks to help setup a secure environment in advance. but most of our victims are victims because they don't have these controls in place before something happens. Therefore you have to deal with what you have, and usually its very little in regards to logs or preventative measures.


Hecknoman Wednesday, 25 March, 2009  

I have found this tool to be useful when comparing times in the system folder for an intrusion. I am using EnCase for a current case. I was able to identify a couple of items for further attention.

My only observation is that the bookmarks all appear in individual folders at the top level. I'd like to modify the tool so it prompts you for the name of a Bookmark folder. This would allow me to easily separate items found in the WINNT folder from those found in other folders, for example. I'd also like the option to auto sort items into sub-folders based upon whether or not the two time sets match. For example:

1. I run the tool against WINNT/system32. It prompts me for a folder name. (I choose WINNT-Test).
2. It compares the results of the FNA and SIA and puts matches in a sub-folder called [Match] and items that do not have matching times in a folder called [No Match]. This would allow for quicker processing of the results.

What do you think?

echo6 Monday, 30 March, 2009  

I posted on the EnCase forum asking if this could be could included. No response...Sept 2006!!!

Nice Lance, thanks for the enscript :-)

Anonymous Thursday, 21 May, 2009  

I have had 3 floppy disks looked at by a forensics company, each containing a couple of documents, I have been told all the dates/ times etc are conclusive with the dates/times the documents are said to have been produced and copied on to the floppy disks and there are no inconsistencies with the metedata. Could this still be the case if these had been changed before being put onto the floppy disks. There are no hard drives available.

Anonymous Friday, 26 June, 2009  

I am new to Encase and starting with an used v4.20, no way to buy new license yet. Is it possible to port this Enscript to v4.20?
Thanks and Regards,
Santiago, Chile

Tim Wednesday, 14 April, 2010  

I recently did some experimenting with MS PowerShell and modifying the dates within the $MFT. Indeed renaming a file post system time change changes the created, Modified, and Access FNA dates. It does not change the FNA MFT Modified Date however. Just my two cents. Great Post!

My Post can be found here:


Anonymous Wednesday, 08 December, 2010  

Could the Enscript be modified to have labels by each date? Nothing indicates which date is which. Only by using a file where all four of the SIA dates are different, and then comparing those to what this script produces, can the sequence be determined.

Marty S

ken Saturday, 07 May, 2011  


Can you inspect a flash drive to see if a time stamp has been falsified?


Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles