Journey Into Incident Response

I recently had the opportunity to attend the SANs Digital Forensics and Incident Response summit in Austin Texas. The summit was a great con; from the outstanding presentations to networking with others from the field. I gave a SANs 360 talk about my technique for finding fraudulent word documents (I previously gave a preview about my talk). I wanted to release my slide deck for anyone who wanted to use it as a reference before my paper is completed. You can grab it from my Google sites page listed as “SANs 360 Detect Frauduelent Word Documents.pdf”.

For those who were unable to attend the summit can still read all of the presentations. SANS updated their Community Summit Archives to include the Forensics and Incident Response Summit 2012. I highly recommend checking out the work shared by others; a lot of it was pretty amazing.

Anyone who looks at the topics I discuss on my blog may not easily see the kind of cases I frequently work at my day job. For the most part my blog is a reflection of my interests, the topics I’m trying to learn more about, and what I do outside of my employer. As a result, I don’t blog much about the fraud cases I support but I’m ready to share a technique I’ve been working on for some time.

Next month I’m presenting at the SANs Forensic and Incident Response Summit being held in Austin Texas. The summit dates are June 26 and 27. I’m one of the speakers in the SANs 360 slot and the title of my talk is “Finding Fraudulent Word Documents in 360 Seconds” (here is the agenda). My talk is going to quick and dirty about a technique I honed last year to find fraudulent documents. I’m writing a more detailed paper on the technique as well as a query script to automate finding these documents but my presentation will cover the fundamentals. Specifically, what I mean by fraudulent documents, types of frauds, Microsoft Word metadata, Corey’s guidelines, and the technique in action. Here’s a preview about what I hope to cover in my six minutes (subject to change once I put together the slides and figure out my timing).

What exactly are fraudulent documents? You need to look at the two words separately to see what I’m referring to. One definition for fraudulent is “engaging in fraud; deceitful” while a definition for document is “a piece of written, printed, or electronic matter that provides information or evidence or that serves as an official record”. What I’m talking about is electronic matter that provides information or serves as an official record while engaging in fraud. In easier terms and the way I describe it: electronic documents providing fake financial information. There are different types of fraud which means there are different types of fraudulent documents. However, my technique is geared towards finding the electronic documents used to commit purchasing fraud and bid rigging.

There are a few different ways these frauds can be committed but there are times when Microsoft Word documents are used to provide fake information. One example is an invoice for a product that was never purchased to conceal misappropriated money. As most of us know electronic files contain metadata and Word documents are no different. There are values within Word documents’ metadata that provide strong indicators if the document is questionable. I did extensive testing to determine how these values change based on different actions taken against a document (Word versions 2000, 2003, and 2007). My testing showed the changes in the metadata are consistent based on the action. For example, if a Word document is modified then specific values in the metadata changes while other values remain the same.

I combined the information I learned from my testing with all the different fraudulent documents I’ve examined and I noticed distinct patterns. These patterns can be leveraged to identify potential fraudulent documents among electronic information. I’ve developed some guidelines to find these patterns in Word documents’ metadata. I’m not discussing the guidelines in this post since I’m saving it for my #DFIRSummit presentation and my paper. The last piece is tying everything together by doing a quick run through about how the technique can quickly find fraudulent documents for a purchasing fraud. Something I’m hoping to include is my current work on how I’m trying to automate the technique using a query script I’m writing and someone else’s work (I’m not mentioning who since it's not my place).

I’m pretty excited to finally have the chance to go to my first summit and there’s a great lineup of speakers. I was half joking on Twitter when I said it seems like the summit is the DFIR Mecca. I said half because it’s pretty amazing to see the who else will be attending.  

Performing examinations on the Windows 7 (and possibly 8) operating systems is going to become the norm. In anticipation of this occurring, I’m preparing myself by improving my processes, techniques, and knowledge about the artifacts found on these operating systems. One artifact others brought to my attention but I never tested until recently are Jump Lists (Harlan has an excellent write-up about Jumplist Analysis). I wanted to share a quick tidbit about Microsoft Word’s Jump List.

I knew Jump Lists were a new artifact in Windows 7 which contain information about a user’s activity on a system. I thought the user activity information would resemble something similar to link files showing what files were accessed as well as timestamps. I didn’t fully realize how much more information may be available about a user’s activity in Jump Lists until I started using Harlan’s jl.pl script included with WFA 3/e (my WFA 3/e five star review can be found here). I ran a simple test. Create a Word document and see what information jl.pl parses from Word’s Jump List located in the AutomaticDestinations folder. The following is a snippet from the output:

C:\Export\jumplist-research\AutomaticDestinations\adecfb853d77462a.automaticDestinations-ms

Thu Mar 8 02:20:50 2012 C:\fake-invoice.docx
Thu Mar 8 02:17:20 2012 C:\logo.png
Thu Mar 8 02:17:03 2012 C:\Users\test\AppData\Roaming\Microsoft\Templates
C:\Users\test\AppData\Roaming\Microsoft\Templates\TP030002465.dotx

Now let’s breakdown the output above. I identified the Microsoft Word 2007 Jump List (adecfb853d77462a.automaticDestinations-ms) using the list of Jump List Ids on the Forensic Wiki. The last entry shows I accessed a document called fake-invoice.docx at 02:20:50 on 03/08/2012. The other two entries contain information that was previously not available when examining link files. The second entry shows I used Microsoft Word to access an image called logo.png 30 seconds before accessing the fake-invoice.docx document. In addition, the third entry shows the first thing I accessed was a Microsoft Office template. The recorded activity in the Jump List shows exactly how I created the document. I first selected a template for an invoice and made a few changes. To make the invoice look real I imported a company’s image before I saved the document for the first time at 02:20:50.

When analyzing user activity prior to Windows 7 we could gather a lot of information about how a document was created. We could use the information to try to show how the document was created but it wasn’t like the play by play found in the Jump List. Microsoft Word records the files imported into a document and this information may be useful for certain types of cases. For me this information is going to be helpful on financial cases where templates are used to create fraudulent documents. Not every Jump List exhibits this behavior though. I tested something similar with PowerPoint and the following snippet shows what was in the Jump List.

C:\Export\jumplist-research\AutomaticDestinations\f5ac5390b9115fdb.automaticDestinations-ms

Thu Mar 8 02:31:03 2012 C:\Users\Public\Videos\Sample Videos
Thu Mar 8 02:30:32 2012 C:\Users\Public\Pictures\Sample Pictures
Thu Mar 8 02:27:46 2012 C:\Users\test\Desktop
C:\Users\test\Desktop\Presentation1.pptx

As the output shows, PowerPoint only records the objects imported down to the folder level. The entries don’t show the video and image’s filenames I added to the presentation. However, Microsoft Word records the filenames and this is something to be aware of going forward because it provides more information about what a user has been doing with the program.

Nothing ground breaking but just something I noticed while testing.

….. Or more specifically why is Microsoft Office metadata what it is?

Microsoft Office documents contain metadata that may be relevant to a digital forensic examination. The metadata may show when a file was created, modified, printed, or what user accounts were used to perform those actions. Others have already researched the metadata in Microsoft Office 2003 and 2007 documents including providing programs to parse the metadata. A few of the write-ups are: Kristinn Gudjonsson’s Office 2007 metadata post, and Lance Muller’s Office Metadata EnScript & Updated Office 2007 Metadata EnScript posts. I was interested in understanding how different actions taken against a Microsoft Office document affect its metadata.

To help show the relevance of Office documents’ metadata I included the metadata from one of my test Word 2007 documents. Usually I manual examine the information in metadata on an as needed basis but I thought for this post it would be cleaner to show the information in report format. The text below is the output from Kristinn’s read_open_xml_win.pl script ran against a test Word document. The File Metadata section shows when the file was created, modified, printed, and what user accounts were used to perform those actions. Did you notice the last print date/time (2011-05-27T19:09:00Z) occurred one minute before the file was even created (2011-05-27T19:10:00Z)? I’ll touch on this later in the post which is why I pointed it out.

Document name: E:\office metadata testing\word 2007\Xp-2007-1sp.docx
Date:
--------------------------------------------------------------------------
Application Metadata
--------------------------------------------------------------------------
Template = Normal.dotm
TotalTime = 2
Pages = 1
Words = 1
Characters = 9
Application = Microsoft Office Word
DocSecurity = 0
Lines = 1
Paragraphs = 1
ScaleCrop = false
Company = Test-lab
LinksUpToDate = false
CharactersWithSpaces = 9
SharedDoc = false
HyperlinksChanged = false
AppVersion = 12.0000
--------------------------------------------------------------------------
File Metadata
--------------------------------------------------------------------------
title =
subject =
creator = test-2007
keywords =
description =
lastModifiedBy = test-2007
revision = 2
lastPrinted = 2011-05-27T19:09:00Z
created = 2011-05-27T19:10:00Z
modified = 2011-05-27T19:10:00Z

Usernames in Microsoft Office Metadata

Before looking into how different actions against a Microsoft Office document affect its metadata I think it is useful to know more about the usernames reflected in the creator and modifiedby attributes. The usernames are not populated with the name of the user account that performed the action since there is a value in the Windows registry containing the name to use.

When Office 2003 and 2007 is installed there is prompt asking for a user name and company. Those fields are already prepopulated with the information entered when the operating system is installed which is located in the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion (thanks Greg Kelly for this info). The prompt gives the user an opportunity to either change the user name or company or to leave the fields with the information entered during OS installation.

There is a registry key containing what user name and company was used when Microsoft Office was installed. To locate the registry key the Office program’s GUID must first be determined and this Microsoft article explains how to locate the GUID. The GUID of Microsoft Office programs I tested were 9040110900063D11C8EF10054038389C for Microsoft Office Professional Edition 2003 and 00002109110000000000000000F01FEC for Microsoft Office Professional Plus 2007. The registry key containing the information about the Office installation is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\{GUID}\InstallProperties. The regowner and regcompany values in the registry key contain the user name and company entered during the Office installation.

The usernames and company information reflected in Microsoft Office documents’ metadata are pulled from the UserInfo registry key of the user account’s NTUSER.DAT hive performing the actions. The names of the two values containing the data in the registry key are UserName and Company. The location of the registry key varies depending on the version of Microsoft Office but the paths below show where the key is located for Office 2007 and 2003.

Microsoft Office 2007: HCU\Software\Microsoft\Office\Common\UserInfo
Microsoft Office 2003: HCU\Software\Microsoft\Office\11.0\Common\UserInfo

Now the question I found myself asking is how are the UserName and Company values initially populated in the UserInfo key? I previously explained the user name and company during Office installation because the entered information is used to populate the UserInfo registry key of the user account that installed Microsoft Office. For the user accounts on the system that are using Microsoft Office but didn’t install it, the values are populated a little different. The first time the user launches an Office application a dialog box appears asking for the user name and initials. The dialog box is prepopulated with the name of the currently logged on user. The information entered in the dialog box is what results in the username value in the user's UserInfo key while the company value comes from the information entered when the Office was installed.

The metadata shown above now has a little more meaning. The username test-2007 is not the name of the user account that created and modified the document but is the name listed in the UserInfo registry key. The name in the UserInfo registry key can be changed at any point but any changes will alter the last write time on the registry key. This means the last write time of the user account’s UserInfo key should be taken into consideration when examining metadata. If the registry key last write time is before the dates/times in the metadata (create, modify, or print) then the metadata reflects what is currently in the user account’s NTUSER.DAT hive. On the other hand, if the registry key last write time is after the metadata timestamps then what is currently in the user account’s NTUSER.DAT hive may not be what was there when the action was taken against the Office document (did I just hear someone whisper check the restore points or volume shadow copies for registry files).

How Actions Change Microsoft Office Metadata

The testing I conducted consisted of creating one document then performing different actions against copies of the document to see how the metadata changed. I only ran the tests against documents created by the following programs: Word 2007, Word 2003, Excel 2007, and Excel 2003. If I test other Office Programs in the future then I’ll update the post to reflect it. The observed changes in the documents’ metadata were consistent across all of the different versions of Office but there were some minor differences between the different file types. The Excel metadata differed from Word in the following ways: there was no revision number, some timestamps contained seconds, and the Save As function didn’t change the documents’ creation date.

I’m providing charts of how the metadata was affected by the different actions taken against the documents. The chart has information in the parenthesis to show what the metadata values were for one set of documents (the timestamps don’t include the date since it was the same for all of the documents).

Here’s the Microsoft Office Word Metadata Changes chart and Microsoft Office Excel Metadata Changes chart.

The charts show how different actions against a Microsoft Office document affect its metadata. There are quite a few takeaways but I’m only going to highlight a few.

* The metadata create date/time reflects when the Office program was opened as opposed to the first time the document was saved
* Copying an Office document doesn’t changed the metadata
* The metadata print date/time only changes when the document is saved after it is printed
* The Save As function results in the Word metadata create and modification date/times being the same while the modification date/time only changes in Excel metadata

Now let’s go back to the metadata I posted above. Do you remember that the last print date (2011-05-27T19:09:00Z) occurred one minute before the file was even created (2011-05-27T19:10:00Z)? There was one action taken against a Microsoft Word document that produced this pattern in the metadata. The action was printing a document then using the Save As function to create a new document. The metadata shown above is from the newly created document.

Hopefully, the sharing of my test results can help others who are pondering the question “why is Microsoft Office metadata what it is”.