Daily Blog #165: Solving Sunday Funday 12/1/13 Part 3

Hello Reader,
           In the past two posts we've discussed how analysis of attachment access has changed and what artifacts are left behind in the USN Journal when an attachment is closed while Outlook is still running on Windows 7. Today let's talk about another scenario, what happens when an attachment is still open when Outlook closes/the system reboots/etc.. Any condition that makes Outlook not an active process to clean up the attachment opened.

We talked in the last post about how Outlook will delete files after they have been closed, but not what happens when Outlook is no longer running when they are closed. In this case the second temporary extracted file will be deleted while the primary will remain. In this post we will show what this looks like.

First let's look at the MFT, here is what TzWorks Gena tool see's within the MFT as recoverable files using ntfswalk:

There are the two attachments that remain that I sent myself, previewed and then opened. You can see here that the two files are still active and will remain so now until such time as the Content.Outlook folder is emptied, typically from a disk clean up process looking for temporary files to reover. Of the two secondary copies made (the files that end with (2) ), only the pdf version is still recoverable as a deleted record within the MFT.

Within the USN Journal though we have a different story as seen below:

Click on the image to see it full size and view the records.

From accessing two attachments twice,  first as a preview within the message and then opening it within the external program associated, we have 35 USN entries!

The first creations have to do with my preview of the data, after the preview is completed the data is deleted!  We can see that this file was deleted and then re-extracted between the preview and open with external application by comparing the first creation in the USN Journal with the  creation date within the MFT of the file still remaining.

Here is the first creation in the USN relating to the preview:

Here is the second creation is the USN relating to the access with an external associated program:

Here is the MFT Filename attribute dates for the file that remains from the second access:

As you can see the MFT entry relates to the second creation, meaning that Outlook 2007 even cleans up after every preview. Luckily for us the preview still calls out to an external program, the previewer or that file type, so we will still get a USN entry for those accesses as well.

Next week I will show what happens when I open up the attachment again forcing the counter to increase for the filename and what other recoverable artifacts there might be with this artifact.

I'm uploading this test image now for your own verification and I'll update this blog when the link is ready.

Update: Here is the test image for download!

Daily Blog #164: Solving Sunday Funday 12/1/13 Part 2

Hello Reader,
        Yesterday we left off with a general description on what changed between Windows XP/Vista and 7 as well as versions of Outlook prior to 2007 and their impact on the forensic analysis of attachment access. Today let's go deeper into the artifacts with what is created when attachments are accessed in a Windows 7 system running Outlook 2007.

In this post we will go over whats left in the $MFT, USN Journal and $Logfile when an attachment is accessed and closed before outlook closes. Tomorrow we will focus on what the artifacts look like when the attachment is left open after outlook closes and then finish up this series with conclusions we can draw to answer sundays challenge.

In my test image, which I will provide for you to download tomorrow, I have a Windows 7 system that I have done a couple tests on. I have installed Outlook 2007, Word 2007 and Adobe Reader on this system. I then created a new email account with Yahoo! called sensorsuspect@yahoo.com and emailed it two different attachments, one pdf version of my cv and one docx version of my cv. I sent two different file types as they create different artifacts from normal access.

When first thinking about this issue you might think that the MRU's for the extensions pdf and docx would be get updated with these files. I have searched the NTUSER.DAT registry for the user minutes after these accesses and within the allocated registry there is no entry made for the opening of these pdf and docx files. Contained within the unallocated space in the registry using yaru from TzWorks I was able to find the following deleted value:

"C:\Users\Suspect\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook\AGI0N64C\cv_cowen_2013.docx"

Left behind by the Microsoft Office Word Previewer when I previewed the message for a second time before opening the attachment directly within Microsoft Word.

So no LNK, no Jumplist, no MRU recent documents key gets created in this access. Within the $MFT I can see only one of the temporary files that was deleted from my first viewing, the other having already been purged out.

This leaves us with the $logfile and USN Journal. The $logfile is helpful here but as the Content.Outlook directory is on a system drive by default it won't last long. So let's look at what the USN Journal knows about my attachment access.

In the 34 seconds that passed between when I opened and closed both attachments we got 18 records from the USN Journal. We can see when each attach was first opened by looking at the file_created flag and we'll have two file_created events for each file as Outlook 2007 by default is extracting two copies of the file on access. I don't know why this is yet and I have seen occasions when it has been only one.

We can see when I closed the file here with the file_deleted, file_closed event. Outlook deletes the file when I close it and this indicator can be a false positive to file deletion. It does represent thought when the open and active file handle closed against the file.

So why does our second file have a (2) after it? For example cv_cowen_2013.pdf and cv_cowen_2013 (2).pdf? The reason is that Outlook never overwrites an existing file and if there are older copies of the attachment that still exist within the 'Content.Outlook' directory the next number in sequence will be used for the newly extracted file.

Interested yet? The USN Journal is an amazing artifact for us in our analysis of Windows Vista and 7 systems, if you are not looking at it, you should be!

Tomorrow lets see what it looks like when I the attachment remains and talk about possible conclusions we can draw.

Daily Blog #163: Solving Sunday Funday 12/1/13 part 1

Hello Reader,
           This weeks Sunday Funday seems a good candidate for further explanation given the small number of responses received. So this week lets go through the artifacts I would look at (and have looked at in real cases) to solve this challenge. As a reminder here was the questions asked:

Please detail how on a Windows 7 system running Outlook 2007 you can determine:
1. What attachments were accessed in the last two weeks
2. When attachments were accessed
3. How many times attachments were accessed

So let's start with Question 1. How do you determine what attachments were accessed in the last two weeks on Windows 7 using Outlook 2007. In prior versions of Outlook and Windows this was a pretty easy task. As the winner pointed out you can go to the temporary directory where Outlook will extract attachments to see what exists. Standard protocol prior to his combination of OS and Outlook versions would then allow you to see what number is appended to the end of the file name.

For example if an attachment was named 'TopSecret.doc' and accessed three times over a period of time you would see the following attachments extracted in the OLK directory for older versions of Outlook/Windows:
TopSecret.doc
TopSecret(2).doc
TopSecret(3).doc

You would then look at the Filename timestamps in the MFT to determine when the attachment was accessed as Outlook will reset the Stdinfo timestamps to the time the email was sent. Outlook would rarely clean up after itself in prior versions leaving great evidence for quite some time.

This protocol is not as useful as it used to be for the following reasons:

1. Outlook 2007 will delete an attachment when it is closed from the Content.Outlook directory. If Outlook closes while the attachment is still open then the attachment will remain there.
2. Windows 7 will defrag once a week meaning older attachments deleted entries will be purged from the MFT
3. Outlook 2007 will extract two copies of the attachment, up to three on preview and open, meaning you can't rely only on the number after the filename.

So we are left looking for alternate sources, the one we rely on the most now for these accesses is the USN Journal. The USN Journal tracks all file creations, renames, opens, closes, changes and deletions. As such we filter the USN for the MFT reference number of the Content.Outlook folder to find all the attachments opened within it, timestamped to their opening. You might be tempted at this point to take the time of open and close of a file to indicate the total time open, but this can be a red herring as our testing has shown that file handles are closed while a process is backgrounded and then reopened later when activity resumes.

Tomorrow I'll go into detail on the artifacts left in the USN.