Using Extended MAPI Properties to determine email sent time
Recently, David Cowen at 'Hacking Exposed - Computer Forensics Blog' has resumed the 'Zeltser Challenge' of daily blogging. In doing so, he has highlighted (at least to me) that after a short initial flourish this blog has been somewhat neglected, taking a back seat while regular work and other commitments have ramped up again.
Inspired by David's effort and with an eye on his 'Sunday Funday' challenge series I thought I would respond to the most recent challenge via blogpost. The challenge in question is detailed at this post and in essence asks the question:
'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.'
In my day-to-day work I have limited need to analyse emails for the senders machine so this posed an interesting opportunity to look into Extended MAPI Properties for the first time in a long time.
The Setup
When performing this type of research I would normally aim to set up a number of test environments combining a mix of OS, client and configuration versions however for the purposes of this exercise I have limited my research to a single setup, as follows:
Windows 10 (10.0.17134.48)
Outlook 2016 (16.0.9330.2073)
Office365 Account
The test setup comprised:
- Microsoft Windows 10 (10.0.17134.48)
- Outlook 2016 (16.0.9330.2073)
- An Office365 email account configured as an exchange mailbox using default settings within Outlook.
Examining MAPI Properties
There are a number of ways to view MAPI properties within various forensic suites and using plugins for Outlook. For the purposes of this analysis I used Kernel OST Viewer and will look to verify findings using a secondary tool, however have not done so at this stage.
Viewing MAPI Properties in Kernel OST Viewer could not be simpler. After launching the application, press 'Select File'.
This will present you with the 'Source File Selection' dialog box.
Browse to the location of your OST for analysis, within this configuration the OST is located in the default location of 'C:\Users[UserName]\AppData\Local\Microsoft\Outlook'. Once selected, you will be presented with a further box, select 'Finish' and the OST will be parsed.
Select any message within the messages table and then select the 'Advanced Properties View' tab in the Viewing Pane. In the image below we have navigated to the Sent Items folder as this will be of note during testing.
Now that we have a way to examine the MAPI Properties we can commence testing.
Date Fields in MAPI Properties
The first thing I examined was sending a test message and examining what MAPI Properties were associated with it and particularly those which contained date values. Immediately notable are 5 values which contain Windows Filetime data. In all test messages the following Properties were populated:
As detailed in the image the identified Property name and Property Tag associated with these properties was:
PR_CREATION_TIME | 0x30070040
PR_CLIENT_SUBMIT_TIME | 0x00390040
PidLidValidFlagStringProof | 0x85BF0040
0x00000F0A | 0x0F0A0040
0x00000F02 | 0x0F020040
In addition to these properties, certain other properties also contained dates within strings such as Property 0x0000844D and various others.
While these other properties are of various forensic value and indeed may assist in corroborating dates and times observed elsewhere, they have been excluded from this testing for the moment.
Testing
In testing I chose to test three scenarios to examine the impact on the MAPI Properties on the items as they existed within sent items.
Scenario 1: A user presses compose, generates their message and sends it.
Scenario 2: A user presses compose, generates a message, closes it (saving a draft), reopens the message making modifications and then sends the message.
Scenario 3: A user presses compose, generates their message and sends it while the computer is disconnected from the network, causing the message to be held in the users outbox, the message is then later transmitted when the network reconnects.
Each test was repeated three times with no observed differences between the examined MAPI Property behavior within each repetition of a scenario. One example for each is detailed below in the Results section.
Results
--Test 1--
Tested Scenario:
Message composed and sent
Actions Performed:
20180611T22:30:22 – Pressed 'Compose' within Outlook and typed email message
20180611T22:31:03 – Pressed 'Send'.
MAPI Property values:
0x00000F0A = 20180611T22:31:03
0x00000F02 = 20180611T22:31:03
PR_CREATION_TIME = 20180611T22:31:03
PR_CLIENT_SUBMIT_TIME = 20180611T22:31:03
PidLidValidFlagStringProof = 20180611T22:31:03
Notably the property values all show a consistent date/time, the PR_CREATION_TIME and PR_CLIENT_SUBMIT_TIME show the same timestamp.
--Test 2--
Tested Scenario:
Message Composed, Saved as Draft, Opened and Sent
Actions Performed:
20180611T22:40:50 – Pressed 'Compose' within Outlook and typed email message
20180611T22:41:25 – Closed email message
20180611T22:41:30 – Select 'Save; when prompted to save as draft
20180611T22:42:16 – Opened Draft and updated
20180611T22:43:09 – Pressed 'Send'.
MAPI Property values:
0x00000F0A = 20180611T22:43:09
0x00000F02 = 20180611T22:43:10
PR_CREATION_TIME = 20180611T22:43:09
PR_CLIENT_SUBMIT_TIME = 20180611T22:43:09
PidLidValidFlagStringProof = 20180611T22:43:10
Once again, despite the saving of a draft all timestamps associated with the examined MAPI Properties are within 1 second of the 'Send' button being pressed.
--Test 3--
Tested Scenario:
Message Composed, Sent while system is offline and held in Outbox, Transmitted when system reconnected to network.
Actions Performed:
20180611T22:48:02 – Pressed 'Compose' within Outlook and typed email message
20180611T22:49:50 – Pressed 'Send'
20180611T22:50:30 – Reconnect Network
20180611T22:51:02 – Pressed 'Send/Receive'
MAPI Property values:
0x00000F0A = 20180611T22:51:04
0x00000F02 = 20180611T22:49:50
PR_CREATION_TIME = 20180611T22:51:04
PR_CLIENT_SUBMIT_TIME = 20180611T22:51:04
PidLidValidFlagStringProof = 20180611T22:49:50
Notably within this test we see groupings of timestamps. PidLidValidFlagStringProof and 0x00000F02 appear to reflect the time that the user pressed 'Send' while PR_CREATION_TIME, PR_CLIENT_SUBMIT_TIME and 0x00000F0A appear to reflect the time the message was actually sent from the computer once it had network connectivity restored.
Conclusion
In answer of the challenge the PR_CLIENT_SUBMIT_TIME and PR_CREATION_TIME most accurately reflect when a message was sent from a system. This is consistent with Microsoft documentation which indicates that "The store provider sets PR_CLIENT_SUBMIT_TIME to the time that the client application called IMessage::SubmitMessage." and that PR_CREATION_TIME is "set by message store providers on outgoing messages." as detailed here.
It should be noted however that in cases of a discrepancy between these timestamps and 0x00000F02 or PidLidValidFlagStringProof then it would appear that these may serve as an indication that while the message was transmitted at a particular time the user may have attempted to send (i.e. pressed 'Send') at a time prior to it's transmission.
Further testing
This analysis has been quick and dirty and leaves lots of unanswered questions. Some areas for possible further research may include:
Reviewing of other timestamps as they appear in other MAPI Properties.
Review of timestamp behavior when system time is tampered with
Review of MAPI Property fields when comparing messages which are sent using 'Send/Receive' vs automatic message synchronization following a disconnected network connection