Mailbox Auditing in Exchange Online: Complete Guide

Australian businesses lost more than $152.6 million to Business Email Compromise scams in 2024 – a 66 per cent increase from the previous year, according to the Australian Federal Police. BEC is now among the top three self-reported cybercrimes for business in Australia. The attack pattern is consistent: an attacker gains access to a mailbox, monitors conversations, creates inbox forwarding rules to silently copy emails to an external address, waits for the right moment to intercept a payment, and diverts funds before anyone notices.

When these incidents are investigated, the first question every forensic analyst asks is the same: what do the mailbox audit logs show? The answer, for far too many Australian businesses, is: not enough – or nothing at all.

Mailbox auditing in Exchange Online is the logging capability that records actions taken on and within mailboxes: who accessed what, when, from where, and what they did. It is the audit trail that makes incident response possible, that satisfies Privacy Act notifiable data breach investigation obligations, and that demonstrates the access controls your cyber insurer, your auditor, and the OAIC will want to see evidence of.

This guide explains everything Australian businesses need to know about mailbox auditing in Exchange Online: what it captures by default, what requires additional configuration, how to verify and extend your audit coverage using PowerShell, how to search audit logs through the Microsoft Purview portal, how retention works across different licence tiers, and how to actually use audit data to investigate a compromised mailbox.

At CodeHyper, we manage Microsoft 365 environments for businesses across Sydney. Email security and audit configuration are among the most frequently misconfigured areas we encounter. This guide reflects what matters in practice.

What Is Mailbox Auditing in Exchange Online?

Mailbox auditing is the Exchange Online feature that logs actions performed on user mailboxes, shared mailboxes, and Microsoft 365 group mailboxes. When auditing is active for a mailbox, Exchange Online records a log entry each time a defined action is performed – whether by the mailbox owner, a delegate with access permissions, or an administrator.

These log entries flow into the Microsoft Purview Unified Audit Log, which consolidates audit data from Exchange Online, SharePoint Online, OneDrive, Microsoft Entra ID, and other Microsoft 365 services into a single searchable store.

Mailbox audit records capture:

The identity of the person who performed the action (owner, delegate, or admin)
The specific action taken (email read, message deleted, message forwarded, folder permissions changed, and many others)
The mailbox on which the action was performed
The IP address and client application used
A timestamp of when the action occurred
In certain cases, the specific items affected

This data is the foundation of any email security investigation. Without it, determining what an attacker did inside a compromised mailbox – what they read, what they deleted, whether they set up forwarding rules, whether they sent fraudulent emails as the account owner – is largely impossible.

Is Mailbox Auditing Enabled by Default in 2026?

This is one of the most important things to get right, because there is a significant amount of outdated guidance still circulating – including from well-intentioned IT service providers – that incorrectly states mailbox auditing must be manually enabled for each user.

Microsoft enabled mailbox auditing by default for all Exchange Online organisations in January 2019. Since that date, auditing is automatically active for all user mailboxes, shared mailboxes, and Microsoft 365 group mailboxes in any tenancy created after that point. Tenancies created before 2019 should also have been updated, though it is worth verifying (we cover how to do this below).

This means that for the vast majority of Australian businesses running Microsoft 365 today, mailbox auditing is already on. The question is not whether it is on, but whether the right actions are being logged, whether logs are being retained for long enough, and whether anyone is actually monitoring and investigating those logs.

You can verify your organisation-level audit status with this PowerShell command in Exchange Online PowerShell:

powershell

Get-OrganizationConfig | Select-Object AuditDisabled

If the result is False, mailbox auditing by default is active for your organisation. If it returns True, auditing has been explicitly disabled at the organisation level and needs to be re-enabled:

powershell

Set-OrganizationConfig -AuditDisabled $false

To verify auditing status for a specific mailbox:

powershell

Get-Mailbox -Identity “user@yourdomain.com.au” | Format-List AuditEnabled, DefaultAuditSet, AuditOwner, AuditDelegate, AuditAdmin

A note on the DefaultAuditSet property: When Microsoft manages the default audit actions for a mailbox (the standard configuration), the DefaultAuditSet property shows which sign-in types are using Microsoft-managed defaults. If an administrator has previously customised the audit actions for a mailbox using Set-Mailbox, the corresponding sign-in type will be removed from DefaultAuditSet – and that mailbox will no longer automatically receive new default audit actions when Microsoft expands the default set. This is an important subtlety: if you have ever run a PowerShell script to customise audit actions across all mailboxes, those mailboxes may be locked to the audit set that existed at the time of that customisation, missing newer actions that Microsoft has since added to the defaults.

Understanding Sign-In Types and What They Mean for Auditing

Every mailbox audit log entry is classified by sign-in type – who performed the action. Understanding these three categories is essential for interpreting audit data correctly and configuring the right audit actions for each.

Owner refers to the mailbox account holder – the person the mailbox belongs to. Actions by the mailbox owner are logged under the Owner sign-in type. Owner audit actions are important for detecting situations where an account has been compromised and the attacker is operating as the legitimate user, or for investigating suspicious behaviour by the user themselves.

Delegate refers to any user who has been granted access to the mailbox by the owner or an administrator – someone with SendAs, SendOnBehalf, or FullAccess permissions. Delegate audit actions cover access by other users operating in or on behalf of the mailbox, which is critical for shared mailbox access monitoring and for detecting situations where excessive delegate permissions have been granted.

Admin refers to an Exchange Online administrator who has been granted access to a mailbox using administrative tools – not a regular user with delegate permissions, but an account performing administrative operations. Admin audit actions include actions performed by accounts holding the FullAccess permission assigned administratively, or by accounts accessing mailboxes through eDiscovery or administrative tools.

Each sign-in type has its own set of auditable actions, and each has a different default configuration. Not all available actions are audited by default – Microsoft selects a default set that balances coverage with storage and performance considerations. Understanding which actions are in the default set and which require explicit configuration is the difference between adequate audit coverage and genuine forensic capability.

What Actions Are Audited by Default – and What Needs to Be Added

Microsoft maintains a default audit action set for each sign-in type that evolves over time. As of 2026, the following is the current default coverage across sign-in types:

Default Admin actions audited: Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind, SendAs, SendOnBehalf, Create, UpdateFolderPermissions, UpdateInboxRules, UpdateCalendarDelegation, AddFolderPermissions, ModifyFolderPermissions, RemoveFolderPermissions, RecordDelete

Default Delegate actions audited: Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind, SendAs, SendOnBehalf, Create, UpdateFolderPermissions, UpdateInboxRules

Default Owner actions audited: Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, UpdateFolderPermissions, Undelete, UpdateInboxRules, UpdateCalendarDelegation, SendAs, SendOnBehalf, Create, MailboxLogin

The key action that is not in the default set for standard licensing and requires specific attention is MailItemsAccessed. This is arguably the single most important action for BEC investigations.

MailItemsAccessed: The Critical BEC Investigation Action

MailItemsAccessed is an audit action that records every time a mail item in a mailbox is accessed – read, previewed, or synchronised to a client. It is the action that allows forensic investigators to determine exactly which emails an attacker read during a compromise, what information they accessed, and the scope of data exposure.

Without MailItemsAccessed logs, a BEC investigation can confirm that a login occurred and that certain actions were taken – but it cannot definitively establish which emails were read. This matters enormously when assessing whether a data breach meets the OAIC’s notifiable data breach threshold, because the scope of what was accessed directly determines the required regulatory response.

MailItemsAccessed requires Microsoft 365 E5 or the Microsoft Purview E5 Compliance add-on. It is not available on E3 or Microsoft 365 Business Premium licences. For organisations on standard licences, MailItemsAccessed will not appear in audit logs regardless of configuration – the logs simply will not contain this event type.

For accounts that do hold E5 licences, MailItemsAccessed is included in the default audit set and does not require additional configuration. However, you should verify it is being captured:

powershell

Get-Mailbox -Identity “user@yourdomain.com.au” | Select-Object -ExpandProperty AuditOwner

If MailItemsAccessed appears in the output, it is being logged for that mailbox’s owner sign-in type.

Additional Actions Worth Enabling

Even on standard licences, there are audit actions not enabled by default that are valuable for security monitoring. The following PowerShell command adds additional owner-side actions that improve your audit coverage without requiring an E5 upgrade:

powershell

Get-Mailbox -ResultSize Unlimited –Filter {RecipientTypeDetails -eq “UserMailbox”} |

Set-Mailbox -AuditEnabled $true `

-AuditOwner @{Add=“MailboxLogin”,“HardDelete”,“SoftDelete”,“Move”,“MoveToDeletedItems”,“UpdateInboxRules”,“UpdateFolderPermissions”} `

-AuditDelegate @{Add=“SendAs”,“SendOnBehalf”,“Move”,“MoveToDeletedItems”,“SoftDelete”,“HardDelete”,“FolderBind”,“UpdateInboxRules”} `

-AuditAdmin @{Add=“Copy”,“MessageBind”,“SendAs”,“SendOnBehalf”,“HardDelete”,“SoftDelete”,“MoveToDeletedItems”,“UpdateInboxRules”,“UpdateFolderPermissions”}

Important: Using the @{Add=”…”} syntax preserves existing default audit actions and adds to them. Using a plain string assignment (the approach in older scripts that still circulate) replaces the entire action set and removes Microsoft-managed defaults, causing those mailboxes to stop receiving future Microsoft default updates. Use @{Add=…} syntax whenever extending audit coverage.

To restore a mailbox to full Microsoft-managed defaults for all sign-in types:

powershell

Set-Mailbox -Identity “user@yourdomain.com.au” -DefaultAuditSet Admin,Delegate,Owner

How to Verify Mailbox Audit Status Across Your Entire Organisation

Before making any changes, audit your current coverage. These commands give you a clear picture of where you stand.

Check audit status for all user mailboxes:

powershell

Get-Mailbox -ResultSize Unlimited –Filter {RecipientTypeDetails -eq “UserMailbox”} |

Select-Object DisplayName, UserPrincipalName, AuditEnabled, DefaultAuditSet |

Sort-Object AuditEnabled |

Export-Csv -Path “C:\MailboxAuditStatus.csv” -NoTypeInformation

Identify any mailboxes with auditing explicitly disabled:

powershell

Get-Mailbox -ResultSize Unlimited |

Where-Object {$_.AuditEnabled -eq $false} |

Select-Object DisplayName, UserPrincipalName, RecipientTypeDetails

Check audit status for shared mailboxes:

powershell

Get-Mailbox -ResultSize Unlimited –Filter {RecipientTypeDetails -eq “SharedMailbox”} |

Select-Object DisplayName, UserPrincipalName, AuditEnabled, DefaultAuditSet

Check organisation-level audit bypass accounts (accounts excluded from auditing):

powershell

Get-MailboxAuditBypassAssociation -ResultSize Unlimited |

Where-Object {$_.AuditBypassEnabled -eq $true} |

Select-Object Name, AuditBypassEnabled

Audit bypass associations are accounts for which mailbox auditing is entirely suppressed – no actions performed by these accounts on any mailbox are logged, regardless of mailbox-level audit configuration. This is designed for automated service accounts whose high-volume actions would otherwise flood audit logs with noise. Review all bypass accounts and confirm that each one has a documented business justification. An attacker who obtains credentials for an audit bypass account operates invisibly in your environment.

Connecting to Exchange Online PowerShell (2026 method):

The older MSOnline and Basic Authentication connection methods have been retired. Connect to Exchange Online PowerShell using the current ExchangeOnlineManagement module:

powershell

# Install the module if not already present

Install-Module -Name ExchangeOnlineManagement -Force

# Connect to Exchange Online

Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com.au

# When finished

Disconnect-ExchangeOnline -Confirm:$false

Modern Authentication is required. Legacy Basic Authentication for PowerShell connections to Exchange Online has been deprecated and removed.

Audit Log Retention: What You Get by Licence Tier

Knowing that audit logs are being collected is only half the picture. How long they are retained determines whether they are actually available when you need them – during an investigation, a compliance audit, or an OAIC data breach assessment.

Audit (Standard) – Microsoft 365 Business Premium, E3, F1, F3: The default retention period for Audit (Standard) logs is 180 days for all Exchange Online, SharePoint Online, OneDrive, and Microsoft Entra ID records. This changed from the previous 90-day default on October 17, 2023 – audit records generated before that date retain the 90-day period; records generated after are subject to the 180-day period.

Audit (Premium) – Microsoft 365 E5 or Microsoft Purview Compliance E5 add-on: Audit (Premium) provides a one-year default retention period for Exchange Online, SharePoint Online, OneDrive, and Microsoft Entra ID audit records. It also includes access to MailItemsAccessed and other high-value forensic events, higher API bandwidth for SIEM integration, and intelligent insights for Exchange Online and SharePoint Online investigations.

10-Year Audit Retention Add-On: Organisations with compliance obligations requiring extended retention can purchase the Microsoft Purview Audit 10-Year Retention add-on, which – paired with E5 Compliance or the Purview Suite – allows custom retention policies extending up to 10 years for specified audit record types.

A critical note on AuditLogAgeLimit: Older guides and scripts – including some that are still circulating – recommend using the Set-Mailbox -AuditLogAgeLimit PowerShell parameter to control audit log retention. This parameter is no longer applicable. Audit log retention is now configured and managed exclusively through Microsoft Purview audit retention policies. Setting AuditLogAgeLimit on a mailbox via PowerShell will have no effect on actual log retention in the Unified Audit Log.

The compliance implication for Australian businesses:

The OAIC’s Notifiable Data Breaches scheme requires organisations to investigate incidents as soon as practicable after becoming aware of a suspected breach. BEC incidents in Australia have historically gone undetected for weeks or months – the AFP noted cases where attackers operated inside compromised mailboxes for extended periods. At 180 days of retention on a standard licence, if a BEC incident is not detected within that window, the audit logs needed to investigate it will no longer exist. For any Australian business handling significant volumes of personal information or financial data, evaluating whether E5 licences or the Purview Compliance add-on are warranted – specifically for the retention and MailItemsAccessed capability – is a legitimate and important decision.

How to Search Mailbox Audit Logs in Microsoft Purview

The Microsoft Purview compliance portal is the primary interface for searching audit logs, and it has substantially replaced the older Security and Compliance Center audit search tool.

Accessing the Purview Audit portal:

Navigate to the Microsoft Purview portal: https://purview.microsoft.com. In the left navigation, select Audit. If your organisation has not previously enabled audit logging, you will see a banner to start recording activity – click it to enable. Once enabled, all subsequent activity is logged; historical activity before enablement is not retroactively captured.

Required permissions for audit search:

To search audit logs, your account must be assigned the View-Only Audit Logs or Audit Logs role in Microsoft Purview. By default, these roles are assigned to the Compliance Management and Organisation Management role groups in Exchange Online. Global Administrators have access by default.

Running an audit log search:

In the Purview Audit portal, set your date range (dates and times are in UTC – important when investigating incidents and correlating with local Australian time zones; AEDT is UTC+11, AEST is UTC+10), select the activities you want to search for from the Activities dropdown, optionally filter by user and by the specific file, folder, site, or mailbox. Click Search.

Key Exchange Online activity categories to search for BEC investigation:

Under Exchange mailbox activities, the activities most relevant to a BEC investigation include: MailItemsAccessed (E5 only), Sent message, Sent message using Send As permissions, Sent message using Send On Behalf permissions, Moved messages to Deleted Items folder, Permanently deleted messages from Deleted Items folder, Created inbox rule, Modified inbox rule, Removed inbox rule.

Under Exchange admin activities: Added delegate mailbox permission, Removed delegate mailbox permission, Set-Mailbox (used to change forwarding settings), New-InboxRule and Set-InboxRule (used to create forwarding or deletion rules).

Exporting audit results:

Audit search results can be exported to CSV from the Purview portal. The standard export limit is 50,000 records for Audit (Standard); Audit (Premium) supports larger exports. For investigations requiring more than 50,000 records, use the Search-UnifiedAuditLog PowerShell cmdlet with date range iteration:

powershell

# Search for mailbox-related audit events for a specific user over the last 90 days

$StartDate = (Get-Date).AddDays(-90)

$EndDate = Get-Date

$UserEmail = “user@yourdomain.com.au”

Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate `

-UserIds $UserEmail `

-RecordType ExchangeItem `

-ResultSize 5000 |

Select-Object CreationDate, UserIds, Operations, AuditData |

Export-Csv -Path “C:\AuditResults_$UserEmail.csv” -NoTypeInformation

For investigating inbox rule creation and modification:

powershell

Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate `

-UserIds $UserEmail `

-Operations “New-InboxRule”,“Set-InboxRule”,“UpdateInboxRules” `

-ResultSize 5000

For investigating external mail forwarding:

powershell

Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate `

-Operations “Set-Mailbox” `

-ResultSize 5000 |

Where-Object {$_.AuditData -like “*ForwardingSmtpAddress*”}

Shared Mailboxes, Resource Mailboxes, and Group Mailboxes

Mailbox auditing behaviour is not identical across all mailbox types, and this is a frequently overlooked area in audit configuration.

Shared mailboxes are subject to the same default audit configuration as user mailboxes – auditing is on by default. However, because shared mailboxes are often accessed by multiple delegates, the delegate audit actions are particularly important for shared mailboxes. Every access to a shared mailbox by a named user is logged under the Delegate sign-in type. This makes shared mailboxes important sources of audit data for investigating who accessed a specific shared resource and when.

Resource mailboxes (room and equipment mailboxes used for calendar booking) are also covered by default mailbox auditing, though the actions taken on these mailboxes are typically less security-relevant than user or shared mailboxes.

Microsoft 365 group mailboxes have mailbox auditing enabled when your organisation enables mailbox auditing by default, but with an important limitation: you cannot customise the audited actions for Microsoft 365 group mailboxes. Microsoft manages a fixed set of default audit actions for group mailboxes, and these cannot be modified via Set-Mailbox in the same way user and shared mailboxes can be configured.

Multi-geo environments have a specific limitation: cross-geo mailbox auditing is not supported. If a user in one geographic region accesses a shared mailbox located in a different geographic region, those actions are not logged in the shared mailbox’s audit log. Exchange admin audit events remain available for all locations through the Purview Unified Audit Log and Search-UnifiedAuditLog, but mailbox-level cross-geo logging gaps should be factored into your audit architecture for any organisation using Microsoft 365 multi-geo.

Using Audit Logs to Investigate a Compromised Mailbox

This is the practical application that makes everything else meaningful. When an Australian business suspects a mailbox has been compromised – a BEC attempt has been discovered, fraudulent emails have been sent, a payment has been diverted – this is the investigation workflow.

Step one: Confirm the scope of access. Use the Purview Audit portal or Search-UnifiedAuditLog to search for all sign-in activity for the affected user across the suspected compromise window. Look for authentication from unfamiliar IP addresses, countries other than Australia, unusual user agents or client applications, or access times inconsistent with the user’s normal pattern. Correlate these with the Microsoft Entra sign-in logs for the same user and period.

Step two: Identify inbox rule changes. Search for New-InboxRule, Set-InboxRule, and UpdateInboxRules operations for the affected mailbox during and before the compromise window. BEC attackers routinely create inbox rules to silently forward copies of incoming emails to an external address, or to delete incoming emails containing keywords like “fraud” or “bank” to conceal their activities. Finding these rules – or evidence that they existed and were subsequently deleted – is a key investigation step.

Step three: Review external forwarding configuration. Search for Set-Mailbox operations that modified the ForwardingAddress or ForwardingSmtpAddress properties. Also check the current mailbox configuration:

powershell

Get-Mailbox -Identity “user@yourdomain.com.au” |

Select-Object DisplayName, ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

Step four: Identify emails accessed (E5 only). If MailItemsAccessed logs are available, search for them during the compromise window. The MailItemsAccessed event records which specific mail items were accessed, the client type used, and the IP address. This allows the investigation to determine the full scope of what the attacker read – essential for assessing whether personal information was accessed and whether the OAIC’s NDB notification threshold is met.

Step five: Identify emails sent by the attacker. Search for SendAs, SendOnBehalf, and Sent message operations during the compromise window. This establishes whether the attacker sent fraudulent emails as the account owner, which is the mechanism through which most BEC payment fraud is executed.

Step six: Check for OAuth application grants. Sophisticated BEC attackers sometimes use adversary-in-the-middle phishing to obtain not just a session token but a persistent OAuth application grant – which gives them ongoing access even after a password reset. Check the Entra audit logs for new application consent grants and review connected application permissions in the Entra ID portal.

Step seven: Contain and remediate. Revoke all active sessions using:

powershell

Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>

Reset the account password, remove any malicious inbox rules found, verify that no external forwarding is configured, review and revoke any suspicious OAuth application grants, and re-enable MFA if it was not active or had been bypassed.

Our email security guidance and incident response resources cover the broader containment and communication steps following a confirmed BEC incident.

Audit Bypass Accounts: An Underappreciated Security Risk

The MailboxAuditBypassAssociation feature was designed to allow high-volume service accounts to operate without flooding audit logs. When an account is configured as an audit bypass account, none of its actions against any mailbox in the organisation are logged – it operates completely outside the audit record.

In a well-managed environment, audit bypass accounts are limited to a small number of specific service accounts with documented justifications, reviewed regularly, and monitored for unusual activity through alternative controls (since their mailbox actions cannot be monitored through audit logs).

In practice, we frequently find environments where audit bypass has been applied to accounts more broadly than intended, or where bypass accounts exist with no documented justification and no owner. The security risk is straightforward: an attacker who compromises an audit bypass account can access any mailbox in the organisation and perform any action without generating a single audit log entry.

Audit bypass accounts should be reviewed immediately in any environment that has not explicitly managed them:

powershell

Get-MailboxAuditBypassAssociation -ResultSize Unlimited |

Where-Object {$_.AuditBypassEnabled -eq $true} |

Select-Object Name, AuditBypassEnabled |

Export-Csv -Path “C:\AuditBypassAccounts.csv” -NoTypeInformation

For any bypass account that cannot be immediately justified and documented, consider whether audit bypass is still required. If the account no longer needs bypass status:

powershell

Set-MailboxAuditBypassAssociation -Identity “serviceaccount@yourdomain.com.au” -AuditBypassEnabled $false

Mailbox Auditing and Australian Compliance Requirements

Privacy Act 1988 (Cth) and the Notifiable Data Breaches scheme. The NDB scheme requires organisations to notify the OAIC and affected individuals when a data breach is likely to result in serious harm. Assessing whether a breach meets this threshold requires knowing what was accessed – which requires mailbox audit logs. A compromise where MailItemsAccessed logs are unavailable due to insufficient licensing, or where logs have expired due to inadequate retention, directly impairs the organisation’s ability to make a reliable NDB assessment. The 2022 Privacy Amendment, which came into force progressively through 2023 and 2024 including a new statutory tort for serious privacy invasions, strengthened the consequences of inadequate data protection. Robust audit logging is part of demonstrating reasonable steps to protect personal information.

ACSC Essential Eight. The Essential Eight does not explicitly mandate mailbox auditing, but it is directly relevant to several controls. The ACSC’s guidance on detecting and investigating incidents implicitly requires the audit infrastructure to make detection possible. For organisations targeting Maturity Level 2 and above, the logging and monitoring capabilities required to demonstrate compliance are significantly aided by comprehensive mailbox audit configuration. Our Essential Eight checklist covers the monitoring and logging controls in detail.

The Cyber Security Act 2024. Australia’s Cyber Security Act 2024, which came into force in November 2024, introduces mandatory ransomware payment reporting and strengthened obligations for critical infrastructure operators. For businesses in scope, the ability to conduct and document an incident investigation – which depends on audit log availability – is directly relevant to the Act’s incident response obligations.

Microsoft 365 Secure Score. While not a regulatory requirement, Microsoft’s Secure Score system awards points for having mailbox auditing enabled and configured to recommended levels. Secure Score is frequently referenced by cyber insurers and Microsoft partners as a benchmark for M365 security posture. A well-configured mailbox audit setup contributes meaningfully to your Secure Score assessment.

For organisations managing the full Microsoft 365 security posture alongside mailbox auditing, our Microsoft 365 security guide and guidance on Entra ID Protection cover the identity controls that work alongside email audit configuration.

A Real-World Example: BEC Discovery and Investigation for a Sydney Accounting Firm

A mid-sized accounting firm in Sydney engaged CodeHyper following the discovery that a fraudulent payment instruction had been sent to one of their clients from what appeared to be a legitimate email address belonging to a firm partner. The client had sent a substantial payment to a fraudulent bank account before the firm’s staff discovered the message had not been sent by the partner.

The immediate question was: how long had the attacker had access to the partner’s mailbox, and what else had they read or done?

When we examined the audit configuration, we found that the firm was running Microsoft 365 Business Premium – a licence tier that does not include MailItemsAccessed logging. The Unified Audit Log was enabled and Exchange Online audit records were present, but the 180-day retention window meant logs from more than six months prior were unavailable.

The available audit records showed the following: a successful authentication to the partner’s account from a Southeast Asian IP address 11 days before the fraudulent email was sent; the creation of an inbox rule that forwarded copies of emails containing the client’s name to an external Gmail address three days after that initial access; and SendAs activity on the day the fraudulent payment instruction was sent.

The investigation could confirm the access window, the forwarding rule, and the fraudulent send. It could not determine with certainty which other emails had been read during the 11-day compromise period – an important gap when assessing NDB obligations, since the firm handles significant volumes of personal financial information.

We remediated the compromise and worked with the firm to upgrade two high-value accounts – senior partners who handle client financial communications – to E5 licences to enable MailItemsAccessed logging for future incidents. We also configured Conditional Access policies requiring MFA for all users and blocking legacy authentication, and set up an alert rule in the Microsoft Purview compliance portal for external forwarding rule creation.

The audit logs that existed were sufficient to support the AFP investigation. The gap in MailItemsAccessed coverage meant the full NDB assessment required a conservative approach – treating the exposed period as a potential personal information access until evidence demonstrated otherwise.

If your organisation is managing a similar situation or wants to assess its current audit posture, contact our team for a no-obligation Microsoft 365 security review.

Mailbox Auditing Configuration Checklist

Use this to assess and remediate your current Exchange Online audit configuration.

Verify baseline configuration:

Organisation-level AuditDisabled confirmed as False via Get-OrganizationConfig
All user mailboxes confirmed as AuditEnabled True
All shared mailboxes confirmed as AuditEnabled True
Audit bypass accounts reviewed, documented, and minimised
DefaultAuditSet status reviewed – mailboxes not on Microsoft-managed defaults identified and assessed

Audit coverage:

Default admin, delegate, and owner action sets verified as current
Additional owner and delegate actions added where not already in defaults (UpdateInboxRules, HardDelete, SoftDelete, MoveToDeletedItems)
MailItemsAccessed availability assessed against licence tier – E5 licences assigned to highest-risk accounts if standard licence is otherwise adequate
Shared mailbox delegate audit coverage verified

Retention:

Current log retention period confirmed (180 days for standard licences, 1 year for E5)
Retention adequacy assessed against BEC detection timeframes and compliance obligations
AuditLogAgeLimit NOT used for retention management – Purview audit retention policies used instead
Custom Purview audit retention policies configured if extended retention is required

Monitoring and alerting:

Purview Audit log search access confirmed for security and IT staff (View-Only Audit Logs role assigned)
Alert policy configured for external forwarding rule creation (New-InboxRule or Set-InboxRule with external forwarding target)
Alert policy configured for mass email deletion events
Alert policy configured for SendAs or SendOnBehalf from unfamiliar locations

Investigation readiness:

Investigation PowerShell workflow documented and tested
Incident response runbook includes Exchange Online audit log search steps
UTC-to-AEST time zone conversion documented for investigators

Frequently Asked Questions

Is mailbox auditing enabled by default in Exchange Online?

Yes. Microsoft enabled mailbox auditing by default for all Exchange Online organisations in January 2019. For any Microsoft 365 tenancy in use today, mailbox auditing is on by default unless it has been explicitly disabled at the organisation level. You can verify this by running Get-OrganizationConfig | Select-Object AuditDisabled in Exchange Online PowerShell. A result of False confirms auditing is active. There is a significant amount of outdated guidance still circulating – including some MSP knowledge base articles – that incorrectly states you must manually enable auditing per user. This was accurate before 2019 but is no longer correct.

What is the difference between Audit (Standard) and Audit (Premium) in Microsoft Purview?

Audit (Standard) is included in all Microsoft 365 E3, F1, F3, and Business Premium licences. It provides 180-day log retention for Exchange Online, SharePoint, OneDrive, and Entra ID records, and covers the standard set of audited activities. Audit (Premium) requires a Microsoft 365 E5 licence or the Microsoft Purview Compliance E5 add-on. It provides one-year default retention for the same record types, access to additional forensic-grade audit events including MailItemsAccessed, higher API bandwidth for SIEM integration, and intelligent insights for Exchange Online and SharePoint Online investigations. Custom retention policies extending up to 10 years are available with the Purview Audit 10-Year Retention add-on.

What is MailItemsAccessed and why does it matter?

MailItemsAccessed is an audit event that records every time a mail item is accessed – read, previewed, or synchronised to a client application. It is the key event for determining what an attacker read during a mailbox compromise. Without MailItemsAccessed logs, an investigation can confirm that a login occurred and that certain actions were taken, but cannot definitively establish which emails were accessed. This is critical for Australian businesses assessing whether a breach meets the OAIC’s Notifiable Data Breach threshold, since the scope of personal information accessed is directly relevant to the NDB analysis. MailItemsAccessed requires a Microsoft 365 E5 licence or the Microsoft Purview Compliance E5 add-on.

How long are Exchange Online audit logs retained?

For organisations on Microsoft 365 E3, F1, F3, or Business Premium licences (Audit Standard), audit logs are retained for 180 days from October 17, 2023 onwards. Records generated before that date were subject to the previous 90-day default. For organisations with Microsoft 365 E5 licences or the Microsoft Purview Compliance E5 add-on (Audit Premium), Exchange Online, SharePoint Online, OneDrive, and Entra ID audit records are retained for one year by default. Custom retention policies can extend this further. The AuditLogAgeLimit mailbox property is no longer used for retention management – retention is now configured exclusively through Purview audit retention policies.

What are audit bypass accounts and are they a security risk?

Audit bypass accounts are user or service accounts for which mailbox auditing has been explicitly suppressed via the Set-MailboxAuditBypassAssociation cmdlet. When a bypass account accesses a mailbox, none of those actions are logged, regardless of the mailbox’s audit configuration. This feature was designed for high-volume automated service accounts. It becomes a security risk when bypass status is applied without documented justification, when bypass accounts are not regularly reviewed, or when an attacker compromises a bypass account – because all their mailbox activity will be completely invisible in audit logs. Review all bypass accounts with Get-MailboxAuditBypassAssociation and disable bypass for any account that cannot be currently justified.

What actions should I check when investigating a suspected BEC compromise?

For a BEC investigation in Exchange Online, the key audit actions to search are: MailItemsAccessed (if E5 is available) to determine scope of email access; New-InboxRule, Set-InboxRule, and UpdateInboxRules to identify forwarding or deletion rules created by the attacker; Set-Mailbox operations that modified ForwardingAddress or ForwardingSmtpAddress; SendAs and SendOnBehalf events to identify fraudulent emails sent as the account owner; and successful sign-ins from unfamiliar IP addresses or geographic locations. All of these can be searched in the Microsoft Purview Audit portal or via the Search-UnifiedAuditLog PowerShell cmdlet.

Can I still use the old PowerShell scripts that use Connect-MsolService to configure mailbox auditing?

No. The MSOnline PowerShell module (which provides the Connect-MsolService, Get-MsolPartnerContract, and related cmdlets) was officially retired by Microsoft in July 2023 and is no longer functional. Any scripts using these cmdlets – including many knowledge base articles from managed service providers that have not been updated – will fail to execute. The current method for connecting to Exchange Online PowerShell is through the ExchangeOnlineManagement module using Connect-ExchangeOnline with Modern Authentication. For MSP partners managing multiple customer tenancies, the current approach uses the Microsoft Graph API or GDAP (Granular Delegated Admin Privileges) with the ExchangeOnlineManagement module.

Does mailbox auditing cover shared mailboxes?

Yes. Shared mailboxes are covered by default Exchange Online mailbox auditing in the same way as user mailboxes. Access by delegates (users with SendAs, SendOnBehalf, or FullAccess permissions to the shared mailbox) is logged under the Delegate sign-in type. The same default audit actions apply, and the same extensions can be made via Set-Mailbox. Shared mailbox audit logs are particularly valuable for access monitoring because they record the specific named user who accessed the shared mailbox, not just that the shared mailbox was accessed.

How does mailbox auditing relate to Australian Privacy Act obligations?

The Australian Privacy Act 1988 and the Notifiable Data Breaches scheme require organisations that experience a data breach likely to result in serious harm to notify the OAIC and affected individuals. A key component of the NDB assessment is determining what personal information was accessed during a breach. Mailbox audit logs – specifically MailItemsAccessed records where available – provide the evidence needed to scope that assessment. Without adequate audit logs, organisations cannot determine the scope of access, which typically requires taking the most conservative NDB interpretation and treating all potentially accessible personal information as exposed. This makes adequate audit configuration both a security control and a compliance obligation for any Australian business handling personal information in Exchange Online.