Thursday, July 16, 2015

Adobe Reader's Not-So-cRecentFiles

Version 11.0.07 of Adobe Reader, released in May 2014, introduced some interesting changes that can impact forensic examination.  With previous versions of Reader for Windows, the cRecentFiles subkey found in the Acrobat Reader subkeys of an NTUSER.DAT hive provided an examiner with the five most recent files accessed by Adobe Reader.  Information about these files was divided into five subkeys named “c1”, “c2”, “c3”, etc., with each subkey containing a bit of information about the accessed file.  Version 11.0.07 of Adobe Reader expanded this capability, tracking much more than just the five most recently accessed files.  Additional information is also recorded about each accessed file, as well as a list of the five most recently accessed folders.

The screenshot below shows the new look of the “c#” subkeys that store information about recent files accessed in Adobe Reader version 11.0.07 and above.  Note that the full path to these subkeys is found in a user's NTUSER.DAT hive under "\Software\Adobe\Acrobat Reader\<version>\AVGeneral\cRecentFiles\c#".
Values in a cRecentFiles\c# subkey
The new values added to the "cRecentFiles\c#"subkeys are “sDate”, “uFileSize”, and 
sDate value data
“uPageCount”.  The “uFileSize” and “uPageCount” are pretty self-explanatory, storing the size of the file in bytes and the number of pages in the accessed file, respectively.  The “sDate” value stores the last time that the file was accessed in Adobe Reader.  The “sDate” value type is REG_BINARY, but the value data holds a simple ASCII string of the timestamp.  Interestingly, the time zone offset of the system at the time the file is opened is included in the “sDate” value data.  If the time zone of the system is changed, the offset included in the “sDate” value is reflected accordingly for files that are later opened in Adobe Reader.  This provides examiners with a more more granular view of when files were accessed in Adobe Reader, as previous versions only allowed us to determine the last time the most recent PDF was accessed.

The five most recently accessed folders are also tracked by Adobe Reader version 11.0.07 and later in a "cRecentFolders" subkey under "HKCU\Software\Adobe\Acrobat Reader\<version>\AVGeneral".  Recently accessed folders are maintained in a
Values in a cRecentFolders\c# subkey
similar fashion as the recently accessed files, but the level of detail associated with each accessed folder is pretty minimal.  Each "c#" subkey provides us with the name and path of the accessed folder via the tDIText (or sDI) value, and we can correlate the Last Write time of the cRecentFolders subkey with time that the most recent folder was accessed.  

Perhaps the most significant change from a forensic perspective in Adobe Reader version 11.0.7 and later is the alteration to the number of files tracked in the cRecentFiles subkey.  Instead of the most five most recent files that are tracked in previous versions, Adobe Reader 11.0.7 appears to track the 50 most recently accessed files.  In version 11.0.9, the maximum number of recently accessed files jumps to 100.  After testing the current version of Adobe Reader DC, 100 still appears to be the maximum.  This means that you could have up to 100 “c#” subkeys under the cRecentFiles key!  After 100 documents have been accessed, the subkeys will be reused in a FIFO fashion as seen in previous versions of Adobe Reader (e.g. the contents of subkey c100 will be removed and replaced with the contents of c99).

cRecentFiles with 100 subkeys
Examiners should be aware of this additional functionality in Adobe Reader in order to take advantage of the historical information it provides.  The cRecentFiles subkey from a user's active NTUSER.DAT hive can provide a nice list of files accessed by Adobe Reader.  With later versions storing up to 100 "recently" accessed files, the cRecentFiles subkeys could end up storing files that were not-so-recently accessed as well.  Further, when combined with previous versions of the user's NTUSER.DAT hive from volume shadow copies, an examiner may be provided with quite a detailed history of files accessed using Adobe Reader. 

Wednesday, February 4, 2015

Leveraging the DeviceContainers Key

If you've ever examined registry artifacts related to a particular USB device, you've probably come across a value called "ContainerID".  For example, a flash drive's instance ID subkey of the USBSTOR key includes a ContainerID value.  Prior to Windows 8, a device's Container ID was probably of little interest to an examiner. However, beginning with Windows 8, a device's Container ID can be used to help profile a specific device and corroborate findings from other locations.  The CurrentControlSet\Control\DeviceContainers key of the SYSTEM hive on a Windows 8 machine holds a wealth of information, broken down by Container ID, about devices connected to the system.

Before dissecting the DeviceContainers subkey, it's important to understand what a container ID represents in the first place.  Starting with Windows 7, container IDs were used to identify a physical device on the system.  This Windows Dev Center page describes a container ID as "a system-supplied device identification string that uniquely groups the functional devices associated with a single-function or multifunction device installed in the computer."  This "system supplied identification string" is a GUID and is referenced in various locations, including the Enum\USBSTOR and Enum\USB subkeys of the SYSTEM hive, as the "ContainerID".  One thing to keep in mind is that all physical devices should be assigned a ContainerID - not just storage devices.  This means that when digging into the DeviceContainers key, many of the devices listed may be something other than storage devices (e.g. monitors, external speakers, keyboards, etc.).

DeviceContainers\ContainerID subkey structure
The screenshot on the right is an example of what you might see when browsing a device's DeviceContainers subkey.  The top node as well as the subkey to the BaseContainers key is named by the ContainerID value (the same one found in the USBSTOR key).  The Properties subkey contains eight different sets of.... well, properties.  The idea of useful information being found in a set of "Properties" subkeys is not new; Harlan blogged about the Properties subkeys within the USBSTOR key here and Yogesh Khatri wrote about it here as well.  This is a different set of properties, however, than what is found in the USBSTOR key.

While there are numerous bits of data available in the Properties subkey, I will only highlight a few of the items that may prove useful in a typical forensic examination. The table below summarizes some of the information about a device that is available from the DeviceContainers key.  As you can see, the device instance ID, "DeviceContainer_ModelName", and "DeviceContainer_PrimaryCategory" properties are available here in addition to two 64-bit FILETIME properties.  The "DeviceContainer_ModelName", and "DeviceContainer_PrimaryCategory" properties are defined in the devpkey.h file of the Windows 8.1 SDK.  In addition to the property subkey listed in the table below, the device instance ID is also available in the subkey named by the device's Container ID within the BaseContainers key.


The device instance ID is a valuable piece of information, as it contains the VID and PID of a device as well as the serial number or unique identifier of the device.  For example, when connecting a flash drive to a Windows 8.1 system, I found "USB\VID_090C&PID_1000\1009070810017910" to be the device instance ID associated with the flash drive.  In this case, you can see that "1009070810017910" is the serial number of the flash drive; this information can be corroborated with the USB and USBSTOR keys as well.

The DeviceContainer_ModelName helps describe the device - similar to the FriendlyName value of the USBSTOR key.  Examples of what I have seen in this property are "My Passport 0730", "iPhone", and "USB DISK".  The DeviceContainer_PrimaryCategory helps describe the purpose of the device.  Some examples of what I have noted in this property are "Storage", "Audio", and "Display Monitor".

There are also two 64-bit FILETIME timestamps that appear to be consistent with the first time the device was connected to the system.  Specifically, the "3464f7a4-2444-40b1-980a-e0903cb6d912\0007" property appears to contain the time the device driver installation started, while the "3464f7a4-2444-40b1-980a-e0903cb6d912\0008" property appears to contain the time the device driver installation completed.  This theory is supported by the setupapi.dev.log file, which includes the start and end time of device driver installations.  Interestingly, these two timestamps are slightly different than the Install and First Install timestamps found in other Properties subkeys in the registry. Unfortunately I have not yet found a precise definition - such as that from a Windows SDK - for what these two timestamps officially represent.

One of the nice things about the DeviceContainers key is that it appears to group all physical devices that have been connected to a system into one place.  If an examiner is focusing solely on the USBSTOR key, he or she may miss the fact that an MTP device was connected or that a hard drive was connected using something other than USB.  While the DeviceContainers key may not necessarily provide information that cannot be found elsewhere, it serves as yet another source to help examiners corroborate findings from other locations on the system and may be critical in cases where the ordinary sources of device-related information are not available.  

Friday, February 21, 2014

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_USER\Software\Microsoft\Office\15.0\Excel\User MRU\LiveId_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_ USER\Software \Microsoft\Office\15.0\[programName]\File MRU" and "HKEY_ CURRENT_USER\Software \Microsoft\Office\15.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_USER\Software\Microsoft\Office \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_USER\Software\Microsoft\Office\15.0\Excel 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:\Files\Presentation1.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.

Thursday, February 13, 2014

VSC Toolset Update

I've made various updates to VSC Toolset since its last public release in September 2012 and wanted to write a quick post about some of the updates for those interested. The most significant additions to the tool have been two new batch scripts: one for comparing the contents of a directory between two VSCs and one for extracting the USB device connection and disconnection events from one or more VSCs (based on the event log and Event IDs detailed here).  There have also been numerous user interface and general usability enhancements made to the tool.  Read on for more details, or you can skip to the VSC Toolset page to download the latest version.

CompareDirectory Batch Script

It can be helpful to see how the contents of a directory have changed over time.  For example, identifying how an employment contract has been updated, not updated, or even created and deleted over a period of time can be critical in accomplishing the goals of your examination.  VSC Toolset previously supported (and still supports) running a batch script utilizing diff.exe to compare two VSCs, but that may be overkill in many cases.  Being able to specify a particular directory for comparison is much quicker and helps to eliminate the noise found in the output of running diff.exe against the entire VSC.

The "CompareDirectory" batch script addition to VSC Toolset works by first creating a file listing of each directory to be compared using the "dir" command.  It then compares the two directory listings using diff.exe, generating output similar to the screenshot below.

CompareDirectory Batch Script Sample Output

EventLogUSB-Win7 Batch Script

In my last post, I introduced a batch script that can be executed against a Microsoft-Windows-DriverFrameworks-UserMode/Operational event log originating from a Windows 7 system to identify USB device connection and disconnection events.  In order to port over a version of the batch script compatible with VSC Toolset, I made a couple of slight modifications (primarily to the input variables).  Simply select the linked VSCs against which you want to execute the batch script and click "Run Command"; VSC Toolset takes care of the rest (with some help from Log Parser).  A separate CSV file containing the USB connection and disconnection events is created for each VSC the batch script is executed against.  Note that you'll need the LogParser.exe and LogParser.dll file in the same directory as the VSC Toolset executable for this batch script to work.  Log Parser can be downloaded here.

The real benefit in running the EventLogUSB-Win7 batch script against multiple VSCs is that it allows you to recover USB connection and disconnection events that have since rolled off the current DriverFrameworks-UserMode/Operational event log.  This can be invaluable in cases where the length of time a certain device was connected to the system is important and the time frame of interest is prior to the earliest event in the current DriverFrameworks-UserMode/Operational event log.

Other Updates

In addition to the CompareDirectory and EventLogUSB-Win7 batch scripts, various user interface and general usability enhancements to VSC Toolset were made.  These include tips in the output of some commands (e.g. CompareDirectory) to help make the output easier to understand and a few help buttons added to the interface in some situations (depending on which command is specified in the Command drop-down box) to clarify exactly what a specific parameter is requesting.  The file system view, visible after clicking "Browse Shadow Copy", has also been improved to allow for sorting by file name or date by clicking the appropriate column header.

To ease the burden of finding all of the supporting tools you'll need to take full advantage of VSC Toolset, I've added the download links and any special requirements for each on the VSC Toolset page.  This information was previously scattered across multiple blog posts.

I'm always open to and appreciate feedback, including suggestions for improvement and bug reports.  You can download the latest version of VSC Toolset here.

**Update 02-19-14**
Corey Harrell's auto_rip has been integrated into VSC Toolset.  Version 20140216 includes this update.

Friday, February 7, 2014

USB Device Tracking Batch Script

Last month, I wrote about utilizing the Windows 7 Event Log in USB device tracking.  In my previous post, I mentioned automating the process using Microsoft's Log Parser, but didn't go into much detail regarding how to do so other than a couple of Log Parser queries.  This post introduces a batch script that can be used to quickly identify USB storage devices that have been connected to and disconnected from a Windows 7 system based on information available from the Windows Event Log, specifically the Microsoft-Windows-DriverFrameworks-UserMode/Operational event log.

The Log Parser query described in my previous post identifies the connection and disconnection events associated with a given device identifier, but is limited in that it requires the user to have knowledge of the USB device identifier and must be executed for each device identifier of interest.  In many cases, an examiner will not have knowledge of the device identifier(s) that should be targeted or may be interested in a listing of connection and disconnection events within a particular time period (regardless of the device connected).  This batch script accepts a Microsoft-Windows-DriverFrameworks-UserMode/Operational event log as input and parses the connection and disconnection events associated with each unique USB device identifier, based on the connection and disconnection Event IDs described in my previous post (i.e. 2003 for connect, 2100 for disconnect).

The batch script performs three main steps:
  1. Scans the event log and generates a list of device identifiers
  2. Removes duplicate device identifiers from the list compiled in Step 1
  3. Queries the event log for connection and disconnection events associated with each unique device identifier
It may seem odd at first to remove duplicate device identifiers in Step 2, but this important step eliminates the duplicate entries that would otherwise be found in the script output and allows for quicker execution of the script (as each device identifier will be queried only once within the event log).

Example usage of evtx-usb.bat
The script output is in CSV format and may look something similar to the screenshot below.  The output includes the type of event (connect or disconnect), the device identifier, the time of the event, and the LifetimeID associated with the USB device connection session.

Sample output of evtx-usb batch script
As you can see, the screenshot above details three separate connection sessions for two different USB devices.  We know there are two separate devices because of the different device identifiers and we know there are three separate connection sessions by comparing the LifetimeID values.  For a refresher on the LifetimeID value, see my previous post.

The output of the batch script allows an examiner to easily pair connection and disconnection events using the LifetimeID value as well as quickly determine which devices may have been connected to the system at the same time by identifying different devices with the same LifetimeID.  Since the script output is in CSV format, filtering and sorting is easily accomplished using a spreadsheet editor.

Since the batch script relies on Microsoft Log Parser, you will need to download Log Parser here and ensure LogParser.exe and LogParser.dll are both in the same directory as the batch file.

The script is available for download here.

Thursday, January 30, 2014

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 "Software\Microsoft\Office\15.0\Word\Reading 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. 

Sunday, January 12, 2014

MS Excel 2013 Last Saved Location Metadata

The release of Microsoft Office 2013 granted the ability to save files in formats not previously available (such as "Strict OOXML"), but the default format remained the same as Office 2007 and 2010.  Despite the common file format, I've found that Microsoft Excel 2013 spreadsheets maintain additional metadata not available in earlier versions of Excel.  Specifically, it appears that the absolute path to the directory in which the spreadsheet was last saved is maintained by Excel 2013 spreadsheets.

I have not yet found a tool that presents the last saved location with other metadata from an Excel 2013 spreadsheet, but this information can easily be found by opening the "workbook.xml" file embedded in the parent spreadsheet.  Simply changing the file extension from "xlsx" to "zip" and using a zip-extraction utility to extract the contents of the spreadsheet is a quick way to gain access to the embedded files without requiring any specialized tools.

Workbook.xml contains information about the Excel file such as worksheet names, window height and width parameters, and a bit of other information.  For the most part, this XML file appears to be similar across files created using Excel 2007, 2010, and 2013, however, there is one key difference: the "x15ac:absPath" element.  The "x15ac:absPath" element is a child element of "mc:Choice" (which is a child element of "mc:AlternateContent") and contains an attribute called "url" that corresponds to the last saved location of the spreadsheet.

Workbook.xml file from Excel 2013
Information from the "url" attribute could be helpful in many cases, particularly those in which the previous location of a spreadsheet is significant.  For example, examining this metadata field in a spreadsheet copied to a USB device could allow the examiner to identify the previous directory in which the spreadsheet was saved (before it was copied to the USB device).  It's important to note, however, that resaving a 2013 spreadsheet using Excel 2007 or 2010 appears to remove the "x15ac:absPath" element.

If you know that a spreadsheet was created using Excel 2013 but are unable to find the last saved location metadata, it's possible that the spreadsheet was last saved in a version of Excel other than 2013.  This can be verified through the "fileVersion" element, which is the first child element of "workbook".  The "fileVersion" element includes an attribute called "lastEdited" and, according to Microsoft documentation, the "lastEdited" attribute "specifies the version of the application that last saved the workbook". Interestingly, the value specified in the "lastEdited" attribute is not consistent with the application version of Excel (i.e. 2007=12.x, 2010=14.x, etc.).  Instead, this value is a single-digit numeral corresponding to a particular version of Excel.  I've ran some quick tests using 2007, 2010, and 2013 and summarized the corresponding fileVersion values for each Excel version in the table below.

fileVersion Value to Excel Version Mapping
Importantly, Excel 2013 is aware of the last saved location metadata and will clear this information if the user elects to do so using Excel's built-in Document Inspector. Otherwise, this data should travel with the file until it is saved again, at which point this metadata will either be removed or updated (depending on the version of Excel that saved the file).

Excel 2013 Document Inspector identifies Last Saved Location Metadata