The Importance of the Office 365 Audit Log for IT Forensics

Microsoft DART Likes the Office 365 Audit Log (Unified Audit Log)

On September 26, Microsoft’s Detection and Response Team (DART, aka the cybersecurity team you never want to meet) published an article on the Security, Compliance, and Identity blog called Forensic artifacts in Office 365 and where to find them. It’s a nice article that captures the standard and optional (requiring extra configuration or licenses) flows of data captured for Azure AD sign-in events, Azure AD admin events, and Office 365 activities (Figure 1). This data is of great help to forensic investigators as they attempt to understand what happened in cybersecurity incidents.

Regular readers of my written work or those who’ve heard me speak at conferences are well aware of my high regard for the Office 365 audit log. It’s a fantastic source of information about what happens inside a tenant and I believe that every administrator should be familiar with how to retrieve information from the audit log. I keep on coming back to the audit log to see what data shows up there for new features like reactions to Teams messages. It’s also my go-to place to find in-depth information about actions that might affect the tenant, like potential illicit consents.

Moving Office 365 Data to a SIEM

The downside of the Office 365 audit log is that data doesn’t stay there for very long. Even tenants with the Office 365 E5 plan have access to only 365 days of information. For Office 365 E3, the audit log only stores 90 days of information. In addition, Office 365 E3 tenants must enable auditing for every mailbox to make sure that Exchange Online sends mailbox events to the audit log. That’s a gap which I hope Microsoft closes soon.

A SIEM is a good place to hold audit data for longer periods. As Microsoft notes, it’s possible to ingest Office 365 audit data into Microsoft Sentinel. Not all data flows through as the connector used to transfer data to Sentinel is particular about the events it chooses, so that’s something to watch. Nevertheless, Sentinel is a good place to keep audit data if you use Azure.

As to other SIEM platforms, many PowerShell examples exist demonstrating how to use the Search-UnifiedAuditLog cmdlet to fetch audit events  (here’s an example). Once you have the data, it’s not hard to send them to a repository. Some SEIMs have more sophisticated ingestion mechanisms. For example, Splunk uses a registered Azure AD app to fetch audit data and bring it to its repository.

Poor Search Performance

I use PowerShell whenever I need to search the audit log. I have never liked the GUI Microsoft built for audit log search. It has always been unwieldly and inflexible, not to mention slow. Its sole benefit is that the GUI exposes some of the important information stuffed in the AuditData payload in audit records.

I was therefore taken aback by the enthusiasm shown about the new Audit search GUI (preview). According to Microsoft, the new GUI offers the following improvements:

• Search jobs initiated via the compliance portal UI no longer require the web browser window to remain open in order to complete. These jobs will continue to run even after the browser window is closed.
• Completed search jobs are now stored, giving customers the ability to reference historical audit searches. These search jobs are presented in the UI, listing the search name, search job status, progress %, Number of results, Creation Time, and Searched by.
• Each admin Audit account user can have a maximum of 10 search jobs in progress at a time.

I tried the new GUI with a very simple search looking for events for a single operation (someone changes a sensitivity label for a document) for the last 27 days. This search took less than three seconds by running the Search-UnifiedAuditLog cmdlet in PowerShell, but required 9 minutes and 24 seconds through the new search (Figure 2). This kind of performance is not usual in my experience.

Here’s the equivalent search in PowerShell:

Measure-Command { [array]$Records = Search-UnifiedAuditlog -Operations ComplianceSettingChanged -StartDate 1-Sep-2022 -EndDate 27-sep-2022 -Formatted -ResultSize 5000 }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 2
Milliseconds      : 470
Ticks             : 24701589
TotalDays         : 2.85898020833333E-05
TotalHours        : 0.00068615525
TotalMinutes      : 0.041169315
TotalSeconds      : 2.4701589
TotalMilliseconds : 2470.1589

Some overhead is expected to create and process search jobs in the background but this degradation in performance is extraordinary when you consider that both methods interrogate the same data source. You have to do more work with PowerShell when an audit search returns events, but anyone who’s worked with the event log will have that process well defined and understood, so the advantage of being able to view event details through the GUI (Figure 3) is probably only appreciated by those unfamiliar with the audit log.

Slow Interfaces are Unusable

The new audit search GUI reminds me about redesign of the content search interface, which also disappointed with its slowness and buggy nature. Microsoft introduced that redesign in May 2021 and it’s still slow. I hope that they manage to do a better job as they bring the new audit search from preview to general availability. If not, I doubt I would ever use the new audit search interface.

Microsoft DART considers that the new interface makes “large-scale data collection much simpler and more reliable.” However, that statement is softened considerably by saying that their “go-to approach here is to use PowerShell to extract the data we need.” I couldn’t agree more.

---

Learn more about how Microsoft 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.