Emails are usually at the top of the list when it comes to potentially relevant electronically stored information (ESI) sources. They often capture critical business correspondence, agreements, business documents, internal company discussions etc. They are also one of the most frequently forged document types. They can be altered in many ways such as by backdating, changing the sender, recipients or message contents. Fortunately, email servers and client computers often contain various metadata which can be used for forensic email forgery analysis.
One of these metadata fields is the Conversation Index property. I previously wrote about E-mail Conversation Index Analysis and how it can be useful in forensic analysis of e-mails, particularly email forgery analysis. In this post, we will put that weapon to use — along with other computer forensics techniques — and take a close look at a sample fraudulent email message.
Example Email Forgery Analysis Scenario
Please note that all timestamps in this forensic email forgery analysis scenario are in PDT unless otherwise noted.
Preparation
I created a sample fraudulent email message (“Test Message”) for email forgery analysis as follows:
- I configured Outlook 2010 with a Gmail account using the Internet Message Access Protocol (IMAP) on a test workstation.
- On 9/22/2014 at approximately 1:00 PM, I rolled back the date/time of the test workstation to reflect a false date of approximately 9/15/2014 11:30 AM.
- I replied to an existing message with a sent date of 9/18/2014 at 2:32 PM (“Parent Message”), removed the “Re:” prefix from the new email’s subject and deleted the inline quoted original message.
- I then typed the string “Message body.” as the body of the new email and sent my response to an Exchange email address on 9/22/2014 at 1:06 PM (9/15/2014 at 11:36 AM (false) local time on the test workstation).
Analysis
Looking at the message found in the recipient’s inbox for email forgery analysis revealed the following:
- The PR_CLIENT_SUBMIT_TIME property of the Test Message is 9/15/2014 11:36:38 AM. This is consistent with the local time on the test workstation.
- The PR_INTERNET_MESSAGE_ID_W property of the Test Message is “<001e01cfd113$fcf210e0$f6d632a0$@gmail.com>”. The “@gmail.com” suffix is consistent with messages sent via Gmail using IMAP.
- The PR_MESSAGE_DELIVERY_TIME property of the Test Message is 9/22/2014 1:06:08 PM. This discrepancy indicates that there might be something wrong with the sent date of the message. It is unusual for the PR_CLIENT_SUBMIT_TIME and PR_MESSAGE_DELIVERY_TIME values to be so far apart. I will try to find some additional evidence to shed light on this discrepancy.
- The PR_CONVERSATION_INDEX value of the Test Message is “01 CF D3 87 EF 66 67 E6 07 B9 0A 96 4B A7 A7 F1 A4 7D 4C BE 9F 70 00 9D 00 79 40”. The 27-byte value suggests that the Conversation Index contains one child message.
- Parsing the conversation index for email forgery analysis using Conversation Index Parser reveals a header date of 9/18/2014 2:31:40 PM (PDT). This is consistent with the Sent Date of the Parent Message to which I had replied when composing the Test Message.
- The Conversation Index also includes a child block, with a time difference value of ‘3.02:55:27.1181312’ (approximately 3 days, 2 hours, 55 minutes and 27 seconds). As I mentioned previously, the time difference values found in Conversation Index child blocks are unsigned. In this case, applying the time difference as a negative value produces a child timestamp of 9/15/2014 11:36:13 AM (PDT) (see Figure 1 below). This value is consistent with the false local time on the test workstation when the Test Message was created. Note that the 25 second difference with the PR_CLIENT_SUBMIT_TIME was likely caused by the time elapsed between when I created the reply (i.e. hit the “Reply” button in Outlook) and when I sent the response (i.e. hit the “Send” button in Outlook).
Figure 1 – Parsed Conversation Index for Email Forgery Analysis
The Conversation Index header and child dates support my suspicion about the sent date as we would normally not expect to see a header date much later than the sent date of the child message.
Additionally, the fact that the Conversation Index contains a reference to the Parent Message is conflicting with the appearance of the Test Message. The Test Message’s email subject and body suggest that it was a new message, not a response to an existing message (see Figure 2 below).
Figure 2 – Email Forgery Analysis Example Message
- The transport header (PR_TRANSPORT_MESSAGE_HEADERS_W) of the received message looks as follows:
Note: This is only an excerpt from the full header. IDs, computer names and IP addresses were redacted. Line numbers were added for reference.
01 Received: from redacted (xxx.xxx.xxx.xxx) by 02 redacted (xxx.xxx.xxx.xxx) with redacted SMTP 03 Server (TLS) id xx.x.xxxx.xx via Mailbox Transport; Mon, 22 Sep 2014 20:06:08 04 +0000 05 Received: from redacted (xxx.xxx.xxx.xxx) by 06 redacted (xxx.xxx.xxx.xxx) with redacted SMTP 07 Server (TLS) id xx.x.xxxx.xx; Mon, 22 Sep 2014 20:06:06 +0000 08 Received: from redacted (xxxx:xxx:xxxx:xxxx::xxx) by 09 redacted (xxxx:xxx:xxxx:xxxx::xx) with redacted 10 SMTP Server (TLS) id xx.x.xxxx.xx via Frontend Transport; Mon, 22 Sep 2014 11 20:06:05 +0000 12 Received: from mail-pa0-f66.google.com (xxx.xx.xxx.xx) by 13 redacted (xxx.xxx.xxx.xxx) with redacted SMTP 14 Server (TLS) id xx.x.xxxx.xx via Frontend Transport; Mon, 22 Sep 2014 15 20:06:04 +0000 16 Received: by mail-pa0-f66.google.com with SMTP id redacted 17 for <person1@example.com>; Mon, 22 Sep 2014 13:06:03 -0700 (PDT) 18 X-Received: by xxx.xxx.xxx.xxx with SMTP id redacted 19 Mon, 22 Sep 2014 13:06:03 -0700 (PDT) 20 Return-Path: <person2@gmail.com> 21 Received: from COMPUTER1 ([xxx.xxx.xxx.xxx]) 22 by mx.google.com with ESMTPSA id redacted 23 for <person1@example.com> 24 (version=TLSv1 cipher=RC4-SHA bits=128/128); 25 Mon, 22 Sep 2014 13:06:02 -0700 (PDT) 26 From: "Person2" <person2@gmail.com> 27 To: "Person1" <person1@example.com> 28 Subject: Sample Subject 29 Date: Mon, 15 Sep 2014 11:36:38 -0700 30 Message-ID: <001e01cfd113$fcf210e0$f6d632a0$@gmail.com> 31 MIME-Version: 1.0 32 Content-Type: multipart/alternative; 33 boundary="----=_NextPart_000_001F_01CFD0D9.50F507F0" 34 X-Mailer: Microsoft Outlook 14.0 35 Thread-Index: Ac/Th+9mZ+YHuQqWS6en8aR9TL6fcACdAHlAOn line 35, we see the Thread-Index value “Ac/Th+9mZ+YHuQqWS6en8aR9TL6fcACdAHlA”. As expected, this is the Base64 encoded version of our Conversation Index.
Line 34 indicates that the message was mailed using Microsoft Outlook 14.0, which is Outlook 2010 (see Microsoft Outlook Versions).
Line 29 contains the false sent date value, same as what we found in the PR_CLIENT_SUBMIT_TIME property.
Line 25 indicates that the message was received by Google’s mail server on 9/22/2014 at 1:06:02 PM (PDT). This is 6 seconds before the message was delivered according to the PR_MESSAGE_DELIVERY_TIME property.
Between lines 19 to 1, the message goes through multiple hops, finally being delivered on 9/22/2014 at 1:06:08 PM (PDT) (Line 3). This value is the same as the PR_MESSAGE_DELIVERY_TIME property.
The appearance of the “Frontend Transport” and “Mailbox Transport” strings in the transport header is consistent with how mail flow occurs in the Exchange Transport Pipeline.
Other Observations
I have made the following observations while reviewing the metadata of numerous e-mails during email forgery analysis:
- When the message is sent through an Exchange Server rather than Gmail, the incorrect PR_CLIENT_SUBMIT_TIME value is corrected.
- When replying to the Parent Message, Outlook retained the original Conversation Index value — and appended a child block to it — if the e-mail subject (at least the base subject excluding the Re: or Fw: prefix) was kept intact. If the subject was changed, Outlook created a new Conversation Index value.
Conclusion
As the use of electronic documents as evidence in legal proceedings is becoming more and more popular, so is email forgery, electronic document date forgery and other electronic fraud. However, electronic documents usually contain numerous metadata fields, rendering most forgery attempts discoverable. Email transport headers and other metadata such as the Conversation Index, Sent Time and Delivery Time Microsoft Outlook Messaging API (MAPI) Properties are just a few of the numerous metadata fields computer forensics experts can use during email forgery analysis.
