1. Change the $STANDARD_INFORMATION timestamps of the file
2. Create randomly named directory on the same volume
3. Move the file to the newly-created directory
4. Change the $STANDARD_INFORMATION timestamps of the file
5. Move the file back to the original location
6. Change the $STANDARD_INFORMATION timestamps of the file
7. Delete the newly-created directory

You may have noticed that there is no step that explicitly changes the $FILE_NAME timestamps.  To my knowledge, there is not a function that allows a user to easily change these values at this point in time.  To circumvent this issue, setMACE moves the file to a directory on the same volume.  This process should cause the $FILE_NAME timestamps to be updated to reflect those from the $STANDARD_INFORMATION attribute.  Based on my testing, this appears to be the case when moving files to different directories on the same volume.  Once the $FILE_NAME timestamps are updated, setMACE then updates the $STANDARD_INFORMATION timestamps again since the access time and MFT modified times will have changed.  Then, setMACE moves the file back to the original location and updates the $STANDARD_INFORMATION timestamps once again (for the same reason just mentioned).  The result is that when an examiner looks at the MFT record of the file using their forensic tool of choice, they see that the $STANDARD_INFORMATION and $FILE_NAME timestamps are exactly the same and reflect the time set by setMACE.  But what about that directory that was created to update the $FILE_NAME timestamps?

Based on my (fairly limited) testing, the directory that is created for the purpose of updating the $FILE_NAME timestamps appears to have temporal values that are consistent with the time that setMACE was executed.  That is, the timestamps associated with this directory do not appear to be altered.  Unfortunately, tying the directory to the timestamp-altered file does not seem to be an easy task.  Even if you’re fortunate enough to find an MFT record with the directory flag set, the same parent directory as the file in question, and a seemingly random name, there is no value that I’m aware of that could be used to explicitly correlate the timestamps of the directory with the time that the file in question was altered.

However, all is not lost – a clue may reside within the NTFS $LogFile.  By pulling the $LogFile sequence number (LSN) from the MFT record of the file in question, you may be able to shed a bit of light on what’s happened with the file.  It seems that public documentation on the internal structure of the $LogFile is limited, so without parsing software or previous knowledge of the $LogFile structure, piecing this puzzle together may be difficult. If you have access to software capable of parsing the $LogFile (such as X-Ways Forensics), you might be able to search the parsed data for the LSN and obtain some of the Redo or Undo information from the log record.  Ideally, you might find a Redo operation reflecting an update to a file’s timestamps, listing the values to be set (as specified when using setMACE).  In that event, the same record may also contain an Undo operation that lists the original timestamps of the file.  Note that in such a case, you would need to be analyzing the log record referencing the first time alteration (step 1 above).  This might allow an examiner to show that at some point in time, a particular file’s timestamps were changed from X to Y (or more specifically, the log file service was called to write a log record associated with the change).If the MFT record from the directory created by setMACE has not been overwritten, you may also be able to correlate its timestamps with an Undo operation from a $LogFile record that lists the altered file’s original MFT modified or last accessed timestamps after the file has been moved to the newly-created directory (after step 4 listed above).  This may provide a bit more context, as not only would you have a $LogFile record referencing the change, you would also have a randomly named directory created at the same time.

It should be noted that many of the ideas mentioned here are just that – ideas.  I have not been able to test them in many scenarios.  In fact, I originally set out to simply learn more about setMACE and to gain a better understanding of what I’m up against should I ever run into this program being used “in the wild”.  One trail led to another, which in turn gave me a few ideas that one might use in a forensic examination. However, this post has been limited only to artifacts that may exist within a specific system file.  There are likely possibilities through other means that have not been mentioned or explored.  One thing to keep in mind is that even though a program like setMACE may hamper one part of your examination, other artifacts will still remain on the system that may show evidence of execution (PF files, UserAssist, etc.).  Timeline analysis might also reveal anomalies within the system.  Regardless, additional research and testing to the theories mentioned in this post as well as alternative theories will be necessary to gain a better understanding of potential approaches an examiner may take when facing malicious use of a program such as setMACE.