Much is known about MACE values( Modified, Access, Created and Entry Modified time-stamps) of $STANDARD_INFORMATION attribute of a file , which can be easily modified by an attacker. A workaround to detect any such modification is to look at $FILE_NAME MACE values which are not modified by user, but windows in itself manages them.
I found a strange behavior with $FILE_NAME MACE values, which can be indirectly modified by a user/attacker. When a file is moved within a volume, MACE values from $STANDARD_INFORMATION are copied to $FILE_NAME information. I really don't find a justification for such behavior. If the $FILE_NAME MACE is intended to be modified by Windows by itself, than why is this sort of modification allowed?
However it just fosters anti-forensics, I really don't find a perfect way either through meta-data files or attributes which can be helpful in determining sequence of file creation, in such case it is easy for an attacker to camouflage his intent.
- This is an interesting find. While I think you would need some more detail before putting this information on one of the regular wiki pages, I'd like to know more. Perhaps an attacker would move files around to shuffle their timestamps. Could that in an of itself be an indicator of malicious activity? Is there a way to track that? The NTFS change journal perhaps? Jessek 18:28, 29 December 2008 (UTC)