Difference between revisions of "User talk:Shray"

From Forensics Wiki
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 ...)
 
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.

Revision as of 11:59, 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.