microsoft office 2007-2010 registry artifacts...

AccessData Dustin Hurlbut

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 XP – 2002 – Version 10.0




According to a reference in Wikipedia, Microsoft skipped the 13th

version number1. Figure 1 shows a

system with Office 2000, Office 2007, and Office 2010 installed with the 2007 version registry keys


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,


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).


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.

Associated MRU Dates

Access MRUs


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


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)


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

Microsoft Save As dialog box. Those that are using their own proprietary box will not appear

in ComDlg32 keys as this keyset is only

Save As dialog box.

DATE AND TIME INDICATIONS

In Office 2007, Microsoft added a new feature to

now a header that precedes the path

The header is defined by a bracketed [F00000000]. Following this is a second bracketed dataset starting

with a “T”. The numbers following the T

last opened by the user. This is true for both Word and Excel. H

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

documents are opened, this behavior may change.

same time in the same application, saving

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

The information is saved in a non-standard 64

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.

and the dataset is stored as a big endian value

Using the DCode converter created by Craig Wilson

For example, in Figure 10, the first Word document

by the user on August 18, 2010 at 18:46:27 UTC time.

This was determined by copying the Unicode date and time stamp value only

“T”), pasting it into the DCode program, and selecting

the conversion format.

Dustin Hurlbut


keyset is only referencing documents that pass through the Microsoft

Microsoft added a new feature to the MRUs for Excel, PowerPoint, and Word. There is

path statement in the value (see Figure 11).


. The numbers following the T appear to be a date/time stamp of when the document was

is true for both Word and Excel. However, in PowerPoint, it is either the


Each save in PowerPoint trips this value again.

is dependent on a user opening a single document at a time. If multiple

documents are opened, this behavior may change. If multiple documents are opened

in the same application, saving one of them changes the order in the



change the date and time stamp in the three products.

Figure 11 – Word MRU List Header

standard 64-bit Windows date and time stamp. The typical format in


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

Word document with the T header value outlined in red

by the user on August 18, 2010 at 18:46:27 UTC time.

ing the Unicode date and time stamp value only (all numbers beyond the

, pasting it into the DCode program, and selecting the “Windows: 64 bit Hex Value


documents that pass through the Microsoft

MRUs for Excel, PowerPoint, and Word. There is


time stamp of when the document was

in PowerPoint, it is either the


nt on a user opening a single document at a time. If multiple

If multiple documents are opened at the

changes the order in the MRU placing



bit Windows date and time stamp. The typical format in


However, in the Office MRUs, the format is in Unicode,

allows the user to convert these dates and times.

with the T header value outlined in red was opened

(all numbers beyond the

Windows: 64 bit Hex Value – Big Endian” as


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


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”).


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.


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.


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.


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).


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.


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

1

2

3

3

4

4

Live Key Document Information

Deleted Key Document Information


<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.

Figure 21 – Regular Expression to Locate Deleted Document Recovery Keysets

2007 DocRecovery=\x04\x00{3}.{8}[a-z]\x00\:\x00\\.{500}


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