Digital Forensics Stream
Findings, tips, and tools developed while trekking through the world of digital forensics

Archive for Registry Forensics – Page 2

Posted by Jason Hale 
· February 21, 2014 
· 1 Comment

Office 2013: More MRUs

Microsoft Office 2013 continues to yield very interesting artifacts related to user activity. Harlan recently posted about the “PendingChanges” subkeys in relation to PowerPoint, and I have previously posted about MS Word’s “Reading Locations” subkeys as well as the last saved location metadata in Excel 2013 spreadsheets.  The registry, specifically the NTUSER.DAT hive, has been particularly interesting in terms of the Office 2013-related information it stores.

In Harlan’s earlier post, he identified references to the PowerPoint presentation he had opened in PowerPoint 2013 in the “File MRU” and “Place MRU” subkeys of “HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0ExcelUser MRULiveId_xxx”. The “File MRU” and “Place MRU” subkeys appear to track files and directories recently accessed by the application, with the “Item 1” value corresponding to the most recently accessed item, “Item 2” the next most recently accessed, etc..

Office 2013 Sign in Option

When a user is not signed into a Live ID account, references to the files and directories recently accessed by PowerPoint, Word, and Excel are stored in the “HKEY_CURRENT_ USERSoftware MicrosoftOffice15.0[programName]File MRU” and “HKEY_ CURRENT_USERSoftware MicrosoftOffice15.0 [programName]Place MRU” subkeys.  When a user signs into a Live ID account (using the Office 2013 sign in option), the recently accessed files and directories appear to be tracked in “HKEY_ CURRENT_USERSoftwareMicrosoftOffice 15.0[programName]User MRU LiveId_xxx” under the respective File and Place MRU subkeys.

Interestingly, it appears that a new LiveId_xxx subkey is created each time a new Live ID account is signed in to through the Office 2013 interface.  Based on my limited testing thus far, the File and Place MRUs of each LiveId_xxx subkey appear to be updated independently from one another (updates depend on which Live ID account is signed in) as well as independent from the File and Place MRUs maintained when a user is not signed into a Live ID account.  This means that you could see multiple sets of File and Place MRUs per application, all within a single NTUSER.DAT hive!

HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0Excel Subkey

As Harlan mentioned in his previous post, each Item # value in the File and Place MRU subkeys should contain data similar to “[F00000000][T01CF2DF40FEB4220][O00000000]*Z:FilesPresentation1.pptx”, with the value in the second set of brackets being a FILETIME structure that corresponds to the last time the file or directory was accessed from the application.  This means that not only do we have an independent File and Place MRU subkey for each Live ID account that signed in to the system (as well as a File and Place MRU for when the user is not signed into a Live ID account), but we are also provided with the last time each item within each MRU list was accessed.

Regardless of whether a Live ID account was signed in or which Live ID account was used to access a file, usage history still appears to be recorded in the familiar RecentDocs subkey as well as the application’s associated jump list.  These artifacts can serve to provide a file access history (regardless of the Live ID account used to access the file) as well as to help correlate and confirm data located in other artifacts.

Based on initial testing, the File and Place MRU list per Live ID account does not appear to be updated properly on Windows 7 running Office 2013.  More research will be necessary to determine the value and reliability of this artifact under Windows 7. The majority of my testing as it relates to the File and Place MRUs has been with Windows 8.1, which appears to be consistent in updating the appropriate MRU list.  I’ve only tested the addition of Live ID-associated File and Place MRUs with Word, Excel, and PowerPoint 2013, so the differences in MRUs as compared to previous versions of Office likely extend beyond these three applications.

1 Comment
Categories : Microsoft Office Forensics, Registry Forensics
Tags : , ,
Posted by Jason Hale 
· January 31, 2014 
· No Comments

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.

No Comments
Categories : Microsoft Office Forensics, Registry Forensics
Tags : , ,
Posted by Jason Hale 
· September 9, 2013 
· 3 Comments

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.

3 Comments
Categories : Registry Forensics
Tags : ,
Posted by Jason Hale 
· March 8, 2013 
· 5 Comments

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. 

5 Comments
Categories : Registry Forensics
Tags : , ,
Posted by Jason Hale 
· June 12, 2012 
· 6 Comments

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.

6 Comments
Categories : Registry Forensics, Tool Release/Update
Tags : , ,
« Previous Page
Next Page »

Twitter

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

DISCLAIMER

The contents of this blog reflect my opinion and may not represent the views of my employer or anyone else.  Any material on this blog, especially related to technology and/or forensic methodology should not be assumed to be true in all possible scenarios.  As always, test any theories, ideas, or tools from this blog in your own environment before stating them or the results therefrom as factual.