E-mail Forensics in a Corporate Exchange Environment (Part 5)

If you would like to read the other parts in this article series please go to:

• E-mail Forensics in a Corporate Exchange Environment (Part 1)
• E-mail Forensics in a Corporate Exchange Environment (Part 2)
• E-mail Forensics in a Corporate Exchange Environment (Part 3)
• E-mail Forensics in a Corporate Exchange Environment (Part 4)

E-mail Tampering

Using MFCMapi, let us analyze the e-mail present in Victim’s inbox folder that the user claims was received by Offender. This time, we navigate to Inbox:

Figure 5.1: Victim’s Inbox Folder in MFCMapi

Now, we right-click on Inbox and select Open Contents Table. This will open a new MFCMapi window with the entire content of the user’s Inbox folder:

Figure 5.2: Inbox Content in MFCMapi

In the above screenshot we can see the e-mail in question with the subject “Drinks” sent by Offender. Please note that the times mentioned in MFCMapi are GMT-1 in this case. As such, where Received says “02:36:11” it is actually “03:36:11” as we saw previously in the e-mail screenshot (Figure 4.6).

From the vast list of properties for this e-mail, we are interested in four for this particular investigation:

Table 1

At the time a sender submits an e-mail, it gets stamped with the date and time in the PR_CLIENT_SUBMIT_TIME property. When that e-mail reaches the recipient’s mailbox, Exchange stamps the PR_MESSAGE_DELIVERY_TIME and PR_CREATION_TIME properties. If the e-mail remains unaltered, the PR_LAST_MODIFICATION_TIME will match the PR_CREATION_TIME property. Obviously if these two properties do not match, it means the e-mail was modified by the user as no other process will update this property.

If we look at these two properties for this particular e-mail, we can see that PR_LAST_MODIFICATION_TIME is more than 30 minutes ahead of PR_CREATION_TIME, proving the e-mail was tampered with:

Figure 5.3: Proof E-mail was Modified

By comparison, if we look at any e-mail that has not been modified, we can see that these two properties match:

Figure 5.4: Proof E-mail Was Not Modified

If we now look at the PR_LAST_MODIFIER_NAME property, we will see the value of Victim, proving again that it was the user Victim who modified the e-mail. On an unaltered e-mail, this field would have the name of the sender.

Figure 5.5: Last Modifier Name

When exporting a mailbox to a PST file, Exchange will stamp PR_LAST_MODIFICATION_TIME with the date and time each message was created on the PST file. Therefore, this particular procedure can only be done against the mailbox on Exchange, not on a PST file.

Another possible issue is that MFCMapi is a tool that does not require installation nor specific rights on a workstation in order to be used. This means that any normal user can download and use this tool to manipulate their mailbox. What a knowledgeable IT professional would try to do is use MFCMapi to change the PR_LAST_MODIFICATION_TIME so it matches the PR_CREATION_TIME property.

Figure 5.6: Modification Time Property

By editing any of these properties, we can see that it is made of two values: LowDateTime and HighDateTime. This is a typical TimeEncoding structure that specifies a date and time in Coordinated Universal Time [UTC]. To be processed as a valid UTC time, HighDateTime and LowDateTime are assigned to a FILETIME structure, a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since January 1, 1601, Coordinated Universal Time (UTC).

However, it is just too complicated to decipher how to calculate both these times for most people. As such, one could simply copy the values of LowDateTime and HighDateTime from the PR_CREATION_TIME or PR_MESSAGE_DELIVERY_TIME properties for example:

Figure 5.7: Delivery Time Property

Then paste those values into the PR_LAST_MODIFICATION_TIME property and the Date field should match exactly what we want it to be:

Figure 5.8: Changing Modification Time Property

The problem with this approach is that as soon as we click OK to save the changes, PR_LAST_MODIFICATION_TIME will get updated to the date and time this change was made, possibly making things even worse for the user (in this case the change was made approximately 22h after):

Figure 5.9: Modification Time Property Updated to Wrong Value

SendAs Abuse

Although we already saw how to check if an e-mail was sent using SendAs permissions both using Auditing Mailbox Access and Message Tracking Logs, data from these two features might not be available for the forensics investigator. In such cases, the investigator needs to rely on data from the mailbox itself.

Using MFCMapi, we can look at two important properties of the received e-mail: PR_SENDER_SMTP_ADDRESS_A and 0x5D09001E:

Figure 5.10: SendAs Property in MFCMapi

As it can be seen in the screenshot above, the PR_SENDER_SMTP_ADDRESS_A property matches Offender as it was, supposedly, him who sent the e-mail. PR_SENDER_NAME is what the recipient sees in the e-mail From field. However, if we look at the 0x5D09001E property, it mentions the hacker’s e-mail address. Whenever an e-mail is sent using SendAs permissions, this property is stamped with the user who actually sent the e-mail.

If we look at a “normal” e-mail sent by Offender himself, we can see that both properties match, meaning it was actually Offender who sent the e-mail:

Figure 5.11: Value of Property in “Normal” E-mail

For some reason this property does not have a description. MAPI is full of tags that are used to describe the properties of items stored in Exchange mailboxes. As the variety of stored items expanded, so did the set of MAPI property tags. As such, a utility called MrMapi was created to report all known MAPI tags. It is typically used by developers to find what tags exist so they can reference the right tag or do not end up creating a new tag when one already exists. Using this tool we can check what the tag for PR_LAST_MODIFICATION_TIME is, for example, and vice-versa:

Figure 5.12: Example of MrMapi

However, this tool does not have any information on the tag used above to check if an e-mail was sent using SendAs permissions:

Figure 5.13: MrMapi & SendAs Property

As it can be seen there are several methods to check if an e-mail was sent using SendAs permissions. The method chosen will obviously depend on the information available to the investigator but there is always a method of checking who actually sent an e-mail.

Conclusion

The good old days of simply investigating a user’s mailbox cached on their local machine are gone. When configured properly, an Exchange environment can keep logs of practically everything that happens in the messaging system. From changes associated with day-to-day tasks, to unauthorized access to a mailbox or even misuse of the messaging system itself. This gives digital forensic experts a greater challenge but it also makes their life easier if they know where to look for information and how to retrieve it.

Evidence preservation is the key as more evidence is located at the server end rather that the client end. For this reason, when investigating a messaging system based on Exchange, it is crucial for forensics investigators to work closely with the Exchange administrators, otherwise vital information for the investigation might be lost. The importance of getting information out of key Exchange features such as Single Item Recovery, Message Tracking Logs or audit logs as early as possible and preserving this evidence before Exchange deletes or overwrites it cannot be overstated.

Unfortunately the possible scenarios of misuse of an Exchange environment, both from a user and from an administrator perspective, are endless and this article series could simply not cover them all. However, an attempt to cover the most common scenarios was made, showing how to look for information on the Exchange servers as well as on users’ mailboxes using the free tool MFCMapi. By explaining how each Exchange feature works and how to gather data from them, it is simply a matter of adjusting each technique to the particular case in hands. For example, if a forensics investigator can search the administrator audit logs to see who gave permissions to a particular mailbox, he/she can easily adjust the search to find out who deleted a mailbox.

Microsoft is aware of all security compliances that organizations have to adhere to more and more these days, and this article is the proof that it is making good progress in allowing organizations to easily meet compliance requirements, making at the same time the job of a forensics investigator easier.

If you would like to read the other parts in this article series please go to:

• E-mail Forensics in a Corporate Exchange Environment (Part 1)
• E-mail Forensics in a Corporate Exchange Environment (Part 2)
• E-mail Forensics in a Corporate Exchange Environment (Part 3)
• E-mail Forensics in a Corporate Exchange Environment (Part 4)