Daily Blog #170: Solving Sunday Funday 12/1/13 Part 4 USN Anaysis of non outlook attachments

Hello Reader,
      We've talked quite a bit about the USN Journal by this point in its use to analyze attachment access from Outlook 2007 on Windows 7. Today I wanted to extend the discussion to what the USN Journal contains when a non outlook 2007 attachment is accessed. The USN Journal seems simple when you first review it, but the underlying meaning of its reasons codes are not as simple as they appear.

I created a file in c:\users\suspect\documents called 'test.txt' and populated it with one line of information. This is what the USN Journal shows for that initial creation and save:

File Creation:
This is where it gets interesting, notice the first line says the reason coed is File_Create, this is in fact what happened at this point. However as line 2 with USN number 2363040 shows we have another File_Create reason code here with a close. This is tricky though as the file is not being created again at this point, just the handle being closed from the initial creation. Based on our testing we can see we have three more file_create reason codes listed at 23693488, 23693568, and 23693648.

File Deletion:
What is even stranger than the file_create is the file_delete we see in USN 23693120, the file was not deleted. The file handle that was used to create and then open the file was. This is important to understand and can greatly affect your  conclusions when you are looking at USN data, so always check your assumptions carefully as to when a file is actually being created and deleted against other sources such as the $logfile, $mft and timestamps from shell items.

File Modification:
You can see when I placed data into the notepad document in USNs 23693568 and 23693658 shows the Data_Extend reason code. Data_Extend will be seen whenever additional data is written to a file.

File Close:
Within this USN log you would think I have closed this file three times within the same minute. The first close is seen on USN 23693040 and refers to when the file was first created. The second close is seen on USN 23683120 is when the file handle was closed from the creation. The third close on USN 23694560 is from when I saved the file after changing its contents.

At this point I have created a text file, opened it in notepad and added a line of text to it. I left it open at this point for 4 hours and then went back and added one more line of data as can be seen below:

As you would expect and saw in the prior section I have a data_extend again, but this time we also have a data_overwrite. If the prior contents of a file are being changed you will see a data_overwrite. I then saved my changes resulting in the close that you see in USN 23975120 and closed the application.

Lastly I waited 13 minutes and then deleted the file from the file system using a shift delete within explorer to skip the recycle bin as seen below:

In this case I actually did delete the file, but there is nothing special about this reason code that separates it from the same code was saw when I first created the file. Here again you as an examiner need to look into what the USN reason code is actually referring to.

Conclusions:

The USN Journal shows without additional analysis that a file called test.txt was accessed by me during this time frame. We can also state that files are modified and changed when Data_extend and Data_overwrite as these only seem to be logged on file content changes. These facts are something you can rely on and testify to. What the USN Journal needs additional analysis to verify is:

• The total time of usage of the file as a file close/open does not correspond to the total time a file is open for
• When a file is created for the first time as the USN records all file handles as creates.
• When a file is deleted from the file system as file handle closes also create these reason codes.

We can reach these additional analysis points with analysis comparing these files to their timestamps and actions from other artifacts on the system. Tomorrow let's do just that and show how to determine the actual creation and deletion times.

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.

Daily Blog #51: Understanding the artifacts USNJrnl

Hello Reader,
        I'm going to change tracks this week and focus on a deeper understanding of the USNJrnl and its associated artifacts to prove usage from our challenge two weeks ago. To prepare for this series I want to take a bit to explain what each of the artifacts we rely on for proof of usage were created for. When we are complete I hope you will look at your cases in a different way.

Today we are going to talk about the USNJrnl. The USN Jrnl or Update Sequence Number Journal aka the Change Journal was first introduced in Windows 2000 but didn't get enabled by default until Windows Vista (that I know of, please leave a comment if you have evidence of other default states/os's). I have seen it enabled for EFS encrypted drives on XP but I can't say if that's a default setting.The concept of the change journal was simple, many programs need to know when files are changed so they can be backed up, compressed, scanned, replicated, etc...

Prior to the change journal a developer would have to register hooks or shims into the operating system for all reads and writes to be able to be notified that a file is being created/modified/deleted and to process it. The Change Journal gave the developer a central api to monitor that covered all subscribing functions and prevented  a lot of unnecessary overhead. You can read more about the basics of the Change Journal here on wikipedia. The original announcement of it was made in September 1999 and can be found here its interesting that it took as long as it did for it to be enabled by default. You can see that it was being marketed to developers as a way to centrally monitor file system changes and improve performance.


The current change journal development documents are here and if you relying on change journal evidence in your cases you should be familiar with the use case scenario because things are not as black and white as they appear. What do I mean by that? In our testing we've found that a file left open overnight and accessed at different times will create multiple USN open/close/delete events. You cannot rely on the file open and file close times of a file to determine total time of access, it may only be showing you the times of activity against a file that was open the entire time. In addition we've found file close/file delete being used to close a file handle but not to delete the file itself.

I'm going to into more detail of how individual Change Journal operations work and get logged as we move forward so I don't want to get ahead of myself. So in summary remember that the Change Journal keeps track of file system changes for the benefit of those subscribing services. If you are unsure of a pattern of records your seeing the best thing you can do is build a virtual machine and try to recreate those actions to validate your assumptions. The Change Journal is not as simple as we all though it to be! Tomorrow I'm going to continue talking about Usage artifacts and then go into depth on the Change Journal and the rest of them.