Office 365 audit logging
It’s important to enable audit logging for o365 even if you are not monitoring them actively. Atleast if you get hacked there’s logging to investigate :). The audit log is not always enabled by default, it seems to rely on license levels. However there are some important things to take into consideration.
You can enable the unified audit log and be done. However there are some things to take into consideration. Especially when it comes to mailbox operations and logging. Office 365 audit logging can be tricky to manage. There’s some things you need to be wary of when relying on the o365 logging. Essentially we need to make sure Unified Audit log is enabled and the mailbox audit settings are set correctly.
Unified Audit log
The unified audit log is a combination of logging from SharePoint, Exchange Online, Teams and more. If you use o365 just make sure to enable it. It can be checked using “Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled”. Enabling can be done via: “Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true”
Make sure you can detect any modifications to the UnifiedAuditLogIngestionEnabled setting.
Mailbox Audit settings
Mailbox Audit settings describe which operations on the mailbox are logged. Unfortunately we cannot set a standard set of operations that are logged for every mailbox. This forces the administrator to set them per user. After a new mailbox is created we need to set which mailbox operations are logged. Which audit operations are set seems to depend on the license level (business vs e3 vs e5).
Let’s say we create a new user the following auditoptions are set:
The different operations are documented here:
There are three different types of operations:
- Owner: The owner of the mailbox.
- Admin: Mailbox accessed via Content search, eDiscovery or Microsoft Exchange Mapi Editor.
- Delegate: Sendas of sendonbehalf users actions or an admin who’s using the mailbox.
After creation of a new user some operations related to the user’s mailbox will not be logged by default. The following are interesting:
- Owner: MailboxLogin
- Delegate: Folderbind
- Admin: Folderbind
Folderbind: “A mailbox folder was accessed. This action is also logged when the admin or delegate opens the mailbox.”
Mailboxlogin: “The user signed into their mailbox.”
If we dont change anything and log into a mailbox and create a mailbox rule the following logs are created:
If we enable the MailboxLogin operations we can see the login operation and perfoming another, unrelated, action:
Note: keep in mind that mailboxlogins != azureAD logins. So accessing other resources then mail will not be logged by these settings. Those logs are paywalled by AzureAD p1/p2 licenses. AzureAD can be bought separately but is also included in e3/e5 licenses.
Subverting logging
Attackers can try to subvert logging in order to obfuscate their actions.
Unsetting auditoptions to prevent logging
It’s possible to unset all audit operations for a specific mailbox. Doing so will result in less logs however not all log operations will be hidden. After setting every audit option to zero we can still see mailbox rules being created and auto forwarding being set.
“Set-Mailbox -Identity testrik@kelder.io -AuditEnabled $true -AuditOwner @() -AuditDelegate @() -AuditAdmin @()”
We can verify the audit settings are set to nothing:
The mailbox login is not logged, but rule creating and forwarding being set on the mailbox are. It seems there’s always a default set of items being logged. It’s not quite clear to me from available documentation what is in that default set, but I guess it’s based on the type of license the user is assigned.
Set-MailboxAuditBypassAssociation
Mailbox Audit Bypass according to the documentation should prevent activities from being logged. It’s a technique that has been described in the BlackHat talk: “Cloudy with a chance of APT”.
I tried setting the bypass on our test mailbox. Surprisingly, Audit logging kept coming in. I’ve asked one of the authors of the talk and it seems they’ve seen similar behavior. Still it’s smart to keep track of the bypass association..
Attic and logging
Within the Microsoft365 module in Attic a tenant is monitored for different logging factors including the capability to automatically fix issues (pending user approval). In relation to audit logging we monitor the following
- Is Unified Audit log enabled
- Mailbox audit settings correct
- Audit logging coming over in the past 24hs.
- Are there mailboxes with Auditbypass enabled
The following fixes exist:
- Enable unified audit log
- Correctly set mailbox audit settings
Want to know what it is we check and fix? Check our checks and fixes here. Or buy a subscription here.
Future work
- Detect license downgrade as described in the BlackHat talk “Cloudy with a Chance of APT” By Doug Bienstock and Josh Madeley. https://www.slideshare.net/DouglasBienstock/bhusa-2021-cloud-with-a-chance-of-apt
- Figure out if AdminAuditLogExcludedCmdlets actually works, would be shitty to miss Set-MailboxRule or something like that.
- Create a fix to unset any Auditbypass. Not hard: Get-Mailbox -ResultSize Unlimited | Set-MailboxAuditBypassAssociation -AuditBypassEnabled $false
- currently working on an automated rollout of Sentinel including the OfficeActivity/AzureActivity connectors
- Figure out if setting AdminAuditLogEnabled to false is possible and results in no logging
- Investigate what is logged once a Graph app interacts with mailboxes