CLOSE
CLOSE
https://www.sikich.com

New Capability in Email Breach Investigations Within Office 365

Dealing with account breaches is never an enjoyable activity. It typically gets even more sour when you can only get limited information on what happened. During an account breach investigation, the Office 365 Audit Log is one of our most valuable tools to review all types of activity (pre- and post- incident). In the review of mailbox activity, there have been some cases where there is a need for a much more thorough investigation for specific items/actions. For that level of detail, we would need to have mailbox auditing enabled. Historically, we have had to manually enable that feature on mailboxes. Since this wasn’t by a default setting/policy, we had to rely on internal processes to enable this on any new mailboxes that were created. Thanks to a rather recent change by Microsoft, mailbox auditing is now enabled by default.

With mailbox auditing turned off, we could only get rudimentary details on what happens within a mailbox post breach. Now that this feature is enabled by default, we at least have the capability to find out in more detail what was done by the bad actor.

How do you find out if you have this feature enabled or not? Sadly, this is where it gets somewhat technical because finding out that piece of information cannot be done through any of the web portals. You can only obtain that detail through a remote PowerShell connection.

Under the assumption that you already know how to make a remote PowerShell connection to Office 365/Exchange Online, here is how you can find out if this default change has already been made in your tenant.

How to Check if a User Has Mailbox Auditing Turned on

To find out if mailbox auditing has been enabled on your tenant, run:

Get-OrganizationConfig | Select AuditDisabled

Office 365 email breach investigation

From your result:

False = Auditing enabled for all accounts

True = Auditing disabled for all accounts

To find out if auditing is enabled on a specific mailbox, run:

Get-Mailbox -Identity <account address> | Select Audit*

Office 365 email breach investigation

From your result:

AuditEnabled = True, we can confirm that auditing is indeed enabled.

AuditLogAge Limit = 90, we can confirm that we are keeping audit logs for 90 days.

Audit:Admin/Delegate/Owner, we can confirm which audit actions are setup for the different permission levels.

Once Auditing Is Enabled, Now What?

The next logical question is, great, now that I have this enabled (or confirmed that it is enabled), how do I use this information? At least for this part we can return to a web portal. We turn to the Security & Compliance Center’s Audit Log Search tool for this information. Once mailbox auditing is enabled, under the activities, we can now search for things like: “Update inbox rules from Outlook client,” or “New-InboxRule Create inbox rule from Outlook Web App.” While there are other noteworthy items to search on, I highlighted the two inbox rule items because they are a common telltale sign that someone is doing something within the mailbox to hide tracks.

Office 365 email breach investigation

After running our search and filtering (as necessary) our results, we can get a much clearer picture of what transpired.

If you have any questions about mailbox auditing, don’t hesitate to contact us at any time!

This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.

About the Author