Tuesday, September 18, 2012

VSC Toolset Update: File Recovery

I've recently added an important functionality that has been missing from VSC Toolset: the ability to systematically extract files from shadow copies.  You can now do this with VSC Toolset either by utilizing the "Copy" command from the main window or via browsing the directory structure of a shadow copy and utilizing the context menu option.

When browsing an individual shadow copy, you can easily verify the location of the files or folders you wish to copy and extract them accordingly.  To extract files in this manner, simply navigate to the folder of interest, highlight the files or folders you wish to extract, and select "Copy" from the right-click context menu.  You will be prompted to select a location to save the data, then a small status window will appear while the data is being extracted (see screenshot below).  The downside to this approach is that you must copy the files of interest from each shadow copy individually.  To alleviate this problem, the option to copy a selected file or folder from multiple shadow copies in a single operation is available from the main window of VSC Toolset.
Copying Files via VSC Browser Context Menu

By utilizing the Copy command from the main VSC Toolset window, you can extract a file or folder from multiple shadow copies in a batch processing manner.  It's as simple as selecting the shadow copies from which to extract the file or folder, inputting the path (or browsing to it using the Browse button), and clicking the Run Command button.  It's important that the path to the file or folder of interest be the full path on the drive containing the VSCs.  For example, if the image containing the shadow copies is mounted as the H:\ drive, the path to the file/folder to copy should be something like H:\folder\subfolder\file.txt.  VSC Toolset will then use the batch files associated with the copy operation to copy the specified file or folder from all selected shadow copies.  The extracted files will be stored in the "VSCToolset_Output\ExtractedFiles" folder (the location of which may be changed under Tools --> Options).
Copying Files from VSC Toolset Main Window

All copy operations issued with VSC Toolset are simply passing parameters to a robocopy batch file that resides in the VSC Toolset "batch" folder.  
Robocopy is a powerful copying utility and is a standard feature of Windows Vista and above.  For information on Robocopy options, check out this Microsoft article.  With VSC Toolset copy operations, the /COPYALL flag is passed for file and folder copies to copy all file information (including time stamps).  Additionally, the /E flag is passed during folder copy operations to include empty subdirectories. These options can of course be modified by changing the respective batch files within the "batch" folder used by VSC Toolset.  CopyFile.cmd and CopyFolder.cmd are the batch scripts used to issue the robocopy commands for file and folder copying, respectively. The robocopy log, which can also be customized by modifying the batch files, is saved in the "VSCToolset_Output\RobocopyLogs" directory that is created by VSC Toolset upon issuing a copy operation.

A couple of other improvements have been made as well, including adding multiple threads for processing.  By making VSC Toolset a multi-threaded application, the user interface remains responsive even when running time-consuming operations such as Diff or a large copy operation.  This allows you to immediately start a process such as running Diff against a couple of shadow copies and then running a RegRipper plugin or profile against one or more shadow copies while Diff is still executing in the background.

You can download the latest version of VSC Toolset here.

For tips on setting up and using VSC Toolset, check out this blog post. To get the most out of the program, you'll need the accompanying tools below. Also, keep in mind that with the exception of RegRipper, all accompanying executable files and scripts should be stored in the same directory as the VSC Toolset executable in order for the program to see them.

Feedback, suggestions, and bug reports are always welcome and appreciated.

Wednesday, September 5, 2012

FoxTab: Firefox's Hidden Camera

The FoxTab add-on to Mozilla Firefox presents some interesting artifacts in respect to forensic analysis.  According to FoxTab's webpage, the add-on "brings innovative 3D functionality to your Firefox."  Among the features offered by FoxTab are the "Tab Flipper" and "Recently Closed Tabs", which allow a user to view their currently opened tabs and recently closed tabs in an animated fashion.  While these features may be appealing to some users, they are interesting from a digital forensic standpoint in that the artifacts they leave behind provide a unique insight into a user's browsing history.  Each screenshot taken by FoxTab is either a JPG or PNG file (depending on the version of FoxTab) that is stored on the disk and in many cases readily available to a forensic examiner.  And unlike the page thumbnails stored by newer versions of Firefox, Foxtab's thumbnails are undisturbed after clearing the browsing history.
Screenshot stored by FoxTab

Foxtab\thumbs Directory
The images displayed using the Tab Flipper feature (depicting the currently opened tabs) are stored in a folder titled "thumbs" within a user's AppData\Local\Temp\foxtab directory (or Local Settings\Temp\foxtab on XP).  For each tab that is opened in Firefox, a screenshot of the webpage depicted in the tab is stored for use in navigating between currently opened tabs using the Foxtab interface. While newer versions of FoxTab appear to delete the screenshots in the foxtab\thumbs folder when Firefox is closed, older versions (1.4.2 and earlier) of FoxTab aren't quite as efficient in cleaning up their mess. When testing this feature, I observed on several occasions files remaining in the foxtab\thumbs directory after closing Firefox.  The remaining files could simply be given a .jpg or .png extension (they are stored without an extension) and viewed using the native Windows photo viewer. 

Based on my testing thus far, the $STANDARD_INFORMATION creation date of the files within the foxtab\thumbs folder correspond with the time in which the webpage depicted in the screenshot was first visited. The $STANDARD_INFORMATION last modified time appears to be a close approximation of the time the webpage was first visited, although it's a few seconds after the creation date.  I haven't pinned down exactly what the variance can be attributed to, but in all tests, the last modified time of each file was within 40 seconds of the creation time (although some were as close as four seconds apart).

Foxtab\thumbsRCT Directory 
The images displayed using the Recently Closed Tabs feature are stored in a folder titled "thumbsRCT" within a user's AppData\Local\Temp\foxtab folder (or Local Settings\Temp\foxtab on XP).  Similar to the foxtab\thumbs folder, this directory stores images of tabs that were opened in Firefox at some point.  Within the FoxTab interface, a user may view a graphical depiction of the recently closed tabs.  My testing has indicated that only those tabs that were closed since Firefox was last opened are available, despite the fact that screenshots from previous browsing sessions may very well still be stored in the foxtab\thumbsRCT folder.
Recently Closed Tab Feature of FoxTab
As with the foxtab\thumbs folder, newer versions of FoxTab appear to remove screenshots from previous browsing sessions stored in the foxtab\thumbsRCT directory more frequently.  When FoxTab is installed and a tab is closed within Firefox, the image file depicting the screenshot appears to be copied from the foxtab\thumbs directory to the foxtab\thumbsRCT folder and renamed using the computed MD5 hash of the URL of the webpage from which the screenshot was taken.  I've been unable to find a location in which the URL is stored for the purposes of FoxTab, so an examiner may only have the screenshot of the webpage and the MD5 of the URL at their disposal.  

Based on my testing thus far, it appears that the $STANDARD_INFORMATION last modified date of each file in the foxtab\thumbsRCT folder corresponds to the approximate time in which the webpage depicted in the screenshot was opened (this is the same last modified time of the file when stored in the foxtab\thumbs directory).  The $STANDARD_INFORMATION creation date of each file appears to correspond with the time in which the Firefox tab containing the depicted webpage was closed (and hence the screenshot was added to the "thumbsRCT" folder).  If the $STANDARD_INFORMATION timestamps can be trusted in a particular case, the creation and last modified time of files in the foxtab\thumbsRCT folder may provide a time frame in which the webpage depicted in the screenshot was open in the user's browser.

Forensic Implications of FoxTab
Although the artifacts left behind by FoxTab do not seem to store the URL of the webpage depicted in each screenshot, an examiner is provided with a visual depiction of the webpage as the user would have viewed it.  This can be very telling in cases involving access to illicit websites where the relevant browsing history of the computer is no longer available.

It seems that clearing the Firefox browsing history does not have an effect on the files saved by FoxTab, as they are stored independently of the browsing history and cache files.  Additionally, uninstalling the FoxTab add-on does not seem to remove either the foxtab\thumbs or foxtab\thumbsRCT directory.  Further, utilizing Firefox's InPrivate browsing mode does not seem to have an effect on the functionality of FoxTab.  It appears that unless the foxtab directories themselves are deleted, many screenshots from previous browsing sessions, both standard and InPrivate, may remain on disk.

Overall, if FoxTab is functioning correctly, it will save screenshots of currently opened tabs and tabs that were closed since Firefox was last opened.  Older versions of FoxTab (1.4.2 and earlier) remove screenshots less frequently (if at all) than newer versions, however, even the most current version (1.4.5) does not seem to remove all screenshots.  This means that a visual depiction of many webpages visited by the user may potentially be available in the foxtab directories previously described, regardless of whether a user deleted their browsing history or utilized the InPrivate browsing mode of Firefox.  While the absence of the page URL is certainly a drawback, the artifacts left behind by FoxTab may provide insight into a user's browsing history where it would otherwise be unavailable.         

Monday, June 18, 2012

Quickly Find the Date Range of EVTX Event Logs

It's helpful to know the date range that an event log spans, as that information lets you know whether or not you should expect the events from a particular time to be included in the event log, assuming the events you're interested in are being audited.  I've often used Harlan's evtrpt.pl script (available on the WFA 2e DVD) to find, among other things, the date range that is covered by an EVT file.  This has proven to be very helpful in identifying whether a particular event log covers the time frame of interest in an examination.  However, to my knowledge, no such script exists for EVTX files.
I originally wrote a batch script for pulling the date range from EVTX files as an add-on to VSC Toolset, but I figured it would be helpful to have the ability to run it against the most current version of event logs (i.e. those not in volume shadow copies) as well.  A couple of modifications to the VSC Toolset batch script made it ready for use on its own.       

In writing the batch script, I decided to harness the power of Log Parser to get the job done.  If you're unfamiliar with Log Parser, it's a great tool from Microsoft that allows you to interpret data files (event logs, for example) as SQL records and execute SQL queries against them to quickly pull out specific information.  The command that I used to find the oldest event record (by TimeGenerated) in an event log is "logparser -i: EVT "SELECT TOP 1 TimeGenerated FROM %1 ORDER BY TimeGenerated ASC".  Walking through the command, I simply notify Log Parser that the input file is an event log and then specify the query that I want to execute against the file.  The "%1" indicates the value passed into the batch file (G:\files\Security.evtx, for example). The query instructs Log Parser to return the top value existing in the TimeGenerated field when that field is listed in ascending order.  You should actually get the same results without "ORDER BY TimeGenerated ASC" since we're only interested in the first entry of the event log.

To find the newest event record by TimeGenerated, I simply had to sort the event log in reverse order by TimeGenerated.  This can be done by changing the "ASC" in the previous command to "DESC".  I also gathered the oldest and newest records by TimeWritten to report in addition to the TimeGenerated values.  The bulk of the code and work on my part in writing the batch file came from formatting the output for a very easy-to-read display.  I won't break down the code I used for that here, but it turned out to be a nice exercise in batch programming for me.

To use the script, download it here and copy the Log Parser executable and DLL into the same folder as the script (or vice versa).  Note that you'll have to install Log Parser from the MSI before the executable and DLL are available in the Program Files directory.  Then execute the evtxdaterange.bat script from the command line, passing in the path to the extracted event log.  For example, issuing "evtxdaterange k:\files\Security.evtx" should give you output similar to that in the screenshot below.

If you're interested in learning more about Log Parser, I would recommend taking a look at the Log Parser Toolkit book (however there are also many resources available online, such as this article by Chad Tilbury).  If you're interested in batch scripting, there are countless online references, including this one by Corey Harrell that goes over getting started with batch scripting.

VSC Toolset Update

I thought it would be helpful to quickly be able to determine the date range covered by an event log within a shadow copy, particularly if the most current version doesn't go back far enough.  So if you're interested in finding which shadow copy contains the event log covering the date range of interest, you can simply run the EventLogDateRange command against all shadow copies to pinpoint which event logs you'll want to parse.  Event log parsing has also been incorporated in the latest update, via Log Parser.  You can read about the other updates and download the latest version of VSC Toolset here

Tuesday, June 12, 2012

TypedURLsTime RegRipper Plugin

I mentioned in a previous post that a RegRipper plugin (or something similar) would need to be written in order to easily correlate the contents of the TypedURLs subkey with the TypedURLsTime subkey that is present in Windows 8.  Being that I haven't had the opportunity to do a whole lot with Perl or write a RegRipper plugin, I figured this would be a good learning experience for me and another way to contribute a bit to the community.  Harlan's Windows Registry Analysis book does a nice job explaining the process of creating a RegRipper plugin, so I decided to start there.

The book mentions the fact that you can create plugins while writing very little code by copying the functionality from other existing plugins. After all, why spend time rewriting something that's already been put out there (although an argument could be made for the sake of learning)? With that in mind, I thought about the different plugins that I'd executed in the past and what they did.  The typedurls plugin would obviously take care of parsing the TypedURLs subkey for me; I only needed to find code that would parse the TypedURLsTime value data containing the FILETIME structures.  The first plugin that came to mind is also one of my favorites: the userassist2 plugin.

So to create the TypedURLsTime plugin, I started simply by copying the code that parses the contents of the UserAssist key and adding that to the parsing code for the TypedURLs key.  I then went in and removed some unnecessary portions, such as the part decoding the ROT-13 values existing in the UserAssist key.  I was left with code that would parse both of the subkeys I'm interested in; I just needed to correlate the results to make the output easier to read.  There is an abundance of material out there to help you get started with Perl.  Learn.perl.org is a nice way to learn the basics; you can also go out and buy one of the many books that exist on the subject (Learning Perl on Win32 Systems was recommended to me).  After reading though a bit of the basics (comparing values, looping, hashes, etc.), I put together the rest of the plugin to correlate the results and display them appropriately.  I added a couple of variables, but the vast majority of the code and the actual work was completed using functionality from two previously written plugins.  That's it.  In very little time and roughly 10 lines of code, I'd put something together that can be used to extract and make use of the information from the TypedURLsTime subkey or simply add in as part of a plugin file for future use.

This obviously required very little coding, but that's part of the point.  I was surprised at how easy it was and the limited amount of Perl knowledge that's required to create a working RegRipper plugin.  That's not to say that other plugins wouldn't require much more coding and a deeper knowledge of Perl, but this is an example of how easy it can be. So the next time you think about writing a RegRipper plugin or realize that one would be helpful, think about what you're trying to pull from the registry. What is the format of the data you're trying to parse?  Are there existing plugins that perform some or all of the required functionality, except applied to a different key?  You might find that nearly everything you need is already out there and available, you just need to piece it together.

If you're interested in viewing or testing the typedurlstime plugin, it's included as part of the updated RegRipper plugins archive available from the RegRipper wordpress site (or more precisely, the RR supplemental plugins google code page).  I also went ahead and modified the reporting format to allow for outputting in TLN format, which is available with the typedurlstime_tln plugin (included in the download).  The output of the typedurlstime plugin could easily be modified to report in csv format as well.

Tuesday, May 15, 2012

VSC Toolset Update: Browsing Shadow Copies

I don't plan to regularly post about tool updates, but I figured there's enough in the most recent update to VSC Toolset that I might want to write a bit about it.  As indicated by the title of this post, the biggest change incorporates the ability to browse shadow copies using an Explorer-like interface.  Although you can easily write a batch file to list the directory contents of each shadow copy, it's nice to be able to see the directory structure.  The "Browse Selected VSCs" button will open all selected linked VSCs.  This allows you to open a directory view of two (or more) shadow copies and view them side by side to visually see the differences between them.  If you find it easier to view the directory contents in another view mode other than "Details", you can right-click on the list view pane and select a different view mode.

I've also tweaked how the VSCs are listed in the main interface.  For example, when you're viewing a list of the shadow copies on a drive, you will no longer see "ShadowCopy1", "ShadowCopy2", etc..  Instead, you should see something like "VSC1: 4/24/2012", "VSC2: 5/12/2012", etc.. Including the date right beside the listing makes it quicker to determine which VSC(s) you may be interested in, based on the creation date.

Other minor updates include:
  • Removed the "List Shadows" button - shadow copies are now automatically listed upon selecting the drive letter
  • Logging is now in local time instead of UTC
  • Added an "Open Output Folder" button that...well, opens the output folder
  • Added another parameter input box, allowing for up to three additional parameters that can be specified at run time to execute against one or more shadow copies using a simple batch script
  • As noted in the release notes of another recent update, jump lists and custom RegRipper plugin files now have built-in functionality with VSC Toolset (see here for more details).

You can download the latest version of VSC Toolset here.

For tips on setting up and using VSC Toolset, check out this blog post. To get the most out of the program, you'll need the accompanying tools below. Also, keep in mind that with the exception of RegRipper, all accompanying executable files and scripts should be stored in the same directory as the VSC Toolset executable in order for the program to see them.

Feedback, suggestions, and bug reports are always welcome.

Tuesday, May 8, 2012

Windows 8 TypedURLsTime

Amanda Thomson posted a Windows 8 Forensic Guide last month that covers a variety of topics examiners can expect to encounter with this new operating system on the horizon.  One of the new items in Windows 8 - existing at least in the Consumer Preview version - is the TypedURLsTime subkey that is located in the respective user's NTUSER.DAT hive.  Amanda touched on this in her guide, but also mentioned that additional research should be conducted on this subkey. I was interested in when this key was updated, how it might be affected by a user performing specific actions (such as clearing the browsing history), and the added benefits to forensic analysis that an examiner may see with the existence of this subkey.  In an attempt to answer these questions, I ran a few tests on a clean install of Windows 8 Consumer Preview using Internet Explorer 10.

Note that this post doesn't go into a great deal of detail regarding the TypedURLs subkey because it's been covered in other locations such as the Crucial Security Forensics Blog and ForensicArtifacts.com.  I would recommend checking out one of those or the many other sources out there that discuss the TypedURLs subkey if you're interested in more information.  

Upon review of the NTUSER.DAT hive immediately after the first login (before Internet Explorer was ever opened), I observed a single value named "url1" in the TypedURLs subkey with the data being "http://go.microsoft.com/fwlink/?LinkId=69157".  This existence of this value appears to be consistent with the behavior in older versions of Windows.  The TypedURLsTime subkey had not been created at this point.

After visiting a few websites by typing the URL into the address bar and hitting Enter, I observed that the URLs I typed had been added to the TypedURLs subkey with the most recently visited site being associated with the value "url1".  This is consistent with the behavior an examiner would expect to see in older versions of Windows.  However, I also observed that the TypedURLsTime subkey had been created after values were added to the TypedURLs subkey.  The TypedURLsTime subkey is located at HKCU\Software\Microsoft\Internet Explorer\TypedURLsTime. The values within this key are similar to those in the TypedURLs subkey ("url1", "url2", etc.), but the data for each of the values consists of a 64-bit FILETIME structure, as noted in Amanda's guide.  This date/time combination appears to be the most recent date/time the corresponding URL was added to the TypedURLs subkey.  The connection is trivial to make between the TypedURLs subkey and the TypedURLsTime subkey. The URL listed as the data of value "url1" in the Typed URLs subkey was last added to that subkey at the date and time (UTC) contained within the data of value "url1" in the TypedURLsTime subkey.  This appears to be consistent and accurate with each "url##" value within each subkey.

An important point to note is that the date/time listed in the TypedURLsTime subkey corresponds to the most recent date/time the corresponding value was added to TypedURLs.  That is, if an entry for "www.google.com" already exists as the data of "url5" in TypedURLs and is added to the key again, the entry for "www.google.com" will become "url1" in the TypedURLs subkey and the data for "url1" in the TypedURLsTime subkey will correspond to the most recent visit to "www.google.com".  The original data that once existed as "url5" will be replaced by the data from "url4" as each of the values are shifted down in order to add the most recent URL as "url1".  Values existing in either subkey after "url5" ("url6", "url7", etc.) will remain the same.

One difference I noted with Windows 8 is that it appears the maximum number of values within the Typed URLs subkey - and thus the TypedURLsTime subkey - has been increased to 50, as opposed to the limit of 25 that exists in previous versions of Windows.  This may not be a huge difference, but more information - especially when it comes to user activity - is always nice.

When a user clears the browsing history via Internet Options --> Delete (under the Browsing History category), both the TypedURLs and TypedURLsTime subkeys are deleted.  I observed this when monitoring the deletion operating using procmon (snipped screenshot below).

The deletion of these subkeys, specifically the TypedURLs subkey, is of note to an examiner.  As Harlan mentioned in his corollary to the first law of computer forensics, "Once you understand what actions or conditions create or modify an artifact, then the absence of that artifact is itself an artifact".  Since we know that the TypedURLs subkey should exist in a default installation of Windows 8, the absence of this subkey would be an indication that the browsing history may have been deleted (or the user may have taken other means to remove this subkey).  

Further, the TypedURLs subkey does not appear to be immediately recreated after it is deleted using the method described above.  I have noted that opening Internet Explorer and navigating to websites using links within web pages will not prompt Windows to recreate this key.  I also noted that launching regedt32 directly from the System32 folder will not recreate the key, nor will restarting the machine.  However, oddly enough, opening the Run window appears to cause the shell to recreate the TypedURLs subkey (I would imagine there are other means of accomplishing this too, aside from visiting websites to populate the subkey).  When TypedURLs is created in this manner, the "url1" value with "http://go.microsoft.com/fwlink/?LinkId=69157" as its data does not exist as we observed before.  Instead, there are no values contained within the subkey.  This is yet another interesting note for an examiner. Observing the existence of an empty TypedURLs subkey may be an indication that the browsing history was deleted at some point, but the subkey was later recreated by the shell. 

Note that when the TypedURLs and TypedURLsTime subkeys are deleted, their contents may still be recoverable as with any other deleted registry keys.  I successfully recovered portions of these subkeys after the browsing history was deleted by using regslack as well as X-Ways Forensics, although any registry-carving utility should work.

So what exactly are we gaining as forensic examiners with the introduction of the TypedURLsTime subkey? Once obvious benefit is that we're provided with more information regarding the URLs listed in the TypedURLs subkey.  We can now correlate those URLs with a date and time that they were last added to the subkey.  And you can't say date/time in the DFIR world today without thinking timeline.  A tool/script/RegRipper plugin or log2timeline module will need to be written, but correlating the contents of TypedURLs with TypedURLsTime may contribute valuable information to a timeline.  When you add in the additional entries that may exist in NTUSER.DAT hives from volume shadow copies, these subkeys become even more interesting.  

Overall, it appears that the TypedURLsTime subkey is closely tied to the TypedURLs subkey, which doesn't come as a surprise.  However, the knowledge that this key exists and how we might be able to use it will be important when we begin encountering it during examinations.  This is just a single aspect of Windows that will be a bit different with the introduction of Windows 8 (assuming this key is still around when its officially released).  There is certainly a lot of work and research that will need to be conducted so that we as forensic examiners can be ready for what's to come with Windows 8.   

Wednesday, March 28, 2012

VSC Toolset Update

I've updated VSC Toolset with a couple of new features, including integrating some new scripts with it.  You can now choose a specific RegRipper plugin to run against one or more VSCs (specifying either the NTUSER.DAT hive or one of the hives in the config directory).  I've also incorporated link file parsing (thanks for Corey for the batch file and script) and the ability to run diff.exe against two shadow copies to see only the differences between the two.  Running diff against VSCs was one of my favorite features that Corey covered in his VSC series and I wanted to make a point to incorporate it in the GUI.  It's quite time consuming to do this, but it can be helpful if you're interested in exactly which files have changed between VSCs.  If you decide to run diff using VSC Toolset, the GUI will appear unresponsive while its running.  I will eventually need to make the app multi-threaded to avoid this, but I have confirmed that this command does work with VSC Toolset (at least in the test runs that I've completed).

One change I've made that will affect those deciding to extend VSC Toolset by writing their own batch files is that I've specified a directory called "~LinkedVSC" that is created in the root of the "C:\" drive to hold all symbolic links to VSCs.  The main reasoning for this is to enable a user to simply add this directory as evidence in another application such as FTK Imager if they are interested in taking a look at all linked VSCs.  I ran into the annoyance of having to add C:\vsc1, C:\vsc2, etc. to other applications individually instead of being able to add them all at the same time, so I created a directory to store all symbolic links to VSCs.  This doesn't make a huge difference in writing batch files for VSC Toolset, you'll just need to make sure you reference the symbolic link as "C:\~LinkedVSC\vsc%1" instead of "C:\vsc%1".

A couple of other minor improvements include not listing drive letters that do not make sense to list (non-local drives, etc.) and including the volume label beside the drive letter for easier identification.  Additionally, the second and third parameter text boxes and labels are only shown when applicable (and customized when shown).  For example, selecting "RegRipper-ntuser" from the command drop-down box displays a single text box labeled "User Name".  Selecting "RegRipper-plugin(config_dir)" displays two text boxes labeled "Hive Name" and "Plugin Name", respectively.  If a command does not require user-specified parameters, no text boxes are shown.  This will hopefully make it easier for those that may not be as familiar with running some of the commands that are integrated with VSC Toolset, but will likely just serve as a reminder for most.  Note that if a custom batch file is being used (one that is not currently integrated with VSC Toolset), both parameter text boxes will be displayed.

To take advantage of the LinkFiles.bat and Diff.bat scripts, you'll need to download the respective Perl script and executable.  You can download lslnk-directory-parse2.pl from the Win4n6 Yahoo Group under Files\Tools; you can download diff.exe from UnxUtils.  Both the Perl script and the executable will need to be in the same directory as the VSC Toolset executable.  Also, note that you will need ActiveState Perl or something similar to run the link file parsing command since it's a Perl script.  As with the previous version, you can simply copy all RegRipper files into the "regripper" folder that is included with the VSC Toolset download.  You can download the latest version of VSC Toolset here.  

Friday, March 16, 2012

VSC Toolset: A GUI Tool for Shadow Copies

Volume shadow copies (VSCs) have become an important part of the forensic examination of a Windows machine, as they can provide details about user activity that was not possible in the past.  Being able to see how the system has changed over a period of time can be critical in many examinations, and VSCs can provide just that (and more).  The forensic aspects of VSCs, as well as their functionality, have been covered in detail in many other locations, so I'm not going to go over those facts in this post.  If you're interested in some references though, check Harlan Carvey's new book (or his blog posts here and here), Troy Larson's presentation slides, Microsoft documentation, the QCC whitepaper, Lee Whitfield's blog post, or Corey Harrell's recent blog posts.

Corey Harrell's series about VSCs provide a great way to access and examine VSCs through the use of batch scripts.  By adding a loop to the batch script, Corey displayed the ability to create symbolic links to all shadow copies (or only certain ones) on a disk quickly and efficiently. He also covered the use of adding programs like robocopy, RegRipper, and diff (available in UnxUtils for Windows, as noted by Corey) to batch files in order to target specific data or generate a specific report (such as the difference between shadow copies).  The series covered many other aspects and ideas in examining VSCs, so it's best that you read the entire thing instead of taking my word for it.

After reading Corey's series, I decided to explore the option of adding a GUI front-end to his batch scripts.  Although the scripts make it easy to access and rip data from VSCs, I was intrigued as to what a GUI might look like on top of those scripts.  So I decided to take a crack at writing one.  What I've come up with so far is a functioning GUI application that allows a user to enumerate VSCs, create and remove symbolic links to VSCs, and run a few specific RegRipper commands against them.  I've also built in a log pane and a results pane so that you can immediately see the results of what you've just done.     

Since this app is just running batch scripts in the background, there's a folder called "batch" that must be stored in the same directory as the VSC Toolset executable.  As you might have guessed, this is where the batch scripts will be stored.  Each file in this directory with the .bat extension will be listed in the drop down box beside  "Command" in the GUI.  The idea is that a user will be able to write their own batch file with a command to be carried out on a single volume shadow copy, store it in the "batch" folder, and the GUI app (I gave it the name "VSC Toolset") will take care of the rest.  That is, VSC Toolset will list the batch file in the command drop down box and provide a means of inputting the parameters.  This command can then be executed against any number of linked VSCs, which are listed in the "Linked Shadows" check box list.

With the current version, there is a limitation of only one additional input parameter, although I plan to expand this.  For example, VSC Toolset always passes the VSC number to the batch file as the first parameter. In some cases, this may be the only parameter we need (such as ripping data from the entire SOFTWARE hive using RegRipper).  However, in many cases additional parameters will be needed.  To account for this, VSC Toolset has a text box labeled "2nd Parameter" to hold another parameter to be passed to the batch file.  An example of passing a second parameter would be ripping a user's NTUSER.DAT file using the VSC number and the user name.  To do this using VSC Toolset, you would simply select "RegRipper-ntuser" from the command drop down box and type the username of the NTUSER.DAT hive that you would like to rip.  From there, you can execute this command on any number of the linked shadow copies.

UPDATE: I've added an additional text box to the GUI to hold a third parameter to be passed to the batch file if needed.

There's also a logging pane (the bottom of the two text panes) that keeps track of the batch files that have been executed, along with a timestamp.  This can be saved using the button below the pane, but it's currently not saved by default.  The results pane (the upper pane) displays the results of the commands or batch files that were executed. The check box below this pane controls whether all results are saved or not.  The default is to save all results to individual text files, but this can easily be changed.  If the results are being saved, they are saved to the "output" folder that VSC Toolset creates within the working directory. The results are saved according to the batch file that created them and named by the shadow copy from which the information was gathered.  If a case name is specified using the text box in the VSC Toolset GUI, the results are divided by case name first, then batch file, etc..  Other than output directory organization, the case name value serves no purpose.

To get VSC Toolset up and running, you'll need to download the executable here.  After extracting the contents of the zip file, you should see the VSC Toolset executable, a "batch" folder with a few batch files in it, and an empty "regripper" folder.  You'll need to copy Harlan's RegRipper files to this directory where rip.exe is directly inside the "regripper" folder (make sure it's not two folders deep or VSC Toolset will not see it).  From there, you should be able to run VSC Toolset to access and run batch files against your volume shadow copies.

This app is still in its infancy and will certainly require more testing and development, but it's readily available for creating symbolic links to many shadow copies at once, running a few commands against the shadow copies, and keeping track of what you're doing.  While I can make no guarantees about this app, I've found it to be useful in the handful of scenarios I've tested it with (no actual cases though).  Feel free to download it and give it a try.  Any feedback on improvements, bugs, or whether you even found it to be useful would be appreciated.

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.  

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.