Everything you need to know about MailItemsAccessed and more

Last week Microsoft released the highly anticipated and long awaited MailItemsAccessed Operation as part of the Advanced Audit functionality in Office 365. The good news, it is automatically enabled. The bad news, it is only for customers with an Office 365 or Microsoft 365 E5 license.

In this article my colleague Joey Rentenaar and I will provide you with details on the new artefact and share with you how you can use it to identify what emails were accessed by a threat actor. Also we have developed an open-source tool to support analysis of the new artefact and it's available here.

Why is this important?

One of the biggest challenges during a Business Email Compromise investigation is to determine what emails were accessed by a threat actor. At the moment you have to assume that a threat actor had access to all emails for a compromised account during the period of a successful compromise. Since a compromise of Personally Identifiable Information(PII) can lead to regulatory fines under the GDPR and notification of data subjects you really want to know what data was exposed. The new MailItemsAccessed logging can be used by incident responders to get a better understanding of the scope and the depth of an email data breach. For attorneys it is great as well, because with this audit logging you have factual bases for claims on what data was accessed during a data breach.

What is MailItemsAccessed?

MailItemsAccessed is a new Operation recorded in the Mailbox Audit Log and the Unified Audit Log. There are two different types of accessing messages being sync and bind access.

Sync access, is recorded when a mailbox is accessed by a desktop version of the Outlook client for Windows or Mac. More info on sync events can be found here.

Bind access, is recorded when an individual message is accessed, the Unified Audit Log also contains the message id of an email, required to determine which email was accessed. More info on bind events can be found here.

How to access the MailItemsAccessed logs?

There are multiple ways of accessing this information, the audit logging can be investigated using the Security and Compliance Center, the Microsoft API or by using Powershell cmdlets (Search-UnifiedAuditLog and Search-MailboxAuditLog).

Open Audit log search in the Security and Compliance Center and under Activities select 'Accessed mailbox items':

The above setting will filter the audit log for MailItemsAccessed events. Clicking on one of the entries will provide you with more details on the recorded action. We prefer to use Powershell for collection of the logs, because we can acquire all logs at once with the Office 365 Extractor. Also the search and filtering options in the interface are limited. To acquire the logs either run the Office 365 Extractor or use the afore mentioned Powershell cmdlets directly.

To display MailItemsAccessed records and limit the output to the most important fields run the below command for the time period of interest:

Search-UnifiedAuditLog -Operations MailItemsAccessed |select CreationDate, Operations, UserIds, AuditData |fl *

Output:

Using MailItemsAccessed for an investigation

Now to the most important question:

"What email data was accessed by the threat actor?"

To help you answer the above question we developed the MailItemsAccessed tool or in short MIA, you can download it here. MIA relies on the UnifiedAuditLog and the Message Trace log. You will need to have an account with sufficient permissions to use the tool. For more info on setting up MIA visit the Readme on our Github page.

The workflow of the tool is based on the below investigative steps:

The output of each step is the input for the next step.

Step 1: Identify sessions belonging to the threat actor

The first step is determining sessions belonging to the threat actor. We assume that you've already identified the account(s) compromised by the threat actor or the IP-address the threat actor is using.

Run MIA with the -Sessions parameter and the compromised user account or the IP-address the threat actor uses to identify suspicious sessions. In the example below we are searching for sessions belonging to the compromised user G.Jacobs@kwizzy.onmicrosoft.com.

In the output you can see multiple SessionIds and IP-addresses for one user account. Based on your indicators of compromise you should be able to determine what sessions are legitimate and the ones that are not. Another interesting column is the 'OperationCount' this shows the count of messages that were accessed in a bind operation. All bind operations that occur within a 2-minute interval are aggregated, the number of bind operations that were aggregated in the record is displayed in the OperationCount field.

Note: Some sessions do not have a SessionId this is because legacy authentication was used to login. For more information take a look at this Microsoft blog on sessions.

Step 2: Identify InternetMessageId

Using the output of the first step we identified a suspicious sesssion based on the IP-address that was used. Next step is using the SessionId to gather the InternetMessageID(s) of the accessed messages. The InternetMessageId is a unique identifier for email messages, with this piece of information we are able to identify individual emails.

Run MIA with the -Messages parameter and add suspicious SessionId(s) to the -Sessions parameter as shown below:

MIA returns all InternetMessageID(s) associated with the session. Now that we know what messages were accessed for a suspicious session, we can use the InternetMessageID(s) to find out the metadata of the emails that were accessed. When you use the -Save flag, the InternetMessageID(s) and the email metadata are automically saved to the current working directory.

Step 3: Identify Email metadata

The final step is using the Message Trace Log to determine the metadata of the exposed emails. Run MIA with the -Email parameter and use the -Input parameter to load a file with MessageID(s). The output can be printed to the Terminal or to File with the -Output flag. Below we can see the metadata of the emails that were accessed printed to the terminal.

Using the above information, you can work with legal counsel or anyone else to make an assessment on whether Personally Identifiable Information(PII) was accessed.

Limitations to the script

• The script relies on the Get-MessageTrace cmdlet to retrieve the email metadata this cmdlet only goes back 10 days. Workaround is using the Start-HistoricalSearch, which allows you to go back to 90 days.
• The Search-UnifiedAuditLog cmdlet used to retrieve the SessionId and the InternetMessageID can at maximum only return 5000 results. Make sure you limit your search based on the username or IP-address.

P.S. The username in the screenshots is fictious and unrelated to an actual case.

Conclusion

Let's start with the positive, we believe that with the addition of the MailItemsAccessed, we will able to better support and inform our clients on what emails were exposed to the threat actor. For instance, when we work with attorneys we can now provide them with evidence to help them make a legal assessment.

Some critical notes, we have tested the sync access operation which should record when a mailbox is synchronised to an external client. We have performed several experiments where we executed a full sync of a mailbox with a local installation of Outlook and Thunderbird and no sync events were recorded. This is pretty disappointing and will hopefully work better in the future.

Another issue is that identifying the email metadata using the InternetMessageID is very limited. You can either use the Get-MessageTrace cmdlet with a history of 10 days or the very slow Start-HistoricalSearch. It would be great if we can use the InternetMessageID in the eDiscovery module in Office 365 to quickly identify the email contents.

Last but not least we see that a lot of our clients do not have a Microsoft E5 license and currently that is required for the MailItemsAccessed Operation to be recorded. It would be great if this functionallity is expanded to E3 licenses.