Monday, September 9, 2013

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 \Software\Microsoft\Windows\CurrentVersion\Explorer\SearchHistory\ 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 SearchHistory\EXPLORER.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 AppData\Local\Microsoft\Windows\ ConnectedSearch\History 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 ConnectedSearch\History 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.

Monday, July 22, 2013

MS Excel and BIFF Metadata: Last Opened By

In my last post, I discussed using an OLE timestamp to determine the last time an Excel spreadsheet was opened and closed without being saved.  The last opened time can be very helpful, but wouldn't it be nice to know more about who may have opened the file? The Last Saved By metadata field will help if the file was saved after it was opened, but it may not provide additional information if the file was not saved.  However, the file's Workbook stream, comprised of a Binary Interchange File Format (BIFF) data structure, includes a field that records the user name associated with the account that last opened the Excel spreadsheet.  This data is recorded regardless of whether the file is saved and can provide information regarding the last user that opened the file.

The Details

Microsoft Excel spreadsheets saved in the OLE compound file format utilize the Binary Interchange File Format (BIFF) for saving data in the Workbook stream of the spreadsheet.  I'm not going to cover the intricacies of the BIFF here; for more information, refer to the Microsoft specification.  There is more than one version of BIFF as well; version 8 is the specific version addressed in this post.  

According to this Microsoft KB article, "when you open an Excel workbook, Excel writes the name of the current user to the header of the file" (the article later states that this does not apply to .xlsx files).  The "header" of the file, as it's described, is actually the "Write Access User Name" record within the BIFF data structure that comprises the file's Workbook stream.  It's important to note that the user name is referenced from the UserInfo subkey in the user's NTUSER.DAT, which may not be the same as the user name of the Windows account.  Regardless of whether the file is saved, the user name is written to the Write Access User Name record.  As such, data stored in this record may be different from the Last Saved By metadata field located in the Summary Information stream.  

When the "Protected View" warning bar appears (requiring the user to click "Enable Editing" to edit the spreadsheet), it appears that updates to the Write Access User Name record will depend on the volume from which the file was opened.  Opening a file that was downloaded from the Internet but stored on the local hard disk results in an update to user name in the record (regardless of whether the "Enable Editing" button is clicked by the user).  Opening a file from a network resource will not update the record unless the user clicks the "Enable Editing" button.  It should be noted though that my testing has been limited with regard to the Protected View functionality.

Interestingly, it appears that as different users open the same spreadsheet, the Write Access User Name record is simply overwritten as opposed to the previous user name being cleared first.  This means that you may find residual data following the end of the most recent user name.  The screenshot below depicts this scenario.  The most recent user name is "Jason", while "e 2010" is still stored in the record (the previous user name was "Office 2010").  This remained consistent in my testing of Excel 2000, 2007, and 2010 (I did not have Excel 2003 or 2013 available to me at the time of testing).

Write Access User Name record

Finding the Record

The Write Access User Name record should be stored near the beginning of the Workbook stream.  You can easily view this stream using a tool such as SSView, although the user name may not be parsed out automatically.  Once you've identified the Workbook stream, the user name should be visible in a hex editor.  The only tool I've currently tested that parses the user name is X-Ways Forensics, so it may be necessary to manually parse this record if you don't have a tool that will do it for you (or if you want to verify the results of your tool or just enjoy manually parsing data structures).  

An easy way to find the Write Access User Name record within the Workbook stream is to search for a block of 0x20.  According to the MS documentation, this record should be exactly 112 bytes in size and is padded with spaces (0x20) after the end of the user name.  Since most user names will likely only be a few characters in length, a block of 0x20 after the end of the name will be necessary for padding the record to 112 bytes. This method should work for identifying the Write Access User Name record, but I would recommend following along using the binary specification referenced earlier to develop a better understanding of the data structure.  If there is residual data after the current user name in the record, familiarity with the data structure will allow you to easily distinguish between current and previous data.

Forensic Implications

Parsing the data from the Write Access User Name record within an Excel spreadsheet saved in the OLE compound file format can provide an examiner with a metadata field that may be equated to the "Last Opened By" user.  This can be particularly helpful when a limited set of data is provided for analysis or otherwise any time information regarding the last time a spreadsheet was opened is significant.  By combining this data with the OLE Root Entry last modified time, it is possible for an examiner to determine the last time an Excel spreadsheet was opened as well as the user name associated with the account that opened the spreadsheet, even if the file was not saved and nothing other than the file itself is available for analysis.

Microsoft Excel (xls) Binary File Format Specification 

Monday, July 15, 2013

MS Excel and OLE Metadata: Last Opened Time

It is well known that Microsoft Office files store internal metadata that can be very revealing during forensic examinations (Author, Last Saved By, Creation Time, Last Saved time, etc.).  What may not be as well known are the timestamps maintained within the OLE data structures of the Office 97-2003 files and how these timestamps may be used in a forensic examination.  If a file was opened and closed without saving (thus not updating the internal Last Saved time or potentially any file system timestamp) and you do not have access to operating system artifacts to demonstrate file access, examination options are limited.  However, I've found that in some cases - specifically with Microsoft Excel - OLE timestamps may be used to determine the last time a file was opened, even if the file was closed before saving.

The Details

The OLE compound file format is often referred to as a "file system within a file".  As such, there are multiple data structures maintained and used by the file, one of which is the directory entry.  There are multiple directory entries within each Microsoft Office OLE file, but the one I'm going to discuss here is the root directory entry (labeled "Root Entry" within the file).  The root directory entry within an OLE file functions similarly to the root directory in a FAT file system.  Among other things, it contains a creation and last modified timestamp stored in FILETIME format.  At this time, I have not found the creation timestamp to be overly useful in terms of the information it reveals with regard to Microsoft Excel files as it is typically zeroed out (although this is not always the case).  The last modified timestamp, on the other hand, can be particularly interesting.

When a spreadsheet is saved in the Microsoft Excel 97-2003 format, the last modified time of the Root Entry within the OLE file should either be zeroed out or updated to reflect the time that the file was saved (depending on the version of Excel used to save the file).  This may not be very helpful as the last save information is already available through other known metadata (i.e. the Summary Information stream). However, the last modified timestamp of the Root Entry appears to be updated when the Excel file is opened.  If the file is then closed without being saved, this modification time remains and reflects the last time the file was opened.  This means that it may be possible to detect the last time a Microsoft Excel file in 97-2003 format was opened if the file was not saved and an examiner is provided with nothing more than the file itself.

Updates to the last modified time of the Root Entry directory entry remained consistent in my testing of Excel 2000, Excel 2007, and Excel 2010 (I did not have Excel 2003 or 2013 available to me at the time of testing).  Further, the timestamp was updated regardless of the version of Excel that created or opened the file.  When the "Protected View" warning bar appears (requiring the user to click "Enable Editing" to edit the spreadsheet), it appears that the update to the OLE Root Entry modification timestamp will depend on the volume from which the file was opened.  Opening a file that was downloaded from the Internet but stored on the local hard disk results in an update to the modification time (regardless of whether the "Enable Editing" button is clicked by the user).  Opening a file from a network resource will not update the modification timestamp unless the user clicks the "Enable Editing" button.  It should be noted though that my testing has been limited with regard to the Protected View functionality.

Finding the Timestamp

X-Ways Forensics is currently the only tool I've tested that parses the last modified timestamp from the OLE Root Entry of Microsoft Office documents (I'd be interested in hearing about others though).  For the sake of demonstration, manually finding this timestamp is straightforward.  The easiest way is to simply search for the Unicode string "Root Entry" when the spreadsheet is opened in a hex editor.  Starting from the first byte of the Root Entry (Unicode "R"), simply skip ahead 108 bytes to find the 64-bit FILETIME modification timestamp.  Although this method should work for finding this timestamp, I would encourage you to follow along with the binary specification of the OLE compound file format (see Resources below) so that you have an idea of what fields are present and how the overall OLE file format is structured.    

Root Entry with last modified time decoded

Forensic Implications

When an examiner is provided with a limited set of data (e.g. a flash drive or external hard drive), the options for analysis will likely be limited.  Without the common operating system artifacts that we are used to examining, determining activity with regard to a particular file or set of files can be difficult.  However, if an examiner is provided with a media device storing files in Excel 97-2003 format, he or she may be able to determine if and when each file was opened without being saved.  Comparing the Last Saved time in the Summary Information stream to the last modified time of the OLE Root Entry may be revealing.  If the last modified time of the OLE Root Entry is later than the Last Saved time, the file may have been opened and closed without saving after the last time that the file was saved.  This information may be very helpful when the mere fact that a file was opened after a particular date is significant.

While this post (and my testing) has focused on Microsoft Office 97-2003 Excel files, it's important to note that the OLE Root Entry last modified and creation timestamps are not limited to Microsoft Office files.  There are a number of other files that use the OLE compound file format, such as jump lists (*.automaticDestinations-ms), thumbs.db files, and sticky notes.  Further research into the behavior of the OLE timestamps with regard to other file types may reveal interesting and useful information for forensic examinations.

OLE Compound File Format
[MS-CFB]: Compound File Binary File Format
Forensics Wiki: OLE Compound File

Wednesday, June 26, 2013

Amazon Cloud Drive Forensics: Part 2

In my last post, I covered artifacts that an examiner might find when analyzing a system that has accessed an Amazon Cloud Drive using the desktop application.  While the desktop application makes it easier to transfer files to and from an Amazon Cloud Drive, it also requires the installation of an app.  Some users may opt to avoid installing another application on their system in an effort to reduce the footprint they leave behind or for a number of other reasons.  To service this category of users, Amazon allows anyone with a Cloud Drive to upload and download files using only a web browser.  This post will cover some of the artifacts that will be helpful when examining systems that have accessed an Amazon Cloud Drive using only a web browser.

Browsing History Databases
When examining the browsing history databases (e.g. index.dat) of a system, references to "" followed by a specific query to the Cloud Drive are good indications that the system has interacted with an Amazon Cloud Drive.  The query issued will vary based on the operation carried out (upload, download, deletion, etc.).  For example, the following is a URL that an examiner may find in a system's browsing history after a file has been uploaded to an Amazon Cloud Drive using only a web browser:
As you can see, there is potentially useful information available from this URL, such as the file name, customer ID, and type of operation. However, based on my research, a more complete source of information regarding file uploads and other Cloud Drive activity is available from the browser cache files stored on a system.  Nevertheless, analysis of a system's browsing history database will at least give the examiner an idea as to whether an Amazon Cloud Drive was accessed from the system.   

Browser Cache 
The most significant evidence that I've found of a user's interaction with a Cloud Drive when using only a web browser is found in the browser cache files.  There are specific cache files related to different operations carried out on the Cloud Drive, such as uploads and deletions.  Further, there are two types of deletions within an Amazon Cloud Drive: recycling and "permanent" deletion.  Deleting a file within the Amazon Cloud Drive web interface sends the file to the "Deleted Items" folder/area of the Cloud Drive, which functions very much like the Recycle Bin on a Windows system.  If the file is then deleted from the "Deleted Items" area, it is no longer accessible to the user within the Cloud Drive interface.  The type of deletion that takes place via web browser can be distinguished through analysis of the browser cache.

Although the relevant cache files that I've found have been in plain text, analysis of these individual files can get messy and time consuming.  To illustrate, the screenshot below is one particular type of cache file that is helpful when examining a system used to interact with an Amazon Cloud Drive.

Example ACD browser cache file

To ease the burden of an examiner having to manually extract this information, I've written a Perl script called that accepts the path to a directory containing cache files and parses information from each relevant cache file identified by the script.  The type of information that can be harvested from browser cache files includes: file name, object ID, amazon customer ID, file creation date, file last updated date, cloud path, file size, the file's MD5, and the type of operation (upload, recycle, or permanent deletion).

When running against a directory containing browser cache files from a system and redirecting the output to a CSV file, you will be presented with a table of information associated with Amazon Cloud Drive activity.  For example, you may see something similar to the screenshot below. 

Example output from

One of the most significant distinguishing factors between the information available from browser cache files and that which is available from the ADriveNativeClientService.log file (as seen with the Amazon Cloud Drive desktop app) is the inclusion of timestamps.  As the above screenshot indicates, browser cache files associated with Amazon Cloud Drive activity should contain a "File Creation" and "File Last Updated" time stamp.  These timestamps are stored in Unix Numeric format within the browser cache files, but can easily be decoded (and are with  Based on my research, the File Creation time stored in a cache file in consistent with the "Date Added" column within the Cloud Drive web interface (and thus the time the file was uploaded to the Cloud Drive).  This timestamp, along with the other information available from browser cache files, can play a critical role in building a timeline of activity associated with an Amazon Cloud Drive and a more complete picture of how a user interacted the with Cloud Drive. is available for download here.

For more detailed coverage of Amazon Cloud Drive forensics, please see my Digital Investigation article on the topic.

Tuesday, June 11, 2013

Amazon Cloud Drive Forensics: Part 1

Amazon Cloud Drive is yet another way that users can upload and store information in the cloud.  Much like other cloud storage options, an Amazon Could Drive can be used for a variety of purposes, including those a bit more nefarious such as intellectual property theft.  It's important that an examiner know what artifacts are left behind when an Amazon Cloud Drive is utilized in order to better explain what actions may have taken place surrounding a user and his or her Cloud Drive.  At the time of this writing, I'm unaware of any commercial forensic tool that interprets/parses Amazon Cloud Drive artifacts.  This post (as well as the next) sets out to highlight some of the forensic artifacts available to an examiner after a user transfers files to and from an Amazon Cloud Drive.

A user may currently interact with an Amazon Cloud Drive in one of three ways:
  1. Via the desktop application
  2. Via the online interface (i.e. using a web browser)
  3. Via the mobile application (iPhone and Android)
Depending on the method used to interact with the Cloud Drive, artifacts will be left in different locations of the associated file system.  At the time of my research, the Amazon Cloud Drive mobile app had not been released so I currently do not have details of the artifacts found on mobile devices.  This post will cover the the artifacts left as a result of the Windows desktop application being utilized for Amazon Cloud Drive file transfers.  In Part Two of this series, I will cover the artifacts available to an examiner as a result of the user accessing his or her Cloud Drive using only a web browser.

Desktop Application Usage

The Amazon Cloud Drive desktop application is a small app that can be installed on a Windows or Macintosh system that helps streamline operations carried out on an Amazon Cloud Drive.  Once installed, the user will be prompted to enter his or her credentials to access their Cloud Drive.  After the credentials have been verified and the desktop app is running, the user may drag and drop files either to a small window associated with the app (see screenshot below) or the app's icon in the taskbar to initiate an upload.

Uploading files via ACD desktop application

One aspect of an Amazon Cloud Drive that sets it apart from some of the other cloud storage solutions is that there is no "magic folder" or directory within the file system that is set to automatically sync with the Cloud Drive.  Instead, a user must selectively choose which files and folders he or she would like to upload or download from their Cloud Drive. Because of this, an examiner is not able to focus in on a single directory as the source of uploads/downloads on the local system.  Luckily, the app has left us with a log file that is very helpful during forensic examinations.

Desktop Application Forensic Artifacts

The ADriveNativeClientService.log file is a simple ASCII text file that holds, among other things, a log of completed file transfers made between the Cloud Drive and local machine.  This file is located in the user's Application Data directory under "Users\<user>\AppData\Local\Amazon\CloudDrive" on a Windows 7 system.  By analyzing the records within this file, an examiner can determine details regarding completed file transfers such as: file name, local path, cloud path, file size, and whether the transfer was an upload or download. Here's an example of a record you might find within an ADriveNativeClientService.log file (with some potentially more relevant portions bolded for emphasis):

DEBUG [pool-1-thread-2] c.a.a.c.l.PostTransferHandler.handleRequest ( - Task has been retried FileUploadTask:taskId=C:\Users\Public\Pictures\Sample Pictures\Hydrangeas.jpg,parentTaskId=upload,status=FINISHED,taskInfo={"fileCounts":{"PAUSED":0,"CANCELLED":0,"RUNNING":0,"PENDING":0,"FINISHED":1,"ERRORED":0},"byteCounts":{"PAUSED":0,"CANCELLED":0,"RUNNING":0,"PENDING":0,"FINISHED":595284,"ERRORED":0},"taskId":"C:\\Users\\Public\\Pictures\\Sample Pictures\\Hydrangeas.jpg","timeRemaining":""},children=[],localpath=C:\Users\Public\Pictures\Sample Pictures\Hydrangeas.jpg,cloudpath=/Uploads,conflictResolution=RENAME,filesize=595284 

Since this file is in plain text, it's possible to simply open the file in a text editor and analyze each record line by line or perhaps search for file names of interest within the file.  However, if there was much activity with the Cloud Drive and this log expanded to hundreds or thousands of records, manual analysis would become quite cumbersome.  After manually analyzing a few records from an ADriveNativeClientService.log file, the benefit of a script to parse this file is obvious.  To carry out such automation, I've written a Perl script that parses the records within an ADriveNativeClientService.log file and outputs the result in CSV format for easy viewing within a spreadsheet application.  

The Perl script for parsing this log file simply accepts the path to the log file (or a directory of log files specified with the "-d" flag) and outputs the result in CSV format.  By using this script, you can translate records similar to the one above into a much more readable format as in the screenshot below. The script is freely available for download here.

Sample output from

This is a SQLite database stored in the same directory as ADriveNativeClientService.log that holds the queue of files to be transferred to or from a Cloud Drive. When many files are requested to be uploaded or downloaded at once, a queue will be formed and tasks (one task per file) will be assigned a status of "PENDING".  When a transfer tasks's status is "PENDING", information about the transfer (local path, cloud path, file size) is written to a record within this database. Additionally, if a transfer is paused while there are still files in the queue, the transfer tasks in the queue will be assigned a status of "PAUSED" and will remain in this database. If network connectivity is lost while a large transfer is taking place, this database allows the transfer to continue when connectivity is regained by supplying the list of files waiting to be transferred to either the local machine or the Amazon Cloud Drive.  When the file transfer is complete, the associated database record is removed and information about the individual transfer is logged to ADriveNativeClientService.log. 

As I have not found this database to contain any active records relating to completed file transfers (i.e. where the transfer status is "COMPLETE"), the ADriveNativeClientService.log file appears to contain more useful information regarding completed file transfers.  The information within this SQLite database may be relevant, however, to aid in demonstrating a user's intent to transfer the files described in the database records to his or her Cloud Drive.  

The Amazon Cloud Drive desktop application is easy to use and streamlines the process of file transfers to and from an Amazon Cloud Drive.  This method of transfer may be desirable for many users, but for those that do not want to install an application on their workstation, the online interface provides a means of transferring files that requires nothing more than a web browser (and network connectivity of course). The forensic artifacts left behind as a result of file transfers to and from an Amazon Cloud Drive using only a web browser will be discussed in Part Two of this series.    

For more detailed coverage of Amazon Cloud Drive forensics, please see my Digital Investigation article on the topic.

Friday, March 8, 2013

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 Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\microsoft.windowsphotos_8wekby3d8bbwe\PersistedStorageItemTable\ManagedByApp" 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
Full path to the file
Appears to relate to the media type from which the image was opened
64-bit FILETIME value; appears to reference last time the file was opened
Variation of Windows LNK file [MS-SHLLINK]
Holds the name of the file

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. 

Monday, January 21, 2013

Automating USB Device Identification on Mac OS X

One of the common methods examiners may use during USB analysis on Mac OS X machines (running Snow Leopard or above) is to search the kernel log for "USBMSC" entries to identify USB devices that have been connected to the machine.  BlackBag Technologies has a couple of excellent blog posts here and here describing the logging of USB device information in the kernel log.  The "USBMSC" entries appear to have been moved to the system log in Mac OS X 10.8 (as discussed in this blog post), but the information contained within each entry looks to be unchanged.  An example of the approach an examiner may take in attempting to identify USB devices that have been connected to a Macintosh computer is:
  1. Extract the kernel logs from the file system.
  2. Search the kernel logs for "USBMSC Identifier".
  3. Extract all entries containing "USBMSC Identifier".
  4. Format the entries to make them easier to read/sort (e.g. Excel format).
  5. Search the USB ID public repository for the vendor and product ID associated with each device.
  6. Update each extracted log entry for which the associated vendor and product ID was found within the USB ID public repository. 
Correlating the vendor and product IDs with the USB ID public repository can help to associate a name with the type of device that was connected (e.g. Amazon Kindle, PNY flash drive, etc.).  This process can quickly become tiresome though, especially if there are many log entries for which you must search the USB ID repository.  An examiner performing the same small task over and over again is a good argument for automating that task.  With that in mind, I decided to write a script that would do as much of this for me as possible.  Perl seemed to be a good option to use since it's cross-platform and great with parsing.  And after a bit of coding, testing, and tweaking, I now have a script that takes care of steps 2-6 listed above in a matter of seconds.

The script is capable of parsing either a single kernel log or a directory full of kernel logs, outputting the "USBMSC" log entries in csv format. After using a regular expression to locate the "USBMSC" log entries, the script queries the USB ID public repository and attempts to correlate the vendor and product ID of each entry parsed from the kernel log(s) with a particular device listed in the repository.  The script defaults to checking the online version of the repository, but if you don't have a network connection or want to be able to run the script without querying the online database, you can optionally pass in the path to a local copy of the online database using the "-u" parameter (the text of the file must be in the same format as the online repository).

When you're importing the script's csv file into Excel (or your choice of spreadsheet application), you'll want to be sure and set the formatting of the USBMSC ID, Vendor ID, Product ID, and Device Release columns to text values in order to avoid the application interpreting the values as numbers and removing leading zeroes, etc..

I've only been able to test this script on kernel logs, but it should also work on the system logs from Mountain Lion as the relevant entries appear to be in the same format.  As always, feedback, suggestions, and bug reports are welcome and appreciated.

The script is available for download here.

Console view of

Snippet of output file after correlation