Audit and Restrict Mailbox Permissions (CM0074)

In Playbook

Details

  • ID: CM0074
  • Version: 1.0
  • Created: 14 March 2025
  • Modified: 14 March 2025
  • Type: Examine, Disable
  • Status: Active

Intended Outcome

Auditing and restricting mailbox permissions detects and blocks adversary exfiltration using mailboxes.

Introduction

Adversaries may attempt to modify mailbox account permissions in order to access the contents of a mailbox account or use the compromised mailbox as a staging ground for exfiltration. When responding to an incident involving business email compromise (BEC) or likely compromise of a user's mailbox, administrators should audit mailbox access logs and confirm additional email permissions were not delegated by the adversary.

Preparation

  • Administrators should confirm that Exchange mailbox auditing is enabled. This can be done by connecting to the Exchange Server and confirming that auditing is enabled before accessing audit reports from the Microsoft 365 portal. (Get-OrganizationConfig | Format-List AuditDisabled). Note that while mailbox auditing may be enabled, only subscribers with Premium licenses (e.g. E5/A5/G5 licenses) will be able to return mailbox audit log events in audit log searches in the Microsoft Purview compliance portal or via the Office 365 Management Activity API by default.

Risks

No Risks content identified.

Guidance

While delegation is likely possible on any mailbox application, adversaries are most likely to abuse Microsoft Exchange, a component of Microsoft 365 which may be run locally or, more often, as SaaS. The following instructions provide guidance for Microsoft Exchange.

Review Audit Logs in Microsoft Exchange

Administrators can investigate mailbox permission modifications in Microsoft 365 by checking the mailbox audit logs. This may be accomplished using different methods. Audit log searches can be conducted using Microsoft Purview or the Office 365 Management Activity API, entering commands in Exchange Online PowerShell, and/or generating reports via Exchange Admin Center (EAC). Microsoft Purview Audit (Premium) provides administrator's with access to MailItemsAccessed audit records. These records can guide their hunt for suspicious permission modifications of suspected compromised accounts. Alternately, administrators might consider using the EAC to run a non-owner mailbox access report for recent mailbox access. Organizations without access to Microsoft Purview Audit (Premium) should still generate an audit log report and search for suspicious use of Microsoft PowerShell cmdlets. The following cmdlets may be suspicious and warrant further investigation, given the right context:
  • Add-MailboxPermission: May be misused to add permissions to a mailbox.
  • Set-CASMailbox: May be misused to configure client access settings on a mailbox such as allowing them to sync mailboxes and copy mail to the adversary's device(s).
  • Add-MailboxFolderPermission: May be misused to grant permissions to specific mailbox folders (e.g., Inbox, Sent Items).
  • Set-MailboxFolderPermission: May be misused to modify folder-level permissions for users in mailboxes for existing permission entries.
  • Remove-MailboxFolderPermission: May be misused by an adversary to undo mailbox folder permission changes and cover up their tracks.
Auditing Exchange mailboxes may be accomplished with PowerShell using the following cmdlets:
  • Search-UnifiedAuditLog to search the Exchange Online unified audit log and other cloud-based services such as SharePoint Online, Microsoft Teams, and Microsoft Entra ID.
  • Search-MailboxAuditLog to search mailbox audit log entries matching specified search terms.
  • Get-MailboxPermission to retrieve permissions on a mailbox.
  • Get-MailboxFolderPermission (or, for Exchange Online PowerShell, Get-EXOMailboxFolderPermission) to view folder-level permissions.
Administrators may also want to consult existing PowerShell scripts used to perform mailbox auditing of Microsoft 365 accounts.

Review Graph API Application Permissions for Mailbox Access

Adversaries that compromise an Azure AD Tenant will be able to create new multi-tenant applications equipped with specific API permissions. Users who unintentionally consent to an applications permissions request may compromise their mailbox, among other possibilities. For example, an adversary might assign Mail.Read to an application to allow it to read mail in an inbox without a signed-in user. Other potential permissions include:
  • Mail.Read
  • Mail.ReadBasic
  • Mail.ReadBasic.All
  • Mail.ReadWrite
  • Mail.Send
  • MailboxSettings.Read
  • MailboxSettings.ReadWrite
  • Calendars.Read
  • Calendars.ReadWrite
  • Contacts.Read
  • Contacts.ReadWrite
Teams may need to investigate their Azure logs if they suspect access to a mailbox via suspicious application consent. Microsoft provides hunting queries / analytics to locate this type of behavior, including for the SolarWinds Compromise / Solorigate and the O365 Attack Toolkit. Alternately, CISA's Sparrow tool may be used to check the Graph API application permissions of all service principals and applications in M365/Azure AD. Administrators can use the New-ApplicationAccessPolicy PowerShell cmdlet to restrict application access to specific mailboxes.

Establish an Alert Policy for Mailbox Permission Changes

Administrators should consider establishing an alert policy to receive notifications when administrators assign mailbox permissions. Alerts may be created and viewed either via Microsoft's Compliance Center or the Microsoft Defender Portal.

References

  • ID: CM0074
  • Version: 1.0
  • Created: 13 March 2025
  • Modified: 13 March 2025
  • Type: Examine, Disable