On Mar 15, 2017 evening, I attended talk given by Mark Spenser of Arsenal Consulting. During his presentation, he discussed a possible case in digital forensics and sophisticated evidence tampering happened in Turkey 2011. He illustrated using only traditional file system forensics on Windows file system (mainly the NTFS artifacts) may not sufficient to conclude a user activities of adding and deleting documents on Windows system, especially in a case of sophisticated evidence tampering. Based on the artifacts of NTFS log sequence numbers ($LogFile) and update sequence numbers ($Usnjrnl) retained in the NTFS user journal records, he indicated that it is possible to manipulate MACB times without booting up the Windows system. He further pointed out malware is not always an answer for cyber attacks. I concur with him that such contradicting evidence needed to be further reviewed to rule out the possible evidence tampering.
(https://
I don't get it. (
Mark Spencer is a known member of the board, if he affirms something he usually knows what he is talking about. )
You concur with him, which is good. )
What is the point of the poll? 😯
Finding someone that doesn't concur with that?
Measuring the popularity of the concept?
Seeing how many people believe that further research is needed?
Something else?
jaclaz
It is quite a complex topic )
There are several ways to modify a timestamp, and there's also several places to find evidence or indicators of such modification. Many factors will influence, and they may change from a case to another. On NTFS there are so many timestamps to be found. For instance 1 file have an $MFT record, that again have 8 or more timestamps. The parent directory have an index containing 4 timestamps of that file. $UsnJrnl may have recorded 1 timestamp per transaction. $LogFile may have recorded an anormous amount of timestamps regarding transactions concerning any of the above system files and more. Then you may find older versions of the above system files in shadow copies. You may find remnants of them in unallocated and/or slack even at the file and volume level. And you may even find remnants of all or some of them in the hibernation file. And regarding hibernation file, the remnants, can originate from either current or older memory snapshots, in addition to older (previously) unallocated space on the volume from the time the hibernation file was created. There might even be more that I forgot to mention.
Anyway, like jaclaz said, Mark usually knows what he's talking about.