Difference between revisions of "User talk:Shray"

From ForensicsWiki
Jump to: navigation, search
(New page: Much is known about MACE values( Modified, Access, Created and Entry Modified time-stamps) of $STANDARD_INFORMATION attribute of a file can be easily modified by an attacker. A workaround ...)
 
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Much is known about MACE values( Modified, Access, Created and Entry Modified time-stamps) of $STANDARD_INFORMATION attribute of a file 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.  
+
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?
 
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.
 
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 [http://msdn.microsoft.com/en-us/library/aa363798(VS.85).aspx NTFS change journal] perhaps? [[User:Jessek|Jessek]] 18:28, 29 December 2008 (UTC)
 +
 +
I have tested it, and [http://www.forensicswiki.org/wiki/Timestomp  Timestomp] page has results of this behavior under the title "A Practical Example". --[[User:Shray|Shray]] 20:16, 29 December 2008 (UTC)

Latest revision as of 16:16, 29 December 2008

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)

I have tested it, and Timestomp page has results of this behavior under the title "A Practical Example". --Shray 20:16, 29 December 2008 (UTC)