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

Archive for Microsoft Office Forensics

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 
· January 13, 2014 
· 1 Comment

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
1 Comment
Categories : Microsoft Office Forensics
Tags : ,
Posted by Jason Hale 
· July 22, 2013 
· 1 Comment

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.

Resources
Microsoft Excel (xls) Binary File Format Specification 

1 Comment
Categories : Microsoft Office Forensics
Tags : , , ,
Posted by Jason Hale 
· July 16, 2013 
· 10 Comments

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.

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

10 Comments
Categories : Microsoft Office Forensics
Tags : , ,

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.