Microsoft 365: Identifying Mailbox Access

With the advent of remote work in recent times, the number of organizations affected by business email compromises (“BEC”) rose exponentially in 2020.¹ One of the biggest challenges incident responders face during a BEC investigation is identifying and quantifying the data accessed by a threat actor. Microsoft’s Office 365^® infrastructure, now called Microsoft 365^®, has historically been a high priority target for cybercriminals, and Microsoft^® has implemented robust auditing options to aid investigators in determining what data has been accessed. Without detailed logging, incident responders must assume that all information in a mailbox could have been accessed in a compromise. However, this blog post aims to provide direction on narrowing that scope and using multiple log sources to identify the malicious levels of access given the following parameters:

1. Mailbox Sync
2. Mail Items Accessed
3. Actions within Mailboxes
4. Delegate Email Access

 

1.   Mailbox Sync

In late 2020, Microsoft announced its decision to revoke its support for legacy authentication across Exchange. Legacy authentication does not support multi-factor authentication and includes authentication requests made by clients using mail protocols such as IMAP, POP3, SMTP, ActiveSync^®, etc. Threat actors often use legacy authentication to perform brute force or password spray attacks, as they can easily write scripts that leverage these protocols.

During investigations, Stroz Friedberg commonly observes threat actors using legacy authentication connections to facilitate a mailbox synchronization event, which effectively allows for wholesale offline access to the contents of a compromised mailbox. Whether established via IMAP/POP3 protocols or ActiveSync to a mobile device, we can look to user agents in the Unified Audit Log (“UAL”) and the client information in the Mailbox Audit Log (“MAL”) to identify legacy authentication usage. However, if audit logging is not enabled within the tenant, Azure^® Active Directory (“Azure AD”) can be another valuable login source to help investigators distinguish between legacy and modern authentication protocols.

UAL Mailbox Sync Indicators

The Unified Audit Log tracks user and account activities across all Microsoft 365 services. Most importantly, the UAL contains detailed logging for sign-in activities including, but not limited to, timestamps, IP addresses, and user agents. User agents detail information about the device and browser leveraged to sign-in. Stroz Friedberg has commonly observed the following types of user agents associated with legacy authentication-based logons.²

User agents observed:

• “Android™,” “iPhone^®/iPad^®,” or other mobile devices in name
• “Outlook^® or other thick email clients in name
• “BAV2ROPC”*
• “CBAInProd”*

 

*These user agents indicate a potential syncing of the mailbox. In some cases, additional fields may help to determine if legacy authentication applies to the specific client leveraged to access the mailbox (ex. version of Outlook).

MAL Mailbox Sync Indicators

The Mailbox Audit Log tracks mailbox-related activities and actions performed by mailbox owners and admins, containing slightly different information from the UAL. Unlike in the UAL, where only UserLoggedIn operations and their associated user agent string indicate a synced mailbox, the MAL includes indicators of a synced mailbox within the ClientInfoString field across all operations.

NOTE: By default, MailboxLogin events (as shown below) are not recorded via the Mailbox Audit Logs. This specific event type must be enabled on a per-mailbox basis. More information on how to enable the operation can be found in Microsoft documentation.

Client info strings observed:

• “Client=ActiveSync”
• “Client=POP3\/IMAP4;Protocol=POP3”
• “Client=POP3\/IMAP4;Protocol=IMAP4”
• “Outlook” or other thick email clients in name
• “Android,” “iPhone/iPad,” or other mobile devices in name

 

Azure Active Directory Mailbox Sync Indicators

Azure AD is a cloud-based identity and authentication service included in Microsoft 365 that manages user login activities across the environment and provides insight into legacy authentication protocol usage. Indicators of a mailbox sync can be found in the ClientApp field within the Sign-In logs, which denotes the type of application leveraged to connect to the tenant.

Legacy authentication client apps observed:

• Authenticated SMTP
• Autodiscover
• Exchange ActiveSync (EAS)
• Exchange Online PowerShell
• Exchange Web Services (EWS)
• IMAP4/POP3
• MAPI over HTTP (MAPI/HTTP)
• Offline Address Book (OAB)
• Outlook Anywhere (RPC over HTTP)
• Outlook Service
• Reporting Web Services

 

2.   Mail Items Accessed

Before the introduction of the MailItemsAccessed operation, forensic analysts had to assume that all sensitive information in a mailbox could have been accessed by a threat actor when a user account was compromised. Within both Unified and Mailbox audit logs, the MailItemsAccessed operation helps investigators assert whether a specific piece of mail data has been accessed maliciously, covers all mail protocols (POP, IMAP, MAPI, EWS, Exchange ActiveSync, and REST), and is enabled by default for users with an E5 license. Additionally, audit logs have session ID attributes and source IP addresses associated with mail items to help differentiate attacker actions from day-to-day user activities.

Types of Access

MailItemsAccessed events are triggered by two event types: Sync and Bind operations.

Sync operations occur when wholesale downloads of a folder with mail items are synced locally from the cloud, typically occurring when accessing a mailbox via the desktop Outlook client on Windows^® or Mac^®.  Upon unauthorized access into a mailbox, sync operations indicate that investigators should assume that all mail items in the synced folder are copied locally and have been compromised. More information on sync operations can be found in Microsoft documentation.

Bind operations, as opposed to sync accesses, audit accesses to individual mail items, identified by the message’s InternetMessageID, a unique identifier assigned to email messages. A single bind event can contain multiple InternetMessageIDs and each of those messages should be considered compromised. Bind events may be reported even for messages that were not clicked on or “accessed”, even if previews are disabled within the application (see Differences in Logging across Protocols for more information).

Limitations on MailItemsAccessed Protocols

Whenever a Microsoft 365 account with advanced auditing is accessed, the MailItemsAccessed operation is logged, even if the emails may not have been read — just accessing the inbox will trigger a sync event for the inbox folder or bind events for messages that appear on the screen. Beyond this initial access, the logging of the operation then applies to messages that have the following interactions:

• Directly accessed or read within Outlook Desktop client or Web Access*
• Directly accessed via API calls (PowerShell^®, EWS, etc.)
• Synced using a client application
  • Mobile clients will log explicit messages accessed
  • Desktop clients only log that a sync operation for a folder has occurred, and not accesses to individual messages

 

*Specific messages in a thread are recorded only if the individual message is explicitly clicked.

If substantial numbers of emails are accessed within a 24-hour period, throttling will occur and temporarily stop the logging of the MailItemsAccessed operation – investigators should understand that any items in the mailbox could have been accessed during that time period. See Microsoft documentation for more detail. Figure 1 below is an example of which field to reference to see if throttling has occurred in your logs, located in the Microsoft 365 portal under both unified and mailbox audit logs.

 

Differences in Logging across Protocols

Stroz Friedberg conducted several tests on the MailItemsAccessed operation to better understand the nuances of Microsoft’s logging across commonly leveraged protocols.

Our testing explored four avenues of accessing mailboxes, illustrating the type of access associated with the protocol, as well as the mail items logged as “accessed.” Previews were enabled for the OWA and IMAP4/POP3 protocols.

Outlook Desktop Client

When a mailbox is accessed from the desktop client, messages are downloaded from the cloud to a local cache via the sync operation and are accessible even without internet connection. Consequently, specific message viewing activities will not be audited, and the MailItemsAccessed operation will apply to the entire folder associated with the sync. In the example below, the entirety of the “Inbox” folder was synced and is considered “accessed.” Stroz Friedberg leveraged Outlook 2016 on a Windows 10 device to conduct testing for this protocol.

NOTE: The Path field will be set to “Not Available” for Sync operations.

Outlook Web Access (OWA)

When accessing mail items from the Outlook web application, the MailItemsAccessed operation is associated with bind accesses, meaning that specific message IDs will be associated with user activities.

In Stroz Friedberg’s testing, we sent 3 unique emails to a test account to explicitly click on or “access,” while leaving the remaining messages in the inbox as unread. We then accessed the test account using a Windows 10 device with Chrome™ v. 94 browser (with previews enabled) and clicked on the 3 messages intended to be accessed. Upon examining the MailItemsAccessed logs corresponding to this testing, the 3 emails were recorded as accessed, in addition to the next 7 emails in the mailbox. The next 7 emails in the mailbox were present on the screen during testing, and we can hypothesize that those messages were recorded as “accessed” through the previews.

NOTE: MailItemsAccessed records reference specific messages via the InternetMessageID, as opposed to specific message subjects. If the mail item was sent and/or received within the last 90 days, Microsoft’s Message Trace logs can be leveraged to correlate InternetMessageIDs with specific mail items.

Outlook Mobile + Mail App (iOS and/or Android)

Accessing a mailbox from an Outlook iOS or Android application is shown to trigger events categorized under bind accesses. Similarly, accessing items via the default Mail Application on iOS and Android falls under the bind access as well.

In Stroz Friedberg’s testing, we sent 6 unique emails to a test account – 3 to be explicitly clicked on or “accessed” and 3 to be avoided. We then accessed the test account via both an Outlook iOS application and the Mail App on iOS (with previews disabled) and clicked on the 3 messages intended to be accessed. Upon examining the MailItemsAccessed logs corresponding to this testing, all 6 emails were recorded as “accessed” in addition to 2 other messages already in the inbox (not included in the testing process.) Similar to the results of the OWA accesses, though previews were disabled for this test, those 5 unopened emails were visible on the screen during testing, and we can hypothesize those messages were still recorded as “accessed”.

IMAP4/POP3 Clients

Like the behavior observed in the OWA and Outlook Mobile/Mail App accesses, Stroz Friedberg accessed a test account using legacy authentication protocols, which are associated with bind accesses. Our testing (with previews enabled) indicated that the audit log records more messages as “accessed” than clicked on. Upon explicitly clicking on 4 messages, the MailItemsAccessed logs corresponding to the testing showed the next 6 messages were “accessed,” as those message previews were visible on the screen at the time of testing.

Test Results Summary

Table 1 below illustrates the results of our testing:

The results of our testing demonstrated that MailItemsAccessed events can occur on mail items that were not explicitly clicked on or “accessed,” but rather, likely were logged due to the presence of messages on the screen at the time of access even if previews were disabled. During investigations, examiners should keep in mind that the total number of messages associated with MailItemsAccessed event may encompass more items than solely the messages explicitly accessed.

OAuth Analysis

Applications are granted varying levels of privileges and may have specific OAuth permissions that allows threat actors to access sensitive data within the environment without needing to leverage a compromised user account. MailItemsAccessed events contain an application ID entry which can indicate that an application, third-party or otherwise, had email access via OAuth permissions, such as Mail.Read, Mail.ReadWrite, etc.

In the event of a compromise, organizations should review MailitemsAccessed operations with known malicious app IDs for applications found to be compromised to determine which user accounts may have an additional avenue for unauthorized access.

In Stroz Friedberg’s testing, mail items accessed via applications were associated with bind events and log the specific message IDs associated with those events.

NOTE: If a mail item was NOT accessed via an application, there would not be an AppID field in the corresponding log entries.

 

3.   Actions Within Mailbox

In the absence of an E5 license, which would include logging for the MailitemsAccessed operation, other operations in the MAL and UAL can provide insight into which specific mail items were interacted with, such as message updates and deletions. Additionally, threat actors may also place persistence mechanisms to maintain a hold within the environment, such as forwarding settings applied to mailboxes and inbox rules that contain forwarding properties.

MAL/UAL Operations

It is common for a threat actor to delete email messages, specifically emails related to the initial phishing campaign or subsequent phishing and/or fraud attempts throughout the duration of the compromise. In order to identify this activity, investigators should analyze specific operations such as SoftDelete, HardDelete, and MoveToDeletedItems.

Stroz Friedberg observed that inbox rules set to delete specific messages will also trigger deletion operations, which are tracked in the audit log as well. Thus, investigators should leverage additional fields within these logs, such as sessionIDs or ClientIPs, to distinguish between unauthorized, threat actor-attributed activities versus automated or otherwise legitimate user activities.

These operations apply to all messages, regardless of whether they have been read or unread.

The Update operation also sheds light onto which of the items the user interacted. Interactions include a change to any of the message properties. While the Update operation indicates an interaction with these items (potentially reading messages), not all messages interacted with will have an Update event.  This is unlike MailItemsAccessed, which is a more inclusive operation. In the absence of MailItemsAccessed, the conservative approach would be to consider only items with an Update operation as compromised, although this is done with the understanding that there may have been other accessed messages for which the logs do not provide visibility.

Inbox Rule Forwarding + Forwarding Settings

During a compromise, threat actors may create persistence mechanisms in the form of inbox rules with forwarding parameters or by setting a mailbox to forward all messages to an account outside of the client’s domain. While companies may legitimately utilize these settings for business operations, malicious rules may be easy to overlook and can allow for sensitive data to leave the compromised user’s mailbox. Be sure to note forwarding addresses to suspicious external domains, such as phishing domains or personal email accounts.

If any inbox rules with unauthorized mailbox forwarding are identified, consult Message Trace logs to determine which specific mail items have been forwarded to unintended recipients. These messages should be considered “accessed,” as they have been exfiltrated from the environment via the malicious rule or setting.

Message Trace Indicators

Message Trace logs contain several fields that indicate if a mailbox has been set to forward all messages to another account. These logs will only show incoming and outgoing messages for 90 days, so be sure to take that into consideration when determining the completeness of the logs compared to the overall window of compromise.

• If a forwarding address has been identified from malicious rules or forwarding settings, examiners can filter through trace logs for messages with that address as the recipient.
• In cases where a forwarding email address cannot be identified, the following steps can help identify potential malicious forwarding:
  • When filtering for outbound messages (“Originating” in the directionality field), if there are many message subjects pre-pended with “FW:” and the recipient_status is consistent across those events, this may indicate that a forwarding setting to that recipient may be in place.
  • If there are many message subjects pre-pended with “Automatic reply” and the recipient_status is consistent across those events, this may indicate that a forwarding setting to a recipient with an auto-reply setting may be in place.

 

4.  Delegate Email Access

In the event of a compromise, the scope of data accessed may expand depending on whether the compromised mailbox already had delegated rights to another mailbox or if the threat actor granted themselves specific rights to another mailbox.

Shared mailboxes may have the following permissions: full access, send as, and send on behalf.

Analysis

Unified Audit Log

If a mailbox changes the permissions and/or delegation rights to another mailbox, the following operations in the Unified Audit Log will be logged at time of configuration: Add-MailboxPermission, Remove-MailboxPermission, and Set-Mailbox.

• Specific mailbox permissions granted will be listed under the AccessRights subfield under the Parameters field, as shown in Figure 3 below.
• The account listed as User will have the designated AccessRights into the account listed as Identity.

 

 

Mailbox Audit Log

Upon identifying mailboxes configured with delegated accesses in the Unified Audit Logs, one can leverage mailbox audit logging (if enabled for the environment) to determine if a mailbox has been accessed via a delegated user. The Exchange Admin Center allows users to export all events with delegated access to a mailbox, as illustrated in Figure 4 below.

Microsoft 365 Portal

Within the admin center of the Microsoft 365 portal, each active user has a “Mail” tab with the corresponding Mailbox permissions the user is granted. “Read and manage permissions” from Figure 5 below correlate to the FullAccess permissions illustrated in Figure 3 above.

 

Exception

If a threat actor uses legacy authentication (ex. BAV2PROC or CBAinProd) to access a user account, any delegated and/or shared mailboxes for that account are NOT able to be accessed and would not be considered within the scope of the compromise. However, additional investigation may be required (especially if access via OWA occurred) to determine if additional accesses to those delegated and/or shared mailboxes occurred.

Conclusion

Every organization has mailboxes containing varying levels of sensitive information. Whether it be employees in the Payroll or HR department or an IT admin with elevated mailbox privileges, Stroz Friedberg has seen threat actors leverage a variety of techniques to access a mailbox and expand their foothold. Although this post examines access in a Microsoft 365 context, organizations with on-prem Exchange can reference many of the same artifacts, such as trace logs, inbox rules, and mailbox auditing, if enabled. Identifying the scope of malicious access through the above mechanisms can assist with mitigating the losses incurred in the event of a compromise.

Please note that the information above was written in January 2022 and may be subject to change based on changes that Microsoft makes within Microsoft 365, or alternative mailbox access techniques that arise in the future.

 

Author: Rachel Kang
February 8, 2022
© 2022 Aon Plc

This material has been prepared for informational purposes only and should not be relied on for any other purpose. You should consult with your own professional advisors or IT specialists before implementing any recommendation or following the guidance provided herein. Further, the information provided and the statements expressed are not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information and use sources that we consider reliable, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future.

 

1 https://www.darkreading.com/attacks-breaches/fbi-business-email-compromise-cost-$18b-in-2020/d/d-id/1340452

2 User agents can be spoofed by malicious threat actors; however, for the purposes of this blog post, we assume that the audit logging examples are accurate.