Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
AccessData Dustin Hurlbut Page 1
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 13th
version number1. Figure 1 shows a
system with Office 2000, Office 2007, and Office 2010 installed with the 2007 version registry keys
AccessData Dustin Hurlbut Page 2
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 3
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 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
AccessData Dustin Hurlbut Page 5
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 6
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 7
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
Microsoft Save As dialog box. Those that are using their own proprietary box will not appear
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 header is defined by a bracketed [F00000000]. Following this is a second bracketed dataset starting
. 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
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.
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
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
standard 64-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
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
Page 8
Microsoft Save As dialog box. Those that are using their own proprietary box will not appear
documents that pass through the Microsoft
MRUs for Excel, PowerPoint, and Word. There is
The header is defined by a bracketed [F00000000]. Following this is a second bracketed dataset starting
time stamp of when the document was
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.
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
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
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
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
AccessData Dustin Hurlbut Page 9
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 10
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 11
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 12
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 13
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 14
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 15
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 16
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
AccessData Dustin Hurlbut Page 17
<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}
AccessData Dustin Hurlbut Page 18
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