Archive for File System Forensics

File System Tunneling in Windows

File system tunneling is a somewhat obscure feature of Windows that some examiners may not be familiar with.  Seeing this feature in action is as simple as deleting a file and immediately recreating a file with the same name in the same directory.  The new file will inherit its creation date from the original file.

According to Microsoft KB article 172190, both NTFS and FAT file systems perform tunneling.  This Microsoft article further documents that exFAT supports tunneling (also mentioning that UDFS has no support this feature).  Tunneling provides compatibility for programs that use safe save, as described by the KB article referenced above.  Programs using the safe save method copy the modified data into a temporary file before deleting the original file and renaming the temporary file with the original file’s name – this is all in the process of saving.  It would obviously be disadvantageous to have a file’s creation time updated every time you make any type of modification and re-save a file, so file system tunneling is enabled to prevent this.  With the safe save method in mind, one might also recognize the potential issue in programs utilizing this method that are incompatible with long file names.  The short file name would be tied to the temporary file, which in turn would result in the original file being identified with a potentially different name (e.g. LONGFI~1.txt). This blog post does a great job of explaining this scenario (as well as file system tunneling in general).

To illustrate tunneling in action, I followed a series of steps very similar to those from the KB article to recreate a tunneling scenario.  In this particular test, I renamed a file and immediately recreated a second file with the first file’s original name.  The results of this simple test are below.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
As you can see, the creation time remained the same after renaming “Win7TextFILE.txt” to “FILE2.txt”, which is what a normal user might expect.  A listing of the current directory then displayed that “Win7TextFILE.txt” had been removed and “FILE2.txt” was the only file in the directory.  A second file titled “Win7TextFILE.txt” was then created and the directory was listed again with the creation times.  As you can see, both creation times are the same as the original “Win7TextFILE.txt”, despite the fact that it was around 6:11 AM when the second file was created (as noted by the current time being printed at the beginning and end of the test).  This very simple example was carried out using a Windows 7 system.

According to the KB article mentioned earlier, the default time frame for tunneling a file is 15 seconds.  This time value may be changed, or the feature disabled completely, by adding a registry key and value under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFilesystem (the KB article details this method).  Disabling the feature would probably have a negative impact on the system, however, dramatically increasing the lifespan of the tunneling cache (i.e. the tunneling time frame) might have an interesting effect.  The presence of these additional keys in the registry would be a hint that the user may have manipulated the system’s tunneling capabilities.  I haven’t explored the maximum value that Windows allows for the tunneling cache, but it would be interesting to see what the system will allow.

File system tunneling is by no means a new technology.  This topic has been discussed both in the forensics realm as well as by other technologists in the past.  My goal with this article is to enlighten those in the field that may not be familiar with tunneling.  As Harlan Carvey mentioned in a past blog post, examiners need to be aware of and understand this feature of Windows.  This may never have a huge impact on an examination, but understanding that this feature exists might help explain an otherwise perplexing timestamp scenario in the future.

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.