Archive for Registry Forensics – Page 2

MS Word 2013 Reading Locations

Microsoft Office 2013 introduced a new feature that allows a user to continue reading or editing a document starting at the last point he or she was working.  This feature, referred to by some as “pick up where you left off”, is a convenient way to jump to the location within a document that Word believes was being read or edited most recently before a file was closed.  After opening a document and being greeted with the prompt pictured above, I was curious as to where this information is being tracked.  After a bit of investigation, I located a set of registry subkeys specific to Office 2013 where this information is stored.

When a document in Word 2013 is closed, a registry subkey is created or updated in the “SoftwareMicrosoftOffice15.0WordReading Locations” subkey of the current user’s NTUSER.DAT.  The subkey created should be named something similar to “Document 0”, “Document 1”, “Document 2”, etc., as the number appended to the name of each subkey is incremented by one when a new document is closed.  Each “Document #” subkey should contain 3 values that may be of interest to an examiner: “Datetime”, “File Path”, and “Position”.  All three values are stored as null-terminated Unicode strings.

Screenshot of Reading Locations Subkey











Datetime Value
The Datetime value corresponds to the local date and time the file was last closed. This value data is displayed in the format YYYY-MM-DD, followed by a “T”, then HH:MM.

File Path Value
The File Path value is the fully qualified file name.

Position Value
The Position value appears to store the positioning data used to place the cursor at the point in the document “where you left off”.  It appears that the second number in this value data is used to denote the location within the document.  For example, if a file is opened for the first time and then closed again without scrolling down through the document, the Position value data should be “0 0”.  If a file is opened and the user scrolls down a bit through the document before closing it, the Position value data may be something like “0 1500”.  The second number in this value data appears to increase as the user scrolls through (i.e. reads/edits) the document.  Note that positioning of the cursor does not seem to have an impact on this value.  That is, the second field in this value data increases even if the cursor is never moved from the beginning of the document.

Forensic Implications

Fifty unique files (based on fully qualified file name) can be tracked in the Reading Locations subkeys.  Each time a document in Word 2013 is closed, regardless of the version of Word that created the file, a Reading Locations subkey should be added or updated.  It should be noted, however, that files accessed from a user’s SkyDrive do not appear to be tracked in the Reading Locations subkey.  If the file referenced by the “File Path” value data of any subkey is opened and closed again, the corresponding value data is updated, however, the organization of the “Document #” subkeys remains unchanged (i.e. “Document 0” is not shifted to “Document 1”, etc.).  Interestingly, it appears that when the 51st document is opened, the “Document 49” subkey is overwritten, leaving data from the other subkeys untouched.  This LIFO rotation may have some interesting effects on examination, as it lends itself to preserving more historical data while recent activity is more likely to be overwritten.

Windows 8 and 8.1: Search Charm History

The upcoming release of Windows 8.1 offers new features that will add to and/or modify the forensic artifacts available for examination.  One of these additions is the “Search Everywhere” feature that allows a user to search his or her files, settings, apps, and even the Internet at the same time.  In contrast, Windows 8 restricts a user to searching within a single category of data at a time (files, settings, apps).  The new search feature of 8.1 introduces artifacts not available in Windows 8 and provides examiners with another source of search charm data.  This post will discuss artifacts available in both Windows 8 and 8.1 as a result of the user conducting searches via the Windows search charm.

In order to utilize the “Search Everywhere” feature of Windows 8.1, the user must run a search using the Windows search charm, a feature introduced with Windows 8. This is not the same as conducting a search using Windows Explorer and leaves a different set of artifacts.

Windows 8.1 Search Charm
Windows 8 Search Charm

When a user runs a search using the search charm in Windows 8, specifically selecting “Files” as the search category, the search term is added as a value to an MRU list (maintained by an MRUListEx value) in the user’s NTUSER.DAT under SoftwareMicrosoftWindowsCurrentVersionExplorerSearchHistory Microsoft.Windows.FileSearchApp.  If the “Settings” or “Apps” category is selected, the search term does not appear to be added as a value to the MRU list (nor is a separate subkey created in the SearchHistory key).

Windows 8.1 also utilizes the SearchHistory key to maintain an MRU list of search terms, but within the SearchHistoryEXPLORER.EXE subkey instead.  Additionally, it appears that all search terms executed using the search charm are stored as a value here (as opposed to only the terms executed against the “Files” category).  An MRUListEx value is used to maintain the list here as well and the search term itself is stored in Unicode as type REG_BINARY.

In addition to the SearchHistory subkey, it appears that Windows 8.1 maintains another set of artifacts in the form of LNK files in the user’s AppDataLocalMicrosoftWindows ConnectedSearchHistory directory.  Interestingly, the LNK files associated with the search charm history that I’ve examined consist of only the LNK header and a shell item ID list containing the search term.  This means that if your tool does not parse shell item ID lists, it will not extract the search term from these files.  The LNK files I’ve examined that are associated with the search charm do not contain embedded FILETIME timestamps in the LNK header or DOSDate timestamps in the shell item ID list.  Further, if the user runs the same search term at a later date, there appears to be no change to the file content or file system timestamps of the LNK file.  This means that the file system timestamps associated with these files can only be used to identify the first time a particular search was conducted.

The search charm LNK files could be quite useful during an examination, despite the fact that the search terms are also stored in the user’s NTUSER.DAT.  For example, these files can help determine a specific time that each search term was used, provide additional artifacts to support that a particular search term was/wasn’t used, and may be useful if the user has taken steps to remove his or her search charm history.  When the search charm history is cleared (via search & apps settings), the entire SearchHistory subkey and the LNK files in the ConnectedSearchHistory directory are deleted.  The existence of these LNK files provides another possible avenue to recover previously used search terms.  One thing to note with respect to these files is that they are likely to be resident, given the fact that they contain only the LNK header and a small shell item ID list.

The testing I’ve conducted with regard to the Windows 8 and 8.1 search charm history has been with the default settings.  The Preview version of Windows 8.1 Professional was used for all testing related to 8.1.  At the time of this writing, the option to search the Internet using Bing is not a default option and thus was not tested.  It will be interesting to see if/how this option changes the artifacts available to an examiner.  At any rate, the Windows search charm, both with and without the “Search Everywhere” feature, provides additional forensic artifacts to help examiners piece together user activity in a Windows environment.

Windows 8: Tracking Opened Photos

One of the many new features of Windows 8 is a new stock photo viewing application called Photos.  With the inclusion of a new photo viewer comes the creation of new artifacts resulting from its use. Specifically, I’ve found that the Windows 8 Photos app stores usage history information within a user’s UsrClass.dat registry hive.  Buried within this hive is a wealth of information about files that have been viewed using Photos (specifically by double-clicking an image).  By “wealth of information”, I mean information about each file viewed using the Photos app.  This includes the file name, path to the image file, timestamps associated with the image file, the last time the file was viewed using Photos, the type of device from which the file was opened, and more.

Based on my research, if an image file has been opened using the Photos app via double-clicking the file in Explorer, a subkey named using a {GUID} value will be added to the “Local SettingsSoftwareMicrosoftWindowsCurrentVersionAppModelSystemAppDatamicrosoft.windowsphotos_8wekby3d8bbwePersistedStorageItemTableManagedByApp” subkey located in the user’s UsrClass.dat hive. The screenshot below is a depiction of the values and value data from a ManagedByApp{GUID} subkey as viewed with regedit.

Based on my research, each {GUID} subkey beneath the ManagedByApp subkey corresponds to an image that has been opened using the Photos app and includes six values.  The table below includes information about each value located within one of these {GUID} subkeys.

Value Name
Value Type
Value Data
FilePath
REG_SZ
Full
path to the file
Flags
REG_DWORD
Appears
to relate to the media type from which the image was opened
LastUpdatedTime
REG_BINARY
64-bit
FILETIME value; appears to reference last time the file was opened
Link
REG_BINARY
Variation
of Windows LNK file [MS-SHLLINK]
Metadata
REG_SZ
Holds
the name of the file
PackageFamilyName
REG_SZ
microsoft.windowsphotos_8wekyb3d8bbwe

File Path Value
If you guessed that the FilePath value data includes the path to the image file, you’d be correct.  Based on my testing, the full path (including drive letter) is included in this data if the image file was opened from the C: drive, external hard drive, or network share.  If the image file was opened from a flash drive, the volume GUID is listed instead of the drive letter (e.g. ?Volume{D729662E-868D-11E2-BE69-000C29930361}file1.jpg).  The inclusion of the volume GUID here will allow an examiner to corroborate this data with information from the MountPoints2 subkey of the user’s NTUSER.DAT hive as well as the MountedDevices subkey from the SYSTEM hive.  The drive letter assigned to the media where the file was stored can also be found in the Link value data within the same {GUID} subkey.

Flags Value
The Flags value data appears to relate to the type of media from which the image file was opened.  Based on my testing, a flag value of 13 (0x0000000D) indicates that the image file was located on the internal C: drive at the time it was opened.  A flag value of 9 (0x00000009) is assigned when the image file is opened from some type of external media (such as a flash drive or external hard drive), including network shares. This should be easy to verify by checking the FilePath value data (or the Link value data) stored in the subkey.

LastUpdatedTime Value
The LastUpdatedTime value data is a 64-bit FILETIME value and appears to be updated each time the image file referenced by the {GUID} subkey is opened using the Photos app.  Since this value is updated each time the image file is opened, the LastWrite time of the {GUID} subkey to which this value belongs is also updated.  In my [fairly limited] testing, I have yet to come across a case where the LastUpdatedTime value data is different than the LastWrite time of the {GUID} subkey to which the value belongs.

Link Value
With the exception of the first 16 bytes, the Link value data appears to follow the MS-SHLLINK file format (see this document provided by Joachim Metz for more info on this format).  The first 16 bytes of the Link value data appear to hold the LNK class identifier and are the same as bytes 20-35 of the value data (where one would expect to find the LNK class identifier based on the MS-SHLLINK file format).  After the first 16 bytes, we can find much of the same useful information here as would expect to find in Windows shortcut files (target file timestamps, full path to target file, etc.).  The value data alone provides a great deal of insight into the opened file.

Forensic Implications 
Using the values from these {GUID} subkeys related to the Windows 8 Photos app, an examiner can determine not only what files were viewed using the app, but also the last time each file was viewed, the type of device from which each image was viewed, the path to each file, timestamps associated with each image, and much more.  This information can be used to track user activity surrounding image files, corroborate USB device activity found in other locations, as well as provide useful timestamps for inclusion within a timeline.  A RegRipper plugin or otherwise some other means of quickly harvesting this information will need to be written (it’s on my TODO list unless someone beats me to it), but knowledge of these artifacts will be important when examining a Windows 8 machine (particularly when image files are of interest).As an aside, I have yet to determine if there is a maximum to the number of {GUID} subkeys created before they begin to be cycled out, but I have populated more than 200 subkeys without the oldest entry being removed.  This indicates that an examiner may encounter a large number of these subkeys during an investigation, depending on how often the user views images using the Photos app.  Additionally, this information does not appear to be removed when the user clears their app usage history (using any of the stock options that I’ve tried to date).

Update: 07/08/2014: As pointed out in a comment to this post, this information does not appear to be recorded in the same manner in Windows 8.1. 

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.

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 HKCUSoftwareMicrosoftInternet ExplorerTypedURLsTime. 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.