My Road to Digital Forensics Excellence

SIA Timestamps and FNA Timestamps in Action

Posted by Paul Bobby on September 2, 2010

There have been many that have pontificated over the difference between the timestamps found in the Standard Information Attribute of the MFT record and the timestamps found in the Filename Attribute of the MFT record. And much like steganography and printer spool files, it’s one of those things you read about in the fiction of everyday forensic practice, but never really experience.

Here is a repeatable experiment that you can try for yourself that shows NTFS weirdness in action as it relates to MFT timestamps.

  1. Format a test partition to NTFS (I used a custom 2gig partition, makes testing quick)
  2. Right click-create new text file – name it test101.txt
  3. Double click test101.txt and add enough random text to make it non-resident
  4. Repeat by creating a second text file – test201.txt and fill it will random text

The below screenshot shows data from Encase after this process


Now for the fun part

  1. Open a command prompt, and
    1. delete test201.txt
    2. rename test101.txt to test201.txt

The below screenshot shows data from Encase after this process


Notice the weirdness? The File Created timestamp of test201.txt is now equal to the File Created timestamp of the recently deleted test201.txt. What happened to the original timestamp of 09/01/10 16:10:27?

Let’s parse out the MFT record for test201.txt

The below are the timestamps from the Standard Information Attribute


They match what is displayed in Encase. And before you crucify Encase – be aware that these timestamps are in fact also used by Windows Explorer, so this is NOT an Encase-ism, it is an NTFS-ism.

The below are the timestamps from the Filename Attribute


Update2: Thanks to Kieth again for some further detail. I am experiencing two issues. One is the Safe Save tunneling mentioned below that explains why the File Created date remained the same. The second is standard NTFS behavior when it comes to renaming files, even on the same volume.

When renaming a file, the FNA timestamps are populated with the values from the SIA timestamps. Then the SIA timestamps are adjusted per the move process. I did not know this. Yay Kieth.

Be careful though, simply saying that the FNA created timestamp is different does not mean that deleting and renaming a file is the only scenario that can explain this behavior. I am simply using this as a repeatable demonstration that NTFS can change SIA and FNA timestamps unexpectedly.

Update: File Tunneling capabilities. This implements the old DOS Safe Save method – my test was done in Vista Sp2 64bit – isn’t it about time Microsoft cuts backwards compatibility somewhat?

Thanks Kieth and Jeff for the Microsoft information.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: