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.