NTFS Files Systems

In unix there is a way to determine if file timestamps have been tampered with by looking at the file sequence.

That is almost certainly incorrect. For some particular file system it may be true, but not for 'unix' in general.

I was told you could look at the Master File Table and see if the files were created out of sequence but I'm not sure how to do this or if this is even possible or reliable?

Possibility on the assumption that $MFT records are allocated sequentially, increasing record numbers would mean increasing Create time stamp.

Scope and Reliability … well, that's another qestion. I don't know of any testing and reporting.

There is an alternate method, that compares the $FILE_NAME time stamps with the $STANDARD_INFORMATION time stamps. The latter can be modified with system calls if you have the appropritae privileges, the former have no known method of modification, at least so far. This seems to be a more solid approach, provided that some serious testing goes into the the '$FILE_NAME time stamps don't change' hypothesis.

If you're looking for free tools, just search for 'MFT analysis tools'. Just remember, that you generally don't know if the tools work as they should or not. Using untested tools is not a good idea.

And even if you could what is stopping someone from copying out the entire directory adding and removing files and then use something like Robocopy to move all the files back with the same meta data which I'm sure is what he did.

File permissions for once thing. If you are asking what would make that kind of procedure impossible to detect, … it depends on the tool. You need to analyze it before you decide. Does Robocopy modify $FILE_NAME time stamps, for instance?

Greetings,

analyzeMFT, though free, has been pretty extensively tested, though as always, you should verify for yourself.

http//www.integriography.com/

It has an anomaly detection option which tries to detect files that have been timestomped. I've been meaning to do some research into serial numbers along the lines of what you're asking but haven't done much with it yet. I'm quite willing to update the code if you find anything appropriate.

-David

Lance Mueller had a good write up on his blog that should be able to help you out. Here is the link.

http//www.forensickb.com/2011/02/custom-filetime-dateclass-to-display.html

Thanks for all your tips. I followed up with your suggestion to analyze the $MFT file and followed up by reading Brian Carrier book which helped allot.

All of the dates in the MFT appear to be valid at first until you look at the MFT entry date and noted the following behavior

1) All the files in question have an invalid Std MFT entry date
2) All the files in the folders(4) with the content we are looking at have invalid Std MFT entry dates
3) All other files on the system have valid STD MFT entry dates

Which leads me to believe someone used some type of tampering tool to add files and update the meta data. I'm pretty sure we would have noticed the drive taken out so I'm sure he used a Unix tool to do this. If I can duplicate the behavior then the dean will be so happy.

SequenceNumber.

Ok been updating my knowledge on hard drives for most of the week and it looks like NTFS allocation algorithm and applying meta timestamp differs between OS versions.

The files system I'm looking at is a VISTA 64 bit. But I've also studding similar file creation patterns for 64 bit XP pro, 32 bit XP home and 64 bit Windows 7. I'm still looking for a pattern in Vista but haven't found anything.

South Korea had a really good proof of concept for meta tag allocations for different versions of Windows OS. I will see if I can find it.

1) All the files in question have an invalid Std MFT entry date

Invalid how?

Which leads me to believe someone used some type of tampering tool to add files and update the meta data.

A bit difficult to test that hypothesis, isn't it?

Folders and files can get odd timestamps by fairly natural means. For example, if an installation archive either was built with poor time stamps, or is unpacked by software that doesn't do the right thing, the resulting files can get odd-looking timestamps – I remember the MetaSploit distribution did, at least some releases back. (Haven't checked it recently.)

$analyzeMFT output gave me some invalid dates but then I used FTK as a second tool to veryify the timestamps. Anything that says Invalid Date really means a date that is not possible.

There are about 0 timestamps that are used for 3000
2027‐05‐19 053359.915084200 ‐0600 returns invalid.
1973‐12‐31 065116.261799000 ‐0700 returns invalid

That being said if I found a proof of concept

If Std Entry Date is less then File Entry date the timestamps are unreliable.

I also know he was searching tools to backup and recover files including meta data. There are lots of tools to do this XCopy, Unix Touch, Rsync to name a few. Just testing some of the tools now.

Kovar, I was trying to figure out your Number columns.

I get that RecordNumber is a one to many to ParentFileRecNumber

Does that mean each ParentFileRecNumber has a ParentFileRecSeqNumber which is a one to many [SequenceNumber]

This is how I'm thinking your program would relate to NTFS file structure.

ParentFileRecNumber would be a room
ParentFileRecSeqNumber would be a cabinet in the room
SequenceNumber would be a file in the cabinet

By the way your program helped allot thanks.