Good UAL Hunting
In our last blog on this series, Forensic artifacts in Office 365 and where to find them, we spoke about where data relating to Office 365 can be found and which endpoints can be used to effectively conduct a cybersecurity investigation. In this blog post, we will be taking a deeper dive into one of those data sources, the Office 365 Unified Audit Log (UAL). This is a key data source in any cloud investigation because it contains a record of all the activity that has occurred in Office 365 and Azure Active Directory: whether a threat actor adds a new application secret, sets up a mailbox rule, accesses an email message, or joins a Teams call, it will be logged in the UAL. If we use this resource correctly, it can help us build a full story of a threat actor’s activity in Office 365.
A UAL study
When reviewing any forensic data, it is first important to understand what the data looks like and how it is structured. Without this awareness, it’s easy to make assumptions or incorrect deductions about the artifacts.
The Unified Audit Log is an amalgamation of log data from multiple products, and the resulting massive data set requires some categorization to help with filtering and triaging. Data in the UAL is split into three categories: workloads, record types, and operations. When searching the Unified Audit Log, filtering using these categories can help triage this massive data set.
- Workloads – Top level categorization based on products. Examples include AzureActiveDirectory, Exchange, OneDrive.
- Record Types – Categorization used to group operations logically within a product. Examples include ExchangeAdmin, SharePointFileOperation, MicrosoftTeams.
- Operations – The individual event that occurred. Some common examples are MailItemsAccessed, FileDownloaded, UserLoggedIn. There are over 3,500 different operations in the Unified Audit Log, most of which are documented in Audited Activites. Some of these operations, such as SearchQueryInitiatedExchange and MailItemsAccessed, are dependent on your Microsoft Purview Audit (Premium) licensing.
Looking at the raw output from Search-UnifiedAuditLog (a PowerShell cmdlet for accessing raw UAL data), most of the interesting data in a single log entry is in a field called ‘AuditData’. This makes sense considering that the Unified Audit Log is a collection of log artifacts from multiple disparate products in Office 365. Each product has its own log format and structure, and AuditData is a way to provide an open field for each product group to populate data into. The other fields are where the more general Unified Audit Log fields live, such as CreationDate, RecordType, and Operations.
The AuditData field can vary wildly in schema and content across different products. What is in an ExchangeAdmin entry will be very different to a MicrosoftTeams entry. This means that some analysis and parsing of data is often needed to bring the picture into focus.
One other thing to consider is that not all Unified Audit Log operations are created equal. Some are commonly seen in investigations, while some are rarer. It is important to keep an open mind and remember that all forensic artifacts have the potential to be forensically interesting! With that said, some examples of the more commonly seen operations include:
- UserLoggedIn
- MailItemsAccessed
- FileDownloaded
- Add service principal.
- Update user.
- Consent to application.
- Update application - Certificates and secrets management
- Set-MailboxFolderPermission
- New-InboxRule
This list gives a flavor of the adversary tactics, techniques, and procedures (TTPs) that Microsoft Incident Response (formerly DART/CRSP) often hunts for in cloud investigations. Note that the varying naming conventions of these operations reflects the actual naming convention in the UAL. Some have periods at the end while some have spaces – yet another reminder that the Unified Audit Log is a collection of data from disparate sources.
One barrier to Office 365 hunting is the sheer amount of data available; to remedy that, start by following identity data and jump off to additional pivots from there. After all, there is no point in hunting for Exchange Online activity if the threat actor never signed into Exchange Online, so use the identity data to tell you where the threat actor has been and pull threads from there. Another thing to keep in mind is that the Unified Audit Log will only show interactive logins. Since non-interactive and service principal logins are just as pertinent to an investigation, do not rely solely on the Unified Audit Log for identity investigations.
Time to hunt!
As mentioned in the previous blog on this subject, Unified Audit Log data can be accessed in multiple ways, each of which has its pros and cons. Let’s go through this in more detail.
Native access
The data in its most raw form can be gathered using PowerShell, more specifically, the ‘Search-UnifiedAuditLog’ command, part of the Exchange Online PowerShell module. It allows filtering by time, operations, record types, free text, IP address, User Principal Name (UPN), and site URL. Multiple values can be provided for some of these filters and, when combined, they form a single search. One example of this would be:
Search-UnifiedAuditLog -StartDate 2022-05-01 -EndDate 2022-06-01 -Operations New-InboxRule
This query would return all events where a new inbox rule was created in the month of May 2022. Providing a UPN or IP address would filter this even further. Keep in mind that if no time is specified in the date, the search will default to 00:00:00 of that day.
There are some limitations to searching this way, the primary one being that only 5,000 results can be returned at one time. If a wide date range is being used or an entire record type is being searched, you will likely run into this limit. To avoid this, use the script provided on the Use a PowerShell script to search the audit log Microsoft Learn page to return multiple sets of 5,000 results, up to a total of 50,000. This script has the added benefit of being able to output the data to a CSV file for further analysis.
There is also a graphical option available in the form of the ‘Audit New Search’ tool in the Microsoft 365 Defender Portal. This tool allows a search to be queued and the results downloaded when completed, and the search can be filtered by time, activities (read: operations), record types, free text (i.e., keyword search), users, and sites. This portal can be useful when searching for a particular activity listed in the ‘Activities’ drop-down or when searching for all activity from a particular user. It is not as fast as using Search-UnifiedAuditLog but is more accessible for larger scale data collection.
Defender for Cloud Apps
Unified Audit Log data in Defender for Cloud Apps is an excellent solution for UAL hunting and often a go-to for Microsoft Incident Response, as it includes data enrichment and as long as the correct licensing is available, customers face no storage costs for data ingestion or retention.
Defender for Cloud Apps integration with Office 365 is performed through the Investigate>Connected Apps page. The Office 365 connector uses the Office 365 Management API to pull data. It can even be enabled in the middle of a live security incident: the API holds a buffer of 7 days worth of Unified Audit Log data that will be pulled down once the connector is enabled, providing access to some historical data.
When connecting or editing this app connector, there is the option to enable or disable particular components of the connector. For Unified Audit Log integration, the key option is ‘Office 365 activity’. Make sure this option is enabled to pull Office 365 data through to this portal.
Once Defender for Cloud Apps is integrated with the Unified Audit Log, there are two different hunting options: the Activity Log and Advanced Hunting. The Activity Log in the Defender for Cloud Apps portal shows a chronological sequence of different events from every connected application. Filtering options for the Activity Log change depending on the timeframe you are looking at. For 30 days back, there are many filters to pivot on, including advanced filters such as ‘registered ISP’, ‘device’, and ‘user agent string’. For 180 days back, the maximum retention period, the filtering options are more limited and the last 30 days can no longer be filtered on. This set of data is accessible via the 'Investigate 6 month back' option on the page, highlighted in Figure 5.
For the 180 day historical data, filtering options include App, Location, Name, IP Address, Activity Type (read: Operation), and Activity ID (see Figure 6 below). This data is no doubt still useful, but it is not as detailed as the < 30 day filtering.
Clicking into some of these events will reveal some of the data enrichment that Defender for Cloud Apps offers. For example, the ‘Show Similar’ option can be used to pivot on activity, user, IP, location, and time. There is also enrichment data from the IP address; in Figure 7 below, it shows that the access is coming from a Microsoft Azure IP (likely a VM hosted in Azure).
The ‘User’ tab at the top of the entry leads to a page with detailed information and metrics regarding the user account permissions, recent activity, and more.
The IP address tab gives similar enrichment information, allowing quick understanding of the scope and use of this IP address in the organization.
In addition to the Activity Log, another method of accessing the Unified Audit Log data via Defender for Cloud Apps is by using Advanced Hunting in the Microsoft 365 Defender Portal. There is a table called ‘CloudAppEvents’ that contains the last 30 days of Unified Audit Log data, but it is only available if the Defender for Cloud Apps Office 365 activity connector is configured.
Advanced Hunting is powerful because it allows for querying via the Kusto Query Language (KQL). For example, here is a simple query to grab a count of all the different admin operations from the last 30 days:
CloudAppEvents
| where Timestamp > ago(30d)
| where IsAdminOperation == '1'
| summarize count() by ActionType
Below is a more complex query to hunt for files downloaded per IP address. This query also extends data from the AuditData field (called ‘RawEventData’ in Defender for Cloud Apps) to new columns to provide a list of the file names downloaded from each IP address:
CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType == 'FileDownloaded'
| extend SourceFileName = RawEventData.SourceFileName
| extend SiteUrl = RawEventData.SiteUrl
| summarize count(), make_set(SourceFileName), make_set(SiteUrl) by IPAddress
These queries can also be saved for repeated use. One thing to keep in mind with Advanced Hunting is that it shows the raw output from the Office 365 Management API and, as a result, does not return the enrichment data from Defender for Cloud Apps.
Sentinel/SIEM
Unified Audit Log data isn’t just limited to analysis within the Microsoft 365 product suite: APIs and connectors available can also be used to ship this data off to a SIEM of choice. Check out the Detection and Response Teams blog series on using Microsoft Security APIs for Incident Response for more information on this subject.
This log shipping is reliant on the Office 365 Management Activity API. Many popular SIEM solutions have connectors for simple integration of Office 365 data, and Sentinel is no exception. In Microsoft Sentinel, a multitude of connectors exist for integration with Microsoft 1st party products. The best combination for Office 365 activity is the Office 365 connector and the Azure Active Directory connector. This will ensure that all Azure AD, Exchange Online, SharePoint Online, and Teams data is being pulled into Sentinel. Additionally, each connector has multiple pre-created Workbooks (for data visualization), Queries (for hunting), and Analytics Rules (for alerting), simplifying the data wrangling involved in investigations.
A special mention also goes to the Microsoft 365 Defender connector for Sentinel (currently in preview) which has a wide range of additional data collection, including alerts, incidents, and advanced hunting events.
That’s a wrap!
Hopefully this article has helped tell the story of the most important log source available in Office 365. The Unified Audit Log is complex and can be challenging to navigate, but for an investigator it offers rewards that are often worth the effort. Microsoft Incident Response has solved many an investigation using this rich data source, and with that experience, we can continue our mission to inform and educate our customers, putting this power into their hands. We will surely learn more as time goes on, so keep an eye out for more blogs detailing our cloud-hunting techniques and methodology.