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

By Joachim Metz
Hoffmann Investigations
www.hoffmannbv.nl

Version: 1.0 Joachim Metz August 17, 2009 Initial version.

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 finding 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.

Table of Contents

1. Introduction
1.1. Background
2. Falsified e-mail message
2.1. The e-mail body
2.2. Conversation index
3. The modified appointment
4. Conclusion
Appendix A. References
Appendix B. GNU Free Documentation License

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<BR>
\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.