Saturday, January 28, 2012

Including Shellbag Data in Timelines

Windows shellbags hold a wealth of potential evidentiary value in forensic investigations.  There are already a few articles that detail the forensic impact of shellbags, including Chad Tilbury’s writeup on Windows 7 shellbags and a great article by Willi Ballenthin.  Metadata that is stored internally to the shellbags is of particular interest when it comes to forensic investigations.

Since shellbags are not parsed under the current version of log2timeline (0.62), my first thought was to write a module for log2timeline to incorporate shellbag data, however, my Perl abilities are not yet up to the task (although I'm working on them!).  So I instead decided to find a way to use existing tools to accomplish what I set out to do - incorporate shellbag data in my timeline.

With the latest release of SIFT, Willi Ballenthin’s shellbags.py script is included in the mix.  Shellbags.py, documented on Willi’s site, parses the shellbag data from a registry hive and outputs the result in bodyfile format.  This bodyfile can then be passed through mactime to obtain a timeline of events relating to a user’s shellbags.  Then, this timeline of shellbag data can be merged with a timeline from log2timeline.  To illustrate, I've included an example of combining MFT and shellbag timelines below.  Note that this assumes that the MFT and NTUSER.DAT have already been extracted from an image.    

There are a couple of slightly different approaches that you can take when you know that you'll be adding in shellbag data to a timeline.  The first is to create a bodyfile using log2timeline, add in the shellbag data, and then run mactime against the entire thing.  The second option is to run mactime against the two outputs before a bodyfile is ever created, and then merge those two timelines together.  Both options are shown below.

Option 1
  1. log2timeline -o mactime -f mft -z GMT my.mft > tln_body
  2. shellbags.py ntuser.dat >> tln_body
  3. mactime -d -b tln_body > timeline.csv
Option 2
  1. log2timeline -o mactime -f mft -z GMT my.mft | mactime -d -b - > timeline.csv
  2. shellbags.py ntuser.dat | mactime -d -b - | sed '1d' - >> timeline.csv
Note that in the second option above, I piped the mactime output to "sed '1d' -" because I wanted to eliminate the header row from my shellbag timeline before appending it to the existing timeline.  This way, I don't have a header row in the middle of my timeline.  It likely wouldn't make a difference during analysis, but I don't like knowing that it's there. It's also important to point out that you'll need to use the mactime output module of log2timeline if you plan on merging it with your shellbag timeline.  Running mactime against the current default output format of log2timeline will strip all of the values because the input of mactime will be different than the format that it expects.

While a module to parse shellbag data will undoubtedly be added to log2timeline in the future, we at least have the option of manually adding shellbag data to an existing timeline now.  It may not always be necessary to include shellbags in a timeline during an investigation, however, in some cases it could add the context that is needed to connect the dots of removable devices or activity involving deleted folders.  

Wednesday, January 4, 2012

The NTFS $LogFile and setMACE

After reading about the release of setMACE , I became curious as to exactly how setMACE works and the forensic consequences if such a program is used maliciously, so I decided to look into this particular program a bit closer.  Compared with existing timestamp altering programs like timestomp, setMACE allows a user to modify the $FILE_NAME timestamp values within NTFS file systems (as opposed to only modifying the $STANDARD_INFORMATION timestamps).  On a general note, if you’re looking for more detailed information about NTFS and other file systems, I strongly suggest reading Brian Carrier’s book.

The author of setMACE provides an explanation as to how the program works in the readme file included with the download, but naturally I wanted to see for myself.  I set up procmon to capture the chain of events occurring when a file’s timestamps are altered using setMACE.  What I noticed appeared to be consistent with the author’s explanation.  Thus, my interpretation of the steps setMACE follows to alter timestamps is below.
  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.