Daily Blog #393: Exploring Extended MAPI Part 7

Hello Reader,
          I've been wondering in the last several posts about what happens to exported messages when different users edit the message. I finally got a chance to test this today and document my results here. To do this I exported a message from my SANS FOR500 instructor laptop on to a USB external storage device.

Once I exported the message I loaded up the message on my SANS instructor laptop and with Outlook spy inspected the last modification time and name.

Next I took that external storage device and I plugged it into my surface book where I usually write these blog posts and opened up the message from the external storage drive to see if just opening it as another user would change this data.

As you can see nothing changed which is what I was hoping would be true.

However what happened next surprised me. In order to try to modify the message and get the Extended MAPI fields to update with my work email address of dcowen@g-cpartners.com I did the following:

1. I set a follow up flag as completed
2. I replied to the message
3. I removed a file attachment from the message

After I did each step I checked the Extended MAPI and found that the values didn't change! This is what the Extended MAPI fields looked like after I did all three things.

Notice that PR_LAST_MODIFIER_NAME_W and PR_LAST_MODIFICATION_TIME have not changed from the prior screenshot. However notice that PR_LAST_VERB_EXECUTED was set to a reply value (102) and that the PR_LAST_VERB_EXECUTION_TIME had been updated to reflect when i replied to the message on my surface book.

Now I was doing these against the exported message directly without bringing it back into Outlook. Next week I will attempt to import a message into Outlook from an exported message from another mailbox and see if this behavior changes.

Continue Reading: Daily Blog #392 -  Exploring Extended MAPI Part 6

This is a 19-part series on Exploring Extended MAPI. You can find the rest of the posts here. 

Read More

Daily Blog #389: Sunday Funday 6/10/18 - Extended MAPI Challenge

Hello Reader,
             Another week begins and with it comes a new challenge. You will have a five days to try to complete this challenge now that answers are not due till Friday. Send in your answer as you have it and you are allowed to update your submission if you find new information.

This week we've been talking about Extended MAPI, let's see what you can determine in this week's email related challenge.


The Prize:

$100 Amazon Giftcard

The Rules:

1. You must post your answer before Friday 6/15/18 7PM CST (GMT -5)
2. The most complete answer wins
3. You are allowed to edit your answer after posting
4. If two answers are too similar for one to win, the one with the earlier posting time wins
5. Be specific and be thoughtful 
6. Anonymous entries are allowed, please email them to dcowen@g-cpartners.com. Please state in your email if you would like to be anonymous or not if you win.
7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post

The Challenge:

Extended MAPI records metadata around what actions occur against an email message inside of Exchange and Outlook. What within an email message sent from Outlook and connected to an Exchange server would allow an examiner to determine when an email was sent from the system they are examining presuming they found the message in the sent folder within the mailbox.

Also Read: Daily Blog #388

Read More

Daily Blog #386: Exploring Extended MAPI Part 3

Hello Reader,
            In the prior post with the help of an Outlook plugin we examine the value of a single Extended MAPI property. Now that's great for my testing but what if in your work you need to prove that value exists within the structure and validate the tools output? I thought before we continued on our journey into Outlook/Exchange message interactions we should see how to work with the raw data.

The first thing you should know about the underlying message structure is that it is not just a text file like a RFC82 email message. This would be obvious if you opened up the message in a text editor and saw something like this

The message structure is actually a Compound File Binary Format, meaning a little file system exists within this message and the data we see loaded within the mail client is retrieved from streams of data stored within it. Viewing the same file with a tool that support CFBF like Structure Storage Viewer would show us this

Now we can see the streams of data as its stored. In future posts I am going to go more into the structure of these streams in future posts as it relates to our DFIR work, if you want to jump ahead to that go here https://blogs.msdn.microsoft.com/openspecification/2009/11/06/msg-file-format-part-1/.

The Extended MAPI data we were locating at yesterday is stored within the stream named __properties_version1.0. I saved this stream to my disk with a structured storage viewer and then loaded the stream with 010 hex editor.

What you are seeing in 16 byte entries is all of the named properties we saw within the message and the extended MAPI data. Within this structure is our PR_CREATION_TIME and our PR_LAST_MODIFICATION_TIME values we looked at yesterday. To find them we need to lookup their tag as defined in the MSDN reference. Each extended MAPI property has a fixed tag value that lets use find the value in the structure but while its shown in big endian in the MSDN documentation its stored in little endian within the data structure itself.

So looking at PR_CREATION_TIME (https://docs.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtagcreationtime-canonical-property) we can see that the tag is 0x3007. When you apply the last 4 bytes of the access mask 0040 for the property and the tag you are looking for is 0x30070040 which in little endian is 40007030 and serching for that will find that the third record down is our value.

The timestamp is in the next 8 bytes and is in windows 64 bit little endian filetime format.

Which if we copy out and put into a tool like DCODE. The timestamp we retrieved is not the same as we saw yesterday within the mailbox as I exported the message onto my desktop to get it loaded into structure storage viewer. The action of saving the message to my disk reset the PR_CREATION_TIME to when I saved it to my disk. I need to do more testing on this going forward to see what this really means for us.

We can do the same for the PR_LAST_MODIFICATION_TIME which we can see in the MSDN documentation for PR_LAST_MODIFICATION_TIME is tag 0x3008 which with the access bit is 0x30080040 and in little endian is  0x40008030.

Searching within the stream we can see the 4th entry within the structure is in fact the PR_LAST_MODIFICATION_TIME

and the following 8 bytes is the timestamp stored for PR_LAST_MODIFICATION_TIME

Which when decoded will match the creation as the structure was modified when I exported it to disk.

Now that we can locate these tags within the data itself that means we should be able to write some Python code with libolecf to parse this data out at scale once we've defined the use cases we want to analyze.

Much more to come so please keep reading with me as we journey together into the depths of Outlook/Exchange message interactions.

Continue Reading: Daily Blog #385: Exploring Extended MAPI Part 2

This is a 19-part series on Exploring Extended MAPI. You can find the rest of the posts here. 

Read More

Daily Blog #385: Exploring Extended MAPI Part 2

Hello Reader,
           In the last post in this series we discussed the Extended MAPI data resident within Outlook and Exchange messages. In this post we will look at what within the Extended MAPI data changes when a user marks the message as unread but performs no other action against it.

First I made a new message and I sent it to myself, you can see the message below:

As you can see from the above screenshot I have installed a Outlook extension called OutlookSpy which will expose all the Extended MAPI properties being stored within this message. If Ilook at the Extended MAPI data within the iMessage store for this message I would see the following.

Notice that there is no PR_LAST_VERB_EXECUTED entry within this message, this because none of the tracked actions have occurred. This means that the PR_LAST_VERB_EXECUTED property is not created as part of the base message structure and instead is created when an action occurs. This is good to know because that would mean the presence of the LAST_VERB_EXECUTED regardless of what its storing means that at least one action occurred against this message.

This next part of the testing surprised me. I made the message unread and based on the fact that the PR_LAST_VERB_EXECUTED has an entry for Unread I assumed that this property would be set when I made a message unread. Here is the iMessage Extended MAPI data after making the message unread.

There is still no PR_LAST_VERB_EXECUTED, meaning that making an email unread is not a tracked agent, at least not from the base state of the message. I am going to attempt a couple of different actions against the message to see how this changes.

While it is true that there is no PR_LAST_VERB_EXECUTED property notice that the PR_LAST_MODIFICATION_TIME is set to 8:23PM 6/6/2018. This was interesting to me as you can see in the following screenshot the PR_CREATION_TIME which tracks when this message was stored within this message archive is set to 8:11PM 6/6/2018. All of these times are in UTC.

So based on the first round of testing it would appear as though making an item unread does not set an explicit property, but noticing a difference between the PR_LAST_MODIFICATION_TIME and the PR_CREATION_TIME is a clue that some change occurred to the message. IF that message is also in an unread state, meaning that if it hadn't been changed back to unread by the user and is in fact untouched, that it more than likely was made unread after the fact.

I am going to continue to test the actions that get recorded by Outlook and Exchange in this series. For your reference I am using Outlook 2016 32bit and Windows 10. 

This is a 19-part series on Exploring Extended MAPI. You can find the rest of the posts here. 

Read More

Daily Blog #384: Exploring Extended MAPI Part 1

Hello Reader,
          One thing that I've used for years and we've talked about before on the Forensic Lunch is Extended MAPI. Extended MAPI is a set of properties that are part of the message structure of any Outlook or Exchange stored email. In this first series of posts I thought it would be good to revisit the Extended MAPI data and provide some analysis scenarios and more information as many people still either seem confused by it or unaware of its existence.

To start with let's look at the property PR_LAST_VERB_EXECUTED. This Extended MAPI property records in email messages what the last action that occurred to the message itself. Most of the common entries here are actions like Reply, Reply All, Forward or Reply To Forward. Combined with PR_LAST_VERB_EXECUTION_TIME you can tell not just what last happened to the message but when it happened.

To read more about all of the possible values that can be set for the last verb executed go here :

https://docs.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtaglastverbexecuted-canonical-property

Now when I found that list of properties I wasn't expecting to see all the additional states relating to things other than email messages. It makes sense that other objects within the structure would have Extended MAPI properties but its not something i've tested. So my plan for the next several posts is to run a couple of different tests against different outlook items (email message, calendar item, etc...) and see what actions I can infer from the properties stored within them.

Talk to you tomorrow!

This is a 19-part series on Exploring Extended MAPI. You can find the rest of the posts here. 

Read More

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!

Also Read: 

Daily Blog #164 - Solving Sunday Funday Part 2 

Daily Blog #163 - Solving Sunday Funday Part 1

Read More

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.

Also Read: 

Daily Blog #164 - Solving Sunday Funday Part 3

Daily Blog #163 - Solving Sunday Funday Part 1

Read More

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.

Also Read: 

Daily Blog #164 - Solving Sunday Funday Part 3

Daily Blog #163 - Solving Sunday Funday Part 2

Read More