Hello Reader,
Yesterday we reviewed the timestomp tool and showed how simple MFT analysis can defeat it. Today we are going to go into the newest version of setmace v1006 which not only can modify the STDINFO timestamps but the FILENAME timestamps as well.
Yesterday we reviewed the timestomp tool and showed how simple MFT analysis can defeat it. Today we are going to go into the newest version of setmace v1006 which not only can modify the STDINFO timestamps but the FILENAME timestamps as well.
I'm not sure how widely known setmace is but I will tell you that its very good at what it does as we'll see in the screenshots below. Prior versions of setmace did some tricks with file moving to reset the FILENAME timestamps but in version v1006 it actually modifies the physical disk itself leaving very few traces of its actions. Setmace will work on NTFS and FAT file systems.
Things to understand
What it does
Setmace will access the underlying physical disk and modify the $MFT directly changing the timestamps you specify (STDINFO or FILENAME or both) or cloning them from another file. Since this is direct physical disk access there are no $logfile or USN entries that show these changes.
What it does not do
It does not change the MFT record number, sequence number or find other artifacts pointing to it. That does not mean that future versions couldn't be modified to further obfuscate the original timestamps.
Capabilities by OS
Windows XP
On a Windows XP system setmace can reset timestamps on a file on any volume as XP's security model did not restrict access to the physical disk. Further since Windows XP does not have a USN Journal by default the only way to prove the original timestamps of a file will either be through the $Logfile or shell items pointing to the file.
Windows Vista/7/8
On a Windows Vista/7/8 system setmace cannot access the physical disk of any system volume, but it can access the physical disk of non system volumes. In my virtual environment I created two additional partitions one which i ran setmace from and the other where i stored the files whose timestamps i reset.
What does it look like?
After setmace runs this is what the STDINFO timestamps look like:
This is what the FILENAME timestamps look like for both the 8.3 and Unicode filenames:
I've used 1-1-1970 here to make it easy to spot that this is a fake timestamp but notice something here, the milliseconds here are set. This is another standard forensic analysis technique to detect timestamp modification, finding files where the milliseconds are set to 0. In this instance our suspect could set the full timestamp value to any date/time desired or clone a valid file. Scary stuff
The USN Journal contains no entries as the timestamp alteration occured outside the filesystem driver, we do have an entry from the usage of the file prior to its timestamp alteration that we can gather a last true usage time from:
The $Logfile contains the original timestamps of these files from its creation:
However there is no entry in any of the filesystem journal logs we normally rely on that would detail the fact that a timestamp change occured, it would be up to the analyst to look for indicators.
What indicators are left?
Don't lose hope, this isn't a blank check just yet for undetectable timestamp alteration. We still have several analysis points left that can reveal past true timestamps of this file:
- Shell Items contain timestamps, compare them to the MFT to determine if MFT creation date is different. Examples of Shell item containers include
- LNK Files
- Shell bags
- Jumplists
- Other registry keys being identified but that I don't have in front of me :) Sounds like a good post for next week.
- MFT entry and sequence numbers, is the file outside the range that it should be in to be created at that time?
- Registry MRUs
- System restore points
- Vista/7/8 - Shadow copies - Compare MFTs
- XP - Restore Points - Parse LNK files for shell items
- Any activity taken place through the filesystem driver prior to the timestamps change will still be in the $logfile and USN
- Prefetch of the setmace execution
I am going to be looking deeper into setmace to see what other artifacts of execution exist, I'll follow up on this on a later blogpost. Until then get some rest, these anti-forensic tools will only get better and you will have to do get better as well to keep up.
This is a 3-part series and here are all links to the entire series:
Post a Comment