Correlating events becomes easier as Microsoft adds ‘SessionID’ to the audit logs in EXO

Yesterday, Microsoft announced a new capability in Exchange Online which adds the ‘SessionID’-field to the existing audit logs in Exchange Online. Audit logs are a useful feature to go through and look at what actions have been performed on a mailbox at any given time. The events that are exposed through the Audit Logs are a great source way to correlate events and detect suspicious behavior – whether its for a legitimate user or through a potentially compromised account.

Many (security) solutions, including Microsoft’s own, use the information from the Audit Logs to correlate events and determine whether or not specific activity should be flagged as suspicious for further investigation. When such investigations happen, it’s sometimes hard to distinguish which actions of an account are safe and which ones aren’t. Consider the following example. I re-used the data from the announcement, to illustrate the point. The following data shows a series of (chronological) events, without the Session ID:

Without more information, these actions look like something a real user would do too: authenticating to the mailbox (twice), and performing some actions like removing data and adding an Inbox rule. Unless there is a high amount of (infrequent) actions that immediately stand out from the ordinary, it is really hard for an administrator to determine whether the above data warrants further investigation or not.

Now, let’s look look at the same data with the SessionID:

Again, the same events are visible, but we can now see that various actions have been performed in different sessions. This doesn’t necessarily point to malicious behavior. However, when different sessions are active at the same time, my attentions would be triggered more easily. Of course, the administrator will still have to verify with the user to identify the nature of the actions. But, by doing so, the admin might learn that the user did not create Inbox rules, nor did the user add any mailbox permissions.

At this point, having the SessionID has another benefit: it allows you to query the Audit Logs with the Session ID and list all actions that were performed within the same session, like shown in the table below:

Disabling/Blocking Basic Auth

This all seems good news, but what’s the caveat you might ask? As per announcement, sessions which were authenticated through Basic Auth will not have the SessionID information available because the information in only logged when modern authentication is used. Personally, I think this is great, as it is yet another reason to get rid of Basic (legacy) authentication. On the other hand, and the sad reality, is that many organizations are still using some form of legacy authentication today, not in the least through protocols like POP3 and IMAP.

Ideally, the SessionID (or similar) information would have been available for legacy auth as well. Especially because these non-modern authentication protocols do not support MFA and, hence, accounts using legacy auth are more susceptible to attacks/compromise.

Conditional Access to the rescue?

There are various ways to disable Basic Authentication in Microsoft’s online services. One way is to use Conditional Access, where you can define a set of policies that apply to different user (groups) in your organization. As such, you can be very granular as to whom you allow to use legacy auth and to what service.

Specifically for Exchange Online, you can use the recently-released Authentication Policies, where you can basically do the same, albeit just for Exchange Online.

Is auditing enabled?

To access the audit logs for a mailbox, auditing must be enabled first. Although Microsoft recently announced it would enabled mailbox audit logging for all users by default, older tenants might still have mailboxes that aren’t audited. To check whether auditing is enabling, connect to Exchange Online with PowerShell and run the following command(s). To get a list of all users and whether or not auditing is enabled, run the following command:

Get-Mailbox -ResultSize Unlimited | Select Name,AuditEnabled. 

To (re-)enable auditing, you would run the following command. More information on the process is available here.

Set-Mailbox <mailbox> -AuditEnabled $True"

Lastly, to verify if your tenant is configured to enable Mailbox Audit logging by default, run the following command:

Get-OrganizationConfig | Select AuditDisabled

Reading the audit logs

Before you get all hyped up about this feature, you must understand there are a few limitations too. First of all: to use the audit logs on a daily basis as means to improve your security monitoring and detection capabilities, you will need a mechanism (often in the form of an external tool or feature) that captures the audit events and performs an initial triage on them. This can be an external SIEM solution or – if you have the necessary licenses – Microsoft’s Cloud App Security.

Even though the audit logs can be access through PowerShell, doing so is merely effective for ad-hoc investigations in my opinion –not in the least because querying the audit logs for a large number of mailboxes can be slow. Additionally, audit logs are only kept for a (limited) amount of time. If you have E3 licenses, they are kept for 90 days. Audit logs for E5 licenses are kept for 365 days. Either way, you’ll have to take this into consideration if you have a requirement to be able to go back further in time than your current built-in retention period.

Increasing your tenant’s security

All in all, this is a small but important step towards increasing your organization’s security posture and making it increasingly more easy to detect (and thus react to) attacks. Security is an important topic and one of our core focus areas at The Collective. Feel free to reach out to us to understand how we can help you become more secure in Office 365.