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.