SANS Digital Forensics and Incident Response Blog

Analysis of e-mail and appointment falsification on Microsoft Outlook/Exchange

Author: Joachim Metz <forensics@hoffmannbv.nl>

Summary

In digital forensic analysis it is sometimes required to be able to determine if an e-mail has or has
not been falsified. In this paper a review of certain Outlook Message Application Programming
Interface (MAPI)
is provided which can help in determining falsified e-mails or altered
appointments in an Microsoft Outlook/Exchange environment.

About the libpff project

In 2008 Joachim Metz a forensic investigator at Hoffmann Investigations started the libpff project.
At that time the best source about the Personal Folder File (PFF) format in the public domain was
the libpst project. The libpst project dated back to 2002 and had been contributed and maintained
by David Smith, Joe Nahmias, Brad Hards and Carl Byington.

However the libpst, at that time, wasn't a library and had no support for recovering deleted items
in PST and OST files. The initial goal of the libpff project to create a shared library for PST and
OST that had support for recovering deleted items. Recovering deleted items requires detailed
knowledge of the inner structures of the PFF format. This was the beginning of an interesting
journey. In which even recently additional information about the inner structures has been
discovered, like the 6c and 8c table and the use of indirection in large tables.

In March 2009 PFF forensics was first discussed as part of Microsoft Office forensics in the
Hoffmann Advanced Forensic Sessions (HAFS). A paper titled 'Personal Folder File (PFF)
forensics'
was published as part of the HAFS. This paper explains the basics of the PFF format,
which can be quite a challenge to understand. One of the main conclusions of the both the paper
and the seminar was that different forensic tools provide different results when recovering deleted
items in PST and OST files.

In the mean time the libpff project has evolved. Due to continued analysis of the PFF format and
several contributions new aspects of the file format have been discovered. Some of which are the
PFF items that contain information about the recipients, sub folders, sub messages and sub
associated items.

Also a lot of information available about the MAPI has made available. The OpenChange project
provides libmapi which contains an Open Source implementation of the MAPI. And the
MFCMAPI project has provided a lot of MAPI information now available on MSDN.

Within Hoffmann Investigations libpff has been to put to work for two purposes. First as a tool to
cross reference findings in other forensic tools and secondarily as a tool that can provide more
information about PST and OST files than those forensic tools. In the upcoming Hoffmann
Advanced Forensic Sessions in November 2009
PFF forensics will be therefore once more the
subject of discussion. In the mean time several of the interesting findings are provided in this
paper.

1. Introduction

Wouldn't it be nice to have your forensic analysis software to filter out falsified e-mails and
appointments for you? However, most of the current forensic tools provide little information about
the authenticity of e-mail messages and appointments. Therefore, certain analysis have to be done
manually. This paper will give you an understanding of parts the Outlook Message Application
Programming Interface (MAPI) to help identify falsified e-mails in Microsoft Outlook/Exchange
environments.

1.1. Background

If you are a forensic investigator in the field of corporate environments you are probably dealing
with Microsoft Outlook and Exchange most of the time. What you might not know is that both
make heavy use of the MAPI. The MAPI is not only a programming interface but also a useful
resource of information regarding properties of e-mail attributes. For those of you not familiar
with analyzing the Personal Folder File format used by Microsoft Outlook for PST and OST files,
I advice reading [METZ09] before reading this paper.

2. Falsified e-mail message

In a recent investigation we had to investigate if a user had sent an e-mail at a certain date and
time. We started by determining the existence of the e-mail in the mailbox of both the sender and
the recipients. But there were other characteristics that were highly interesting from a forensic
point of view.

A certain e-mail dated March 10, 2009 was forwarded on March 17, 2009. The original e-mail
could not be found in any of the mailboxes. The first indication of falsification was a discoloring
of the day of the month in a print-out of the forwarded e-mail. The 0 in March 10, was gray while
the surrounding text was clearly black.

2.1. The e-mail body

In Outlook/Exchange an e-mail message can contain RTF and/or HTML body text. Both RTF and
HTML formats use formatting codes. Using these formatting codes we did a low-level analysis of
the body text. Most of the available forensic tools do not provide access to these formatting codes,
but lucky for us there is libpff and its tools.
After having compiled libpff with verbose and debug output and having pffexport export the PST

file with the verbose option (-v), we had created a detailed debug log file. In this log file we looked up the e-mail and its RTF body. In the RTF body the following information was found:

{\*\htmltag84 <b>}\htmlrtf {\b \htmlrtf0 Sent:
{\*\htmltag92 </b>}\htmlrtf }\htmlrtf0 Tuesday March 1
{\*\htmltag84 <span style='color:#1F497D'>}\htmlrtf {\htmlrtf0 0
{\*\htmltag92 </span>}\htmlrtf }\htmlrtf0 , 2009 13:48
{\*\htmltag116 <br>}\htmlrtf \line
\htmlrtf0
{\*\htmltag4 \par }

Using other forwarded e-mails as a reference, we established that the bold formatting code should not be there.

2.2. Conversation index

Looking at existing e-mail messages we hypothesized that the original e-mail was not created on
March 10, 2009 but was in fact an e-mail created on March 17 2009 that had been altered. We
wanted proof besides the lack of the original e-mail message in the mailboxes of the sender and
the recipients.

A MSDN article titled 'Tracking conversations' provided us with a fairly reliable answer.
[MSDN] states that:

PR_CONVERSATION_INDEX (PidTagConversationIndex) indicates the position of the
message within a particular conversation. It is a client's reponsibility to
set PR_CONVERSATION_INDEX for each outgoing message, whether it is a new
message, a forwarded message, or a reply. Clients can set this property
manually or call ScCreateConversationIndex, a utility function provided by
MAPI.
ScCreateConversationIndex generates the value of a conversation index for any
outgoing message. ScCreateConversationIndex implements the index as a header
block that is 22 bytes in length, followed by zero or more child blocks each 5
bytes in length.
The header block is composed of 22 bytes, divided into three parts:
* One reserved byte. Its value is 1.
* Five bytes for the current system time converted to the FILETIME structure
format.
* Sixteen bytes holding a GUID, or globally unique identifier.
Each child block is composed of 5 bytes, divided as follows:
* One bit containing a code representing the difference between the current
time and the time stored in the header block. This bit will be 0 if the
difference is less than .02 second and greater than two years and 1 if the
difference is less than one second and greater than 56 years.
* Thirty one bits containing the difference between the current time and the
time in the header block expressed in FILETIME units.This part of the child
block is produced using one of two strategies, depending on the value of
the first bit. If this bit is zero, ScCreateConversationIndex discards the
high 15 bits and the low 18 bits. If this bit is one, the function discards
the high 10 bits and the low 23 bits.
* Four bits containing a random number generated by calling the Win32
function GetTickCount.
* Four bits containing a sequence count that is taken from part of the random
number.

Reverse-engineering this description for the PFF format I found that the part of the header block

containing the 'One reserved byte' with a value of 1 is actually the first byte of the filetime. So

there are not 5 bytes of the filetime but 6. The date and time in the header block of the

conversation index matches the creation date and time of e-mail messages.

The child block contains a difference between the current and the previous time and not the time

stored in the header block, as according to the MSDN specification. This was validated using the

creation date and time of multiple e-mails.

The conversation index for the specific e-mail translates to:

0x0071 (PidTagConversationIndex : Conversation index)
0x0102 (PT_BINARY : Binary data)
Header block:
Filetime : Mar 17, 2009 10:13:04 UTC
GUID : 11111111-2222-3333-4444-555555555555
Child block: 1
Filetime : Mar 17, 2009 10:18:03 UTC
Random number : 2
Sequence count : 0
Child block: 2
Filetime : Mar 17, 2009 10:24:01 UTC
Random number : 9
Sequence count : 0
Child block: 3
Filetime : Mar 17, 2009 10:42:39 UTC
Random number : 9
Sequence count : 0
Child block: 4
Filetime : Mar 17, 2009 10:45:36 UTC
Random number : 14
Sequence count : 0
Child block: 5
Filetime : Apr 17, 2009 07:19:08 UTC
Random number : 8
Sequence count : 0

Note that the precision of the date and time difference in the child block varies and does not match

the creation date and time. The actual reason for this variation is yet unknown.

0x3007 (PidTagCreationTime : Creation time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Apr 17, 2009 08:41:20 UTC

However there is no date March 10, 2009 in the conversation index. Looking at the conversation

indexes of other forwarded and replied e-mail messages this is the behavior we would expect.

Note that the GUID '11111111-2222-3333-4444-555555555555' in this example was altered.

Using the GUID we found corresponding e-mails, with the same GUID in the conversation index.

Most of these e-mails had a different content. This finding supported our hypothesis. All of the

corresponding e-mails also had a creation date of March 17, 2009. Therefore, it was plausible that

the e-mail with the discolored zero in 'March 10' was falsified using another e-mail created on

March 17, 2009. Upon being faced with the findings in an interview, the sender of the e-mail admitted that he had

altered the e-mail.

3. The modified appointment

In another investigation we found an appointment that contained a conversation topic that
contained one of the keywords we were looking for. However the appointment had an entirely
different subject and the last modification date and time already indicated that the appointment
was modified at a later date.

We needed to be certain that this behavior was caused by modifying an appointment. Using
Outlook we created a PST file with an appointment. Libpff provided us with the following
information about the subject and the conversation topic:

0x0037 (PidTagSubject : Subject)
0x001f (PT_UNICODE : UTF-16 Unicode string)
Unicode string : ^A^ATest1
0x0070 (PidTagConversationTopic : Conversation topic)
0x001f (PT_UNICODE : UTF-16 Unicode string)
Unicode string : Test1

And about the date and time values:

0x0039 (PidTagClientSubmitTime : Client submit time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Jul 23, 2009 14:07:47 UTC
0x0071 (PidTagConversationIndex : Conversation index)
0x0102 (PT_BINARY : Binary data)
Header block:
Filetime : Jul 23, 2009 14:07:47 UTC
GUID : 11111111-2222-3333-4444-555555555555
0x0e06 (PidTagOriginalDeliveryTime : Message delivery time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Jul 23, 2009 14:07:47 UTC
0x3007 (PidTagCreationTime : Creation time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Jul 23, 2009 14:04:28 UTC
0x3008 (PidTagLastModificationTime : Last modification time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Jul 23, 2009 14:07:50 UTC

The ^A characters in the subject are control characters and can be ignored.

Note that the creation and last modification date and time are not equal.

Next we modified the appointment and had libpff provide us with information about the subject

and the conversation topic:

0x0037 (PidTagSubject : Subject)
0x001f (PT_UNICODE : UTF-16 Unicode string)
Unicode string : ^A^AModified1
0x0070 (PidTagConversationTopic : Conversation topic)
0x001f (PT_UNICODE : UTF-16 Unicode string)
Unicode string : Test1

And about the date and time values:

0x0039 (PidTagClientSubmitTime : Client submit time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Jul 23, 2009 14:07:47 UTC
0x0071 (PidTagConversationIndex : Conversation index)
0x0102 (PT_BINARY : Binary data)
Header block:
Filetime : Jul 23, 2009 14:07:47 UTC
GUID : 11111111-2222-3333-4444-555555555555
0x0e06 (PidTagOriginalDeliveryTime : Message delivery time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Jul 23, 2009 14:07:47 UTC
0x3007 (PidTagCreationTime : Creation time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Jul 23, 2009 14:04:28 UTC
0x3008 (PidTagLastModificationTime : Last modification time)
0x0040 (PT_SYSTEM : Windows Filetime (64-bit))
Filetime : Jul 23, 2009 14:08:37 UTC

As you can see the conversation topic and index do not change when an appointment is modified.

The last modification date and time in the example is not much of an indication that the

appointment was modified, mainly because we did the modification right after the creation of the

appointment.

4. Conclusion

E-mails and appointments in Outlook/Exchange provide us with certain properties that can be
useful for digital forensic analysis of e-mails, like the conversation index and multiple formatted
body texts. Others may be the conversation topic and original creation and/or modification dates
and times.

Appendix A. References

[METZ09]
Title: Personal Folder File (PFF) forensics
Subtitile: Analyzing the horrible reference file format
Author(s): Joachim Metz
URL: http://kent.dl.sourceforge.net/sourceforge/libpff/PFF_forensics.pdf
[MSDN]
Title: Tracking conversations
URL: http://msdn.microsoft.com/en-us/library/cc765583.aspx

5 Comments

Posted August 26, 2009 at 10:09 PM | Permalink | Reply

Stephen Griffin

Excellent article. Glad to see MFCMAPI (http://mfcmapi.codeplex.com) was of use for forensics. BTW ''" MFCMAPI can natively parse the conversation index for you. You can even use the built in Hex Editor to invoke the parsing if the data was drawn from another source such as an export of the mailbox/pst.
Also ''" you should look at the Exchange protocol documentation. They document many more structures you may find useful in future investigations: http://msdn.microsoft.com/en-us/library/cc307725.aspx

Posted February 18, 2010 at 5:50 PM | Permalink | Reply

John Schmidt

HI
I have a question and hope you can help with this. I am currently in a dispute with another person. Central to my claim is an email he sent me confirming certain items. He now claims he never wrote that email.
The address he sent me that email on is controlled by him and he has since disabled my access and denied all access to my account (Outlook which I accessed using IMAP). Fortunately, all emails coming into that address was forwarded to my GMAIL account.
I am afraid that he will have deleted the originals (or even tempered with them) and that even though I have a valid claim, the non-existence of the emails on his client may lead my copy to be proved as false.
Any thoughst or suggestions?
Kind regards
John

Posted March 10, 2010 at 3:45 PM | Permalink | Reply

anonymous

John,
Your best bet is to show the copy you have in your gmail account, and subpoena the email backups on his server. Law differs in every country, but he might need to keep a copy of the backup for years.

Posted August 18, 2010 at 10:05 AM | Permalink | Reply

Arjaen

Hi John,
To avoid certain disputes in the future, you could use the registration service of copyconfirm.com
This company makes a digital fingerprint of your mail but does not store it. This creates a wittness in case you need one, but the contents of your mail are owned by yourself only.
It's free for private users, and extremely simple to use.
Good luck

Posted April 2, 2012 at 5:19 PM | Permalink | Reply

Grant

For outlook client users, it is also helpful to look at the Outlook Internal Version field. If it is blank, then most likely the user has not opened the email in outlook and edited it. This field shows the version of outlook client used to create or edit the message, but it is not transmitted to the recipient. As an example, you will see it populated in the sent mailbox, but it is not populated in the inbox.