Microsoft Office 2007, 2010 Registry Artifacts Dustin Hurlbut September 16, 2010 INTRODUCTION Previous versions of Microsoft Office used application specific registry artifacts to track opened documents. Largely, they were not consistent and some were not functioning by default. Their forensic importance was limited in some versions to showing documents that had been saved or saved using the Save As dialog box. With the release of Office 2007, the application specific artifacts were changed and would appear to have greater forensic significance. Besides storing a larger number of Most Recently Used (MRUs) information that denotes a document was opened, some of the Office applications now contain a date and time stamp that refers either to when the document was last opened or when that document was last saved by the user. This paper will cover the new application specific artifacts as well as default artifacts from the operating system. It will show how they are created and what criteria seem to affect their modification. MRU INFORMATION Previous versions of Microsoft Office used some application specific MRUs information which was stored in the registry. The information is stored on a per-user basis and so resides in the NTUSER.DAT registry file located at: C:\Documents and Settings\<username> Windows 2000 and Windows XP C:\Users\<username> Windows Vista and Windows 7 The information was stored in the following path in the registry: HKCU\Software\Microsoft\Office\<version#>\<appname> The version number for various Office installations are: Office 97 Version 8.0 Office 2000 Version 9.0 Office XP 2002 Version 10.0 Office 2003 Version 11.0 Office 2007 Version 12.0 Office 2010 Version 14.0 According to a reference in Wikipedia, Microsoft skipped the 13 th version number 1. Figure 1 shows a system with Office 2000, Office 2007, and Office 2010 installed with the 2007 version registry keys AccessData Dustin Hurlbut Page 1
opened. Multiple versions can exist on the same system. Each has its own separate archive in the registry and they do not seem to intermix. Figure 1 Office 2007 Version Information The <appname> variable would be the application name of Excel, PowerPoint, Word, etc. Earlier versions used MRUs for both Open and Save As, however the archiving of MRU data was inconsistent. Figure 2 shows the Office 2010 version information and registry subkeys. Some Office versions will contain more references to application than others as the subkeys for each are only created on installation of that particular Microsoft product. Also, different applications will have different MRU lists. For example; Access uses the Settings subkey and calls them MRU# (where # is a variable indicating a number), and Excel stores them in a File MRU subkey and calls them Item#. Figure 2 Office 2010 Version Information Microsoft made some major changes to Office 2007 MRU lists from previous versions. The Open and Save As MRUs were replaced with a single MRU called File MRU. Instead of the last twelve or fifteen documents, the number now tracks the last 50 documents opened by the user for Excel, PowerPoint, AccessData Dustin Hurlbut Page 2
and Word (see Figure 3). The File MRU entries are numbered from Item1 to Item50 (decimal numbers). Item 1 is the last viewed and the Item 50 is the furthermost viewed (see Figure 3). Figure 3 Office 2007 Word MRU List There are active MRU lists for Microsoft s installed Office documents. The examples here include the most common: Access (Microsoft s Database application), Excel, PowerPoint, Publisher, and Word. Microsoft Access Stores the nine last opened document MRUs under the Settings subkey. They are named MRU1 MRU9. They contain not only the filename, but the complete path to the file. The Access Database application must be closed before the key is updated. Interestingly, the MRU list also has an accompanying MRU set below them called MRUDate1 MRUDate9. These values match up to the numbers of the MRU set for the files and show the date the particular document was last opened in month / day / year format. So the path and filename match up to the MRUDate1 to show the date that document was last opened (see Figure 4). AccessData Dustin Hurlbut Page 3
Access MRUs Associated MRU Dates Figure 4 Microsoft Access DB MRU List Microsoft Excel Stores the MRUs under the File MRU subkey (see Figure 5). They are named Item1 Item50 and hold up to 50 of the last spreadsheets opened. They contain not only the filename, but the complete path to the file. The Excel application updates the MRU list as soon as the document is opened. Figure 5 Microsoft Excel MRU List Microsoft PowerPoint Stores the MRUs under the File MRU subkey (see Figure 6). They are named Item1 Item50 and hold up to 50 of the last slide shows opened. They contain not only the filename, but the complete path to the file. The PowerPoint application updates the MRU list as soon as the document is opened. AccessData Dustin Hurlbut Page 4
Figure 6 Microsoft PowerPoint MRU List Microsoft Publisher Stores the MRUs under the Recent File List subkey (see Figure 7). They are named File1 File9 and hold nine of the last Publisher documents opened. They contain not only the filename, but the complete path to the file. The Publisher application updates the MRU list as soon as the document is opened. Figure 7 Microsoft Publisher MRU List Microsoft Word Stores the MRUs under the File MRU subkey (see Figure 8). They are named Item1 Item50 and hold up to 50 of the last documents opened. They contain the filename and the complete path to the file. The Word application updates the MRU list as soon as the document is opened. Figure 8 Microsoft Word MRU List AccessData Dustin Hurlbut Page 5
The Windows operating system also creates the MRU values by extension type in the RecentDocs and Comdlg32 registry keysets. The RecentDocs keyset stores the last ten documents opened for each extension type in individual values. They are numbered from 0 to 9 with an additional MRUListEx value that tracks the order they were opened. The value number at the beginning of the MRUListEx is the latest viewed document and the following numbers are in descending order. As seen in Figure 9, the last.docx file viewed is the hex value 0x 07 00 00 00. The number 07 equates to the document file value displayed in the lower pane. The previous document before that was 03, and the one before that was 09. The values can get mixed up as the RecentDocs\<ext> does not store duplicates. A file opened previously that has already been assigned a number is reused if the document is reopened. Opening another document when the MRU list has the full ten values, will drop off the oldest in favor of the most recent document. Figure 9 RecentDocs MRU (Vista OS) AccessData Dustin Hurlbut Page 6
ComDlg32, or Common Dialog, is also used to track documents that have been opened or edited using the standard Microsoft Save As dialog box. It is similar to the RecentDocs MRU and stores the most recent documents by extension. It holds more values, in the case of Vista and Windows 7, storing the last 20. In Windows XP, the path and filename were displayed. However, in Vista and Windows 7, only the filename is archived. Figure 10 displays an example of the MRU values. Note there is an MRUListEx to track the order of access of the documents using decimal numbering in the value name, but using hexadecimal numbers in the MRUListEx value. In the example in Figure 10, the last document processed through the Save As dialog box was a draft of this document as it was being written. It does correspond as the last one in both RecentDocs and ComDlg32. Figure 10 ComDlg32 Common Dialog MRU (Vista OS) Note: Documents shouldn t generally be compared between RecentDocs and the ComDlg32 keysets. Some applications use their own Save As dialog boxes and some use the standard AccessData Dustin Hurlbut Page 7
Microsoft Save As dialog box. Those that are using their own proprietary box will not appear in ComDlg32 keys as this keyset is only referencing documents that pass through the Microsoft Save As dialog box. DATE AND TIME INDICATIONS In Office 2007, Microsoft added a new feature to the MRUs for Excel, PowerPoint, and Word. There is now a header that precedes the path statement in the value (see Figure 11). The header is defined by a bracketed [F00000000]. Following this is a second bracketed dataset starting with a T.. The numbers following the T appear to be a date/time time stamp of when the document was last opened by the user. This is true for both Word and Excel. H However, in PowerPoint, it is either the last time the document was opened by the user or the last time the document was saved by the user. Each save in PowerPoint trips this value again. Note: This sequence is depende dependent nt on a user opening a single document at a time. If multiple documents are opened, this behavior may change. If multiple documents are opened at the same time in the same application, saving one of them changes the order in the MRU placing the latest save on top with the number 1. This MRU set then, will not necessarily be the order opened, but rather the order saved in this scenario. This movement in the MRU list may also change the date and time stamp in the three products. Figure 11 Word MRU List Header The information is saved in a non-standard standard 64 64-bit bit Windows date and time stamp. The typical format in the registry is to store the data in a hexadecimal little endian format. Converters in most forensic tools can read this data and convert the time stamp. However, in the Office MRUs, the format is in Unicode, and the dataset is stored as a big endian value (see Figure 12). Using the DCode converter created by Craig Wilson2 allows the user to convert these dates and times. For example, in Figure 10, the first Word document with the T header value outlined in red was opened by the user on August 18, 2010 at 18:46:27 UTC time. This was determined by copying ing the Unicode date and time stamp value only (all numbers beyond the T ),, pasting it into the DCode program, and selecting the Windows: Windows: 64 bit Hex Value Big Endian as the conversion format. AccessData Dustin Hurlbut Page 8
Figure 12 Converting the Date and Time Stamp in DCode There were minor changes from Office 2007 to Office 2010. In Office 2010, there is an extra section to the header that follows the date and time stamp; [O00000000]. It does not appear to hold any forensic significance. An example of a 2010 MRU is shown in Figure 13. Figure 13 Word 2010 File MRU List AccessData Dustin Hurlbut Page 9
Also added in Office 2010 is an MRU list in each application s subkey called the Place MRU (Excel, PowerPoint, and Word only). The Place MRU subkey tracks paths to opened documents rather than the document itself. If several documents are opened from the same path, only one entry will be placed in this MRU for that path. For example, in Figure 14, there are five documents in the File MRU list, however there are only two entries in the Place MRU. There were only two paths that were used to access the five documents; the Desktop folder and the user s Documents folder. Figure 14 Word 2010 Place MRU List Each of the Place MRU values are numbered Item #. They also contain a date/time stamp just as the File MRUs do. However, the date/time only shows access through that path to the last document opened. Microsoft also added the Access database to the list that now has a File MRU subkey. The MRU# value that was previously used in the Settings subkey was removed. As with Excel, Word, and PowerPoint, it now has a date and time stamp associated with each document opened in the Access program. Access, however, was not given a Place MRU subkey nor a Resiliency keyset for document recovery (see the next section Document Recovery Artifacts ). AccessData Dustin Hurlbut Page 10
Microsoft Access in Office 2010 has a new artifact in the form of an MRU for trusted documents. When you open an Access database for the first time (even one created on the current user's system), Access will display a security warning and ask if you want to Enable Content. Essentially, by pressing the Enable Content button, the user is "trusting" this document (see Figure 15). Figure 15 - Trusting an Access Database document Trusted document MRUs are stored in the following path: HKCU\Software\Microsoft\Office\14.0\Access\Security\Trusted Documents\TrustRecords Each time a user selects Enable Content, that document will be placed in the MRU list for trusted documents. The MRUs are stored in a different manner than most with the path and filename used as the value name and some binary data in the value. The data appears to be stored with the first used on top and the rest in descending order. Figure 16 is an example of the Trusted MRUs. The order they are stored in is the order they were opened and then trusted with Info.mdb coming first, then Packing%20Fiji.mdb and lastly Packing%20CZM.mdb. The actual filenames had a space where this value names displays the" %20". The first eight bytes of each document's value is a 64-bit Windows date and time stamp. The behavior of this time stamp is different and erratic from other MRUs, depending upon the types of files opened. Opening several local databases and trusting them with the Enable Content button, sets the date for each one individually noting when it was trusted. Foreign documents created on another system and copied to the current system updated all of that days opened documents. Trusted documents from previous days did not change. Erratic behavior was observed during testing on several occasions when the dates and times backdated from one day to up to five months on some documents. There were no dates in the databases to correspond with these anomalies. AccessData Dustin Hurlbut Page 11
My conclusion is that forensically, if the document and path are listed, one can conclusively state the document was opened locally with Access at that path. However, the dates and times cannot and should not be relied upon for accuracy. Figure 16 - Access Database - Trusted Document MRU DOCUMENT RECOVERY ARTIFACTS Another feature with Office 2007 and 2010 for Word, Excel and PowerPoint is a method of tracking document recovery that may be useful in forensic investigations. If an Office document is open, by default every ten minutes a backup will be made of the document for recovery purposes in case the application locks up and the document can t be saved normally. This is how Word knows, for example, that when reopened from a crash, it will show a previous auto saved version of the open document at the time of the crash and will ask if that is the document the user wants to save. The following discussion of DocumentRecovery uses Microsoft Word. Excel and PowerPoint work in a very similar fashion. Each existing document opened is tracked in a new subkey called Resiliency\DocumentRecovery\<id>, where <id> is a six or seven random character name created when the document is loaded (see Figure 17). If a new document is made, this keyset isn t created until the document is saved for the first time. AccessData Dustin Hurlbut Page 12
The resulting value, which also bears the same random character code as the subkey name, contains the path, filename, and a date/time of last save for the document in its original path and name. Figure 17 A Word DocumentRecovery Example Once a document is auto saved by the system, it creates a second six or seven character name value that is different than the first. It points to the location of the temporarily saved document (Word =.asd file) created as the backup and includes the path, filename and date/time last saved (see Figure 19). Note there are two values stored with the D69A20F subkey that identifies the document testbedword.docx. One is the location and information on the original document in its last saved state by the user, and the second is the autosave document created by Microsoft. This location is based upon the option settings either defaulted from Word or user set. Figure 18 shows the default settings for the Word document utility. Figure 18 Word Autosave Settings When documents are closed, the DocumentRecovery data is immediately deleted from the registry. A forensic examination of a dead box typically will not have the Resiliency subkey unless the system was on with Office documents open when the plug is pulled. However, depending on the Windows operating system, there is a potential to recover this type of data from unallocated space in the registry. AccessData Dustin Hurlbut Page 13
Figure 19 Word Autosave Information in the DocumentRecovery Subkey An understanding of a live DocumentRecovery archive is essential to enable the investigator to be able to identify them if found in the registry after they have been deleted. If a specific file is sought in an investigation, a keyword search may locate a reference to it in unallocated space in the registry. Being able to recognize this keyset will enable the investigator to conclude that the document was indeed in the system at one time, its actual path in the file structure hierarchy, and when it was last saved from an open state in the application. The value begins with a data header: 0x 04 00 00 00 Offset 12 begins the full path and filename to the document. This is a variable length field and is in Unicode (see Figure 19). AccessData Dustin Hurlbut Page 14
In Microsoft Word, 10 to 12 bytes after the end of the path/filename begins a 64-bit Windows date and time stamp (10 bytes in the temporary file pointer created by an autosave value, 12 in a user save). This value is the date/time that the document was last saved while it was open. If you open a document and don t alter it, the time stamp will not change. As soon as the document is saved with an Alt + F + S or hitting File > Save, the time stamp will change in favor of the current date/time. Locating this type of data in unallocated registry space can prove the existence of a document of interest and when it was last altered. This is particularly important in cases where the original document(s) are no longer on the system. Figure 20 is a comparison of two document references in the Resiliency subkey set. The top example on the left side is an active Word document showing current status of the document. Item 1 is the active subkey header, Item 3 is the date/time last saved, and Item 4 is the path/filename of the document. Note: The offsets of the physical registry values seen in Figure 20 are different than the offsets in logical view of the data in Figure 19. A logical view is showing only the data and not the physical header information. In Figure 19, the header for the logical structure is 0x 04 00 00 00. The actual physical header for the registry value in Figure 20 is 0x 50 fa ff ff which is then followed by the logical header of 0x 04 00 00 00. The panel on the bottom right of Figure 20 shows the same data after the document was closed and the system deleted the Resiliency keyset. The only change to the data is Item 2, the four byte header showing deleted registry information. The path, filename (4), and date and time (3) are still recoverable. Because of changes in the Windows 7 registry which is overwriting deleted registry data sooner than seen in XP and Vista, this may limit the length of time this data is available on a Windows 7 system. AccessData Dustin Hurlbut Page 15
1 4 Live Key Document Information 3 Deleted Key Document Information 2 4 3 Figure 20 Comparison of Live and Deleted DocumentRecovery Data in the Registry Regular expressions can be used to locate these values, since we have a pattern of data in these subkey sets including the header and the pathname beginning at specific offsets. The following FTK regular expression can find DocumentRecovery values in allocated and unallocated space: 2007 DocRecovery=\x04\x00{3}.{8}[a-z]\x00\:\x00\\.{500} This regular expression searches for the data header in the value for RecoveryDocuments; 0x 04 00 00 00. Then it locates eight of anything. It then seeks the Unicode path beginning at offset 12 of AccessData Dustin Hurlbut Page 16
<driveletter>:\ in Unicode. The.{500} reference is used to highlight the next 500 bytes of the hit so the path and filename can be more easily seen. Figure 21 shows what a hit will look like using this regular expression. 2007 DocRecovery=\x04\x00{3}.{8}[a-z]\x00\:\x00\\.{500} Figure 21 Regular Expression to Locate Deleted Document Recovery Keysets AccessData Dustin Hurlbut Page 17
CONCLUSION Office 2007 and subsequently 2010 added some powerful forensic artifacts for the investigator. In the past, it was difficult if not impossible to determine when a document was last opened by the user. This was especially difficult in Vista and Windows 7 since the Last Accessed file system date and time was disabled by default and even if it was enabled, potentially had other meanings. With the Office 2007 and 2010 MRU list, that last opened or last saved time for the document can be seen for the last 50 documents. The new path MRU subkey also shows path access with a date and time. If a user removes incriminating information from the system, these MRUs and paths will remain behind and be available for examination. The DocumentRecovery keyset also has a potential benefit to show files existed on the system that may not currently be in the file system. Since this keyset is deleted when the document is closed, the data must be located using searches of unallocated space in the system. If the investigator can locate and recognize this value, it could be potentially important evidence to show the presence of documents the suspect may claim never existed. 1. http://en.wikipedia.org/wiki/microsoft_office, Wikipedia reference to Microsoft Office versions 2. http://www.digital-detective.co.uk/freetools/decode.asp, DCode by Craig Wilson AccessData Dustin Hurlbut Page 18