Email compromises within Microsoft 365 are too common these days. The TrustedSec Incident Response team receives a lot of calls to investigate M365 email breaches, and one (1) of the most common investigation goals is to determine what the attacker accessed within the victim’s email. Unfortunately, this is not an easy thing to do, and it’s important to understand the limitations you might face.

tl;dr

• MailItemsAccessed events record emails accessed by an IP address.
  • These are only available with Audit (Premium) functionality.
  • This functionality is only available for some licenses.
• Mailbox Audit Logs may indicate other emails an attacker interacted with.
  • However, these only provide a limited view of activity.

MailItemsAccessed

The primary method of determining which emails were accessed by an attacker is examining MailItemsAccessed events within the M365 Unified Audit Logs or the user’s Mailbox Audit Logs. According to Microsoft, this event is only accessible if you have the Microsoft Purview Audit (Premium) functionality within your M365 license.

 The licenses that provide Audit (Premium) are:

• E5
• E3 + E5 Compliance add-on
• F1 or F3 plus:
  • F5 Compliance add-on
  • F5 Security + Compliance add-on

If the victim user wasn’t assigned one (1) of these licenses, MailItemsAccessed events won’t exist. Events also cannot be retroactively obtained, meaning that you can’t upgrade a user to E5 in the middle of an investigation and suddenly view all the events you were previously missing. 

There are two (2) additional items of interest to note. First, you do not have to assign everyone an E5 license—you can individually assign licenses to users. We recommend assigning high-risk users an E5 license, especially those users that may be targeted in a business email compromise attack (e.g., sales, accounting, C-level, etc.).

Second, Microsoft is making changes to which events are available within Audit (Standard). One (1) of the events being added is MailItemsAccessed. According to Microsoft, a preview for this event will be available in March 2024 and rollout will start in June 2024. Again, these will not be retroactive.

Mailbox Audit Logs

 Does this mean that if the user did not have one (1) of the Audit (Premium) licenses, you would be unable to view all emails accessed by the attacker? Yes. In these cases, you can only say that it is possible the attacker potentially accessed the victim’s emails during the time the account was compromised. Sorry; complain to your (un)favorite Microsoft sales rep.

 However, there are still ways to see if an attacker interacted with some of the victim’s emails. One (1) way is to pull Mailbox Audit Logs (MALs) for the victim. MALs contain events that occurred within the mailbox by the owner, delegate, or admin.

 Some of these events include:

• Copy - An item was copied to another folder.
• Move - An item was moved to another folder.
• MoveToDeletedItems - An item was moved to the Deleted Items folder.
• SoftDelete - An item was deleted from the Deleted Items folder and moved into the user’s Recoverable Items folder. It is available for recovery for the retention period configured within the mailbox.
• HardDelete - An item was permanently deleted and is not recoverable.

Two (2) other events deserve special attention: Create and Update. 

According to Microsoft, Create events within the MAL occur when “An item was created in the Calendar, Contacts, Draft, Notes, or Tasks folder in the mailbox (for example, a new meeting request is created). Creating, sending, or receiving a message isn't audited. Also, creating a mailbox folder isn't audited.” We have seen instances when emails are generated within the Draft Items folder for a user and the Create event logs it. This implies that artifacts of email creation may be logged using the Create event.

The Update event—if there was ever a more frustrating event, this is it. Microsoft says that the Update event is logged when “A message or any of its properties was changed.” Based on our analysis, the list of potential properties is documented here.

Unfortunately, there is limited information within the Update event to show what was updated, why, or to what value. Additionally, what triggers an Update event is fully unknown.

Does it mean the email was accessed? Maybe. Does it mean the attachment was accessed? Possibly. Does it mean the attacker looked at their screen wrong? All are equally possible. If we can find a more definitive answer to when Update happens, we’ll post it.

However, if a MAL event can be tied to an attacker’s IP address, it implies that they interacted with specific messages within the victim’s email. It won’t be an all-encompassing view of what the attacker did, but something is better than nothing.

There are other ways to determine what an attacker did while accessing a victim’s email account without the MailItemsAccessed event. Eventually, this should be an issue of the past, but until then, it’s important to understand the limitations you may have when performing an M365 email investigation and what you can determine from an email investigation.