Wednesday, February 23, 2011

Time Stomping is for Suckers

OK...So I have been seeing this more lately, so I feel like it's time to post about it again.

Chronological data about the files on a Windows system are stored in something called the Master File Table or $MFT. This is the place that the operating system and various GUI utilities (Insert Forensic GUI Utility of choice) pulls timeline, or MACB times. As a refresher, MACB stands for:

M - Modified
A - Accessed
C - Created
B - Birth

Now...there are two places in the MFT that store this chronological data. One is the $Standard_Information ($S_I) attribute, and the other is the $File_Name ($F_N) attribute. So now you are asking yourself, why are there two places that store this data, and why do I care...well...I will tell you...

The data is stored in two different places because they are accessed by two different parts of the system (loosely). The $S_I is accessed by the OS, various applications, and the user. So, it is able to be modified or stomped. THEREBY " fooling ANY and ALL forensic utilities. ALL OF THEM...since they all pull the chronological data from the $S_I. So, if a file has been modified, and you sort in your little GUI column sorter, the malicious file(s) that has (have) been stomped will be sort in like 2008, 1969, or whatever date the attacker decided to give it.

Sucks to be you right? Wrong! Sucks to be a crappy tool...not a smart investigator!

Here is why...

While the $S_I attribute is able to be modified by the OS and stuff, the $F_N attribute is not. So what does that mean? It means you can use this hand-dandy little perl script called, ""from none other than the illustrious Harlan Carvey to parse the MFT and just pull out the $S_I and $F_N attributes (Which incidentally, Harlan was nice enough to post on Google Code...THANK YOU HARLAN). Then, when you compare the two values, you can see right away if the MACB times have been modified!

Here is the syntax to use

C:\tools>Perl $MFT_from_suspect_system > ripped_mft.txt

Now if you cat or strings that file, it will look like a bunch of nonsense, so here is what I suggest:

C:\tools> strings ripped_mft.txt | grep -A 6 -B 6 -i filename_you_are_looking_for

This will give you the six (6) lines both before and after the hit in the MFT. The MACB times on the top are from the $S_I attribute, while the ones on the bottom (as indicated by the little "FN" are from the $F_N attribute.

So, if the top does not match the bottom, you have a file that has had its MACB times modified by something. Then you can indicate that, and show that the times on the bottom are the correct ones. Use those in your case timelines.

So you see, Time Stomping is for suckers! You can fool a tool, but you CAN'T fool an investigator.

Well...I guess technically you CAN, but it would have to be an investigator who is relying on the tool to solve his case for him and not his brain. In which case, I would refer to that person as more of a click monkey than an actual Investigator...but I digress...

Happy Hunting!


  1. Cool. Glad to see Harlan has released this code. I have a utility written by Mark McKinnon that will pull $F_N time stamps in bodyfile format suitable for pulling into a Sleuth Kit timeline. I was hoping Mark would get his tool out so it could be added to investigator's tool boxes.

  2. Something important to point out here is that $SIA and $FNA time values are just one element of an examination. The Registry can offer quite a bit of useful information, and a properly constructed timeline can prove even more useful.

  3. Agreed Harlan. Nothing stands alone. This is like a bowl of lucky charms, with slim milk, juice, and toast. It's only part of a well balanced investigation.

  4. Look for more on this very subject at the conferences this summer. I'm polishing a full presentation on using timelines and super-timelines to solve breach cases. The preso will include a live walkthrough using fls, mactime, and Keep an eye out for "I'm your MAC(b) Daddy.

  5. MFT records also have a sequence. So, stomping them would still leave evidence that something is amiss as the new stomped date/time would be out of sequence relative to the surrounding MFT records.

  6. The $F_N attribute is not updated as regularly as the $S_I attribute, so you can say the the file did at one time have those times associates with it, but you can't say that that time is what it was before timestomp changed it. Just a point I wanted to stress.

    Also, another indication of timestomp is the microseconds will be zero. If you are using TSK to build your timeline, you are dropping the microseconds off of all of your times and never noticing that artifact.