Introduction
Last week, I came across an interesting post on Forensic Focus. The poster, jahearne, was asking about how one can detect manipulation of an existing email in Gmail. In his hypothetical scenario, the bad actor was using Outlook to edit the message and change its contents after it was received. I wanted to reproduce this setup and examine the results to see what we find out.
The Setup
I started by performing a baseline acquisition of the target email account over IMAP—which is the same protocol Outlook would use to connect to Gmail. This allowed me to capture the Internal Date Message Attribute as well as the Unique Identifier (UID) Message Attribute for each message before any manipulation took place. I used our Forensic Email Collector to do this, but you can also capture these values by directly interfacing with Gmail’s IMAP server.
I then connected the Gmail account to Outlook 2016. Once Outlook finished downloading the messages, I picked the message that I wanted to manipulate. The original message looked as follows:
Original Gmail Message
I then clicked the “Edit Message” menu item from the “Move” section in the toolbar ribbon for the email.
Editing Gmail Message in Outlook
I changed the subject of the message from “Play games while you drive ????” to “Play games while you ride your horse” and changed the string “I used to drive 4 hours a day to get to SF” to “I used to drive 4 hours a day to get to San Diego” in the message body.
I clicked the “Save” button on the top left corner. Outlook indicated that it was synchronizing the folder, and voilà! The manipulated message was pushed to the server.
I double checked this by logging into Gmail’s web interface and pulling up the manipulated message. It looked as follows:
Manipulated Email in Gmail
Now that our manipulated message had made its way back to Gmail, it was a good time to acquire the mailbox one more time for comparative analysis.
Forensic Examination of Manipulated Email
Server Metadata
The first question in my mind was how this affected server-side metadata—the Internal Date and Unique Identifier message attributes. Before manipulation, our message (highlighted) and its four immediate neighbors had looked as follows:
| UID | Internal Date (UTC) | Header Date (UTC) | Hash (SHA-256) |
|---|---|---|---|
| 213 | 11/5/2018 12:58:15 | 11/5/2018 12:40:13 | C0705F365281A1584A9A0C6EEBCE07C1DE677554BE638F72618378A03982892C |
| 214 | 11/5/2018 16:09:38 | 11/5/2018 16:09:36 | 1B12A488E5FBC914AA056C27E16102FD7882390840452BB76E6C374D8381CF6A |
| 215 | 11/5/2018 17:43:29 | 11/5/2018 17:43:28 | 82655FF5D3B502F15D28F2B95640369D3D20BEE20B716DF42FD099352690150C |
| 216 | 11/6/2018 13:07:58 | 11/6/2018 12:43:10 | 2086199596425C735BCF7AA9E283B1D45CEDC8891B1CE940B7E707843238E3F6 |
| 217 | 11/6/2018 16:12:12 | 11/6/2018 16:12:11 | 88B736304F6E048E3993BDD10C3563DB25AB64E7EB5313FA006A90F25DE921D0 |
Note that the UIDs were in ascending order while the messages were sorted chronologically by Internal Date.
Now, let’s take a look at the same set of messages after the manipulation:
| UID | Internal Date (UTC) | Header Date (UTC) | Hash (SHA-256) |
|---|---|---|---|
| 213 | 11/5/2018 12:58:15 | 11/5/2018 12:40:13 | C0705F365281A1584A9A0C6EEBCE07C1DE677554BE638F72618378A03982892C |
| 214 | 11/5/2018 16:09:38 | 11/5/2018 16:09:36 | 1B12A488E5FBC914AA056C27E16102FD7882390840452BB76E6C374D8381CF6A |
| 348 | 11/5/2018 17:43:29 | 11/5/2018 17:43:28 | BC2DC5763568CEF6F734315D40D3295F3E0069C19D9BAF9B28F974C8ED0DD178 |
| 216 | 11/6/2018 13:07:58 | 11/6/2018 12:43:10 | 2086199596425C735BCF7AA9E283B1D45CEDC8891B1CE940B7E707843238E3F6 |
| 217 | 11/6/2018 16:12:12 | 11/6/2018 16:12:11 | 88B736304F6E048E3993BDD10C3563DB25AB64E7EB5313FA006A90F25DE921D0 |
As expected, the manipulation changed the cryptographic hash of the email message. But more importantly, it caused Gmail’s IMAP server to assign the message a new UID. Now, when we look at the messages in chronological order, the UID of the manipulated email is no longer in order. In fact, it received the greatest UID in the folder. Let’s take a look at the mechanism that caused this.
How Did Outlook Replace The Message on The Server?
In the background, Outlook issued an APPEND IMAP command to Gmail’s IMAP server and introduced the altered email into the mailbox as a new message. As an argument to the APPEND command, Outlook passed the Internal Date of the original message. The IMAP specification for the APPEND command states that:
If a date-time is specified, the internal date SHOULD be set in
the resulting message; otherwise, the internal date of the
resulting message is set to the current date and time by default.
In this case, because a date-time was specified, the Internal Date message attribute was preserved. Depending on the IMAP server and the email client that was used, you may find that the Internal Date message attribute sometimes reflects the time when the altered message was synced back to the mailbox.
After the APPEND command, Outlook set the “\Deleted” IMAP flag on the original message. Finally, Outlook issued a UID EXPUNGE command to permanently remove the original message from the mailbox.
Message Data and Metadata
Unlike scenarios where the suspect edits an existing message with a text editor and uploads it to the IMAP server, here I used Outlook to alter the message. Let’s take a look at how the manipulated email message in Gmail looks different than the original.
Message Size and Body
Editing the message using Outlook and saving it caused it to almost double in size. The total size of the message increased from 66.9 KB to 121 KB. This was mostly because of the formatting information Outlook inserted into the document.
The “ProgId”, “Generator”, and “Originator” meta tags were populated with the values “Word.Document”, “Microsoft Word 15”, and again “Microsoft Word 15” respectively—not unlike a Word document saved in HTML format.
Upon looking at the part where I had edited the message body, I found that Outlook managed to update both the HTML and the plain text versions of the message body consistently.
MIME Boundary Delimiters
The MIME boundary delimiter of the original message was “=-FqYpb1xnVuagRE/vpmLO”. After the edits, it was changed to “—-=_NextPart_000_0000_01D4B364.5C460060“.
Note that the last part of the new MIME boundary delimiter, 01D4B364.5C460060 (6000465C64B3D401 in reverse byte order), is a FILETIME value. Decoding the FILETIME value results in 01/23/2019 21:41:12.6780000. This is not the time when the original message was edited and saved in Outlook, but the time when the edited message was synced back to Gmail by Outlook. The timestamp has millisecond precision, and no time zone offset (thanks, Charles Platt, for spotting this!).
Header Fields
When the message was edited using Outlook, the header information shrank from 4,950 bytes to 2,184 bytes. This was mostly because Outlook stripped out several lengthy header fields such as “DKIM-Signature” and “Authentication-Results”.
The Message-Id header field was preserved.
One significant change was to the Origination Date (i.e., “Date” field in the header). The “Date” field of the original message read:
Date: Mon, 5 Nov 2018 17:43:28 +0000
After the edits in Outlook, the “Date” field of the modified email became:
Date: Mon, 5 Nov 2018 09:43:28 -0800
While both timestamps refer to the same point in time, the manipulation in Outlook caused the “Date” field to reflect the time zone where the edits were made!
The “Subject” header field also changed as expected. It was originally UTF-8 encoded to accommodate the “oncoming automobile” emoji (\xF0\x9F\x9A\x98):
Subject: =?UTF-8?Q?Play_games_while_you_drive_=F0=9F=9A=98?=
After my edits, the new Subject header field became:
Subject: Play games while you ride your horse
Outlook also added a few new header fields such as:
X-Mailer: Microsoft Outlook 16.0
X-OlkEid: 00000000E99D742F177E4948AB97502B6BAC12160700C3B68E10F77511CEB4CD00AA00BBB6E600000000000C0000D9539C2261A6BB45B9DAB62C7081B3C10100E800000000006A8B4A45F8869849BA81A810114C7889
Thread-Index: AQGfn39hkC1I90ybIjXNvTnfAiwDDg==
Note that Outlook 16.0 matches the version of Outlook (2016) I used to edit the message.
Conclusions
This exercise shows just how easy Outlook makes it for an end user to edit an email message that’s on the server.
In this case, examining the server metadata along with the message itself made it clear that the message was manipulated. The manipulated email had, among other things:
- An out-of-order UID
- Artifacts in the message header and body that were inconsistent with other messages from the same sender
- A time zone offset in its Origination Date that was inconsistent with those of other messages from the same sender, and that matched the time zone where the message was manipulated
- Its X-Mailer header field populated with the name and version of the email client that was used to alter the message
- A new MIME boundary delimiter which contains a timestamp reflecting the time the altered message was reintroduced to Gmail
When forensically authenticating emails, it is important that forensic examiners capture not only the message of interest but also its neighbors and server metadata. Examining the suspect message in isolation prevents the examiner from analyzing valuable contextual evidence that lives on the server.
References:
RFC 5322: Internet Message Format — https://tools.ietf.org/html/rfc5322
RFC-3501: Internet Message Access Protocol — https://tools.ietf.org/html/rfc3501
RFC-2045: Multipurpose Internet Mail Extensions (MIME) — https://tools.ietf.org/html/rfc2045
Forensic Focus Post — https://www.forensicfocus.com/Forums/viewtopic/t=17409/