Tuesday, February 7, 2012

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_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem (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.  

No comments:

Post a Comment