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

Thursday, January 2, 2014

The Windows 7 Event Log and USB Device Tracking

Recently, there have been a few blog posts discussing evidence found on a system when USB devices are connected and removed (Yogesh Khatri's blog series and Nicole Ibrahim's blog).  I've been meaning to release this post for a while and Yogesh and Nicole's posts have motivated me to do so.  Much of the conversation regarding USB device activity on a Windows system often surrounds the registry, but the Windows 7 Event Log can provide a wealth of information in addition to the registry. Utilizing the Event Log during USB device investigations has been mentioned in various other locations, including chapter 5 of Harlan Carvey's Windows Forensics Analysis 3/E (and recently in Yogesh Khatri's blog).  This post discusses both USB device connection and disconnection artifacts found in the Windows 7 Event Log, specifically the Microsoft-Windows-DriverFrameworks-UserMode/Operational log, and explores an interesting value that can be used to pair a device's connection event with its associated disconnection event.

Connection Event IDs

When a USB removable storage device is connected to a Windows 7 system, a number of event records should be generated in the Microsoft-Windows-DriverFrameworks-UserMode/Operational event log.  The records include those with Event ID 2003, 2004, 2005, 2010, 2100, 2105, and more.  Some of the generated event records contain identifying information about the USB device that was connected.  For example, when viewing an event record with Event ID 2003 using the Windows Event Viewer, the event information below is displayed.

Connection Event Record
A portion of the text formatting in the screenshot above above should look familiar to most, as it contains some of the same information about a USB device that can be found in the SYSTEM hive. Importantly, the device serial number ("000ECC0100087054") is stored in last portion of the event record's strings section. Combined with the record's TimeGenerated field, an examiner can derive the date and time that a USB device was connected to the machine.

Disconnection Event IDs

When a USB thumb drive is disconnected from a Windows 7 system, a few event records should be generated in the same event log as the connection events.  Records with Event ID 2100, 2102, and potentially more may be generated when a USB device is disconnected.  Variables such as whether there is another USB removable storage device still connected to the system at the time a USB device is disconnected can dictate which event records are generated and which are not.  Some records, however, appear to be more consistent.  For example, it appears that an event record with Event ID 2100 and the text "Received a Pnp or Power operation (27, 23) for device <deviceInfo>" is consistently generated when a USB removable storage device is disconnected from a system.  In addition, the same event record should contain the device's serial number/Windows unique identifier that can be mapped to a device.  An example of some of the information available from a disconnection event record with Event ID 2100 can be seen in the screenshot below.

Disconnection Event Record

LifetimeID Value

The LifetimeID value associated with a USB device's connection session is an interesting piece of information.  This GUID value is assigned to a UMDF (User Mode Driver Framework) host when a USB device is connected and should remain the same throughout the connection "lifetime" of the device.  In other words, an examiner should be able to match the LifetimeID written to a device's connection event records with the LifetimeID written to the device's disconnection event records in order to tie a particular disconnection event with its associated connection event.

This is simple enough when a single USB device is used, however, when multiple USB devices are used at once, they appear to all use the same UMDF host and are all assigned the same LifetimeID.  This means that a LifetimeID value cannot be tied to a single USB device, but it appears that it can be used to correlate device connections and disconnections on a per-session basis.

LifetimeID from Disconnection Event Record
Utilizing the LifetimeID associated with a device connection session can help in developing a timeline that, among other things, indicates the length of time a particular device was connected to the system.  In addition, the LifetimeID is useful in pairing a device's connection event with its corresponding disconnection event.  Since there may not be the same number of connection and disconnection events (e.g. a device is removed after the system has been powered down so no disconnection events are generated), the LifetimeID can help to make sense of various connections and disconnections and correctly pair the two together for a particular device.

In addition to being used to determine the length of a USB device's connection session via the Windows Event Log, the LifetimeID value may play an interesting and useful role in determining the time a USB device was last disconnected from the system, based on the LastWrite time of a registry subkey.  I'll forego this discussion for now since this post is focused on event records, but will revisit this topic later.


Automating the process of identifying connection and disconnection event records can really allow the power of utilizing the Windows Event Log in USB analysis to shine. While entirely possible, it would be a tedious process to manually analyze the Windows Event Log for USB connection/disconnection events.  Microsoft Log Parser is a great tool for processing the Event Log in this manner.  Given that event records associated with a device's connection and disconnection will contain identifying information as well as a timestamp, it's just a matter of isolating the event records associated with connection and disconnection and parsing portions of the strings section of the record.  For example, the Log Parser query below returns all event records with Event ID 2003 (connect) or 2100 (disconnect) as long as the device serial number/Windows unique identifier ("1372995DDDCB6185180CDB&0" in this case) is contained in the Strings portion of the event record and, in the case of a disconnection event, the text "27|23" is also in the Strings portion.
logparser -i EVT -o datagrid "SELECT EventID, TimeGenerated FROM Microsoft-Windows-DriverFrameworks-UserMode-Operational.evtx WHERE (EventID=2003 AND STRINGS Like '%1372995DDDCB6185180CDB&0%') OR (EventID=2100 AND STRINGS LIKE '%1372995DDDCB6185180CDB&0%27|23%')"   
Output of Log Parser query above
If you want to clean up the output and add a bit more information, you can use the Log Parser query below (replacing "1372995DDDCB6185180CDB&0" with the USB serial number/Windows unique identifier you're interested in).
logparser -i EVT -o datagrid "SELECT CASE EventID WHEN 2003 THEN 'Connect' WHEN 2100 THEN 'Disconnect' END As Event, TimeGenerated as Time, '1372995DDDCB6185180CDB&0' as DeviceIdentifier, EXTRACT_TOKEN(Strings,0,'|') as LifetimeID FROM Microsoft-Windows-DriverFrameworks-UserMode-Operational.evtx WHERE (EventID=2003 AND STRINGS Like '%1372995DDDCB6185180CDB&0%') OR (EventID=2100 AND STRINGS LIKE '%1372995DDDCB6185180CDB&0%27|23%')"
Output of Log Parser query above
As you can see, Log Parser dramatically reduces the leg work involved in analyzing event records for USB connection and disconnection events.  Moreover, Log Parser queries can easily be incorporated into a batch script that allows the examiner to input the device serial number he or she is interested in to quickly identify the connection and disconnection events associated with the device.  The LifetimeID value can then be used match associated connection and disconnection events.

As with other event logs, event records in the Microsoft-Windows-DriverFrameworks-UserMode/Operational event log eventually roll over, leaving the examiner with a limit on how far back in time he or she can go.  However, utilizing VSCs can allow an examiner to squeeze a bit more out of this approach and ultimately build a very telling history of USB device connection and disconnection events.