Recently there have been some big changes in Microsoft auditing, especially with the Unified Audit Log (UAL). It all started with a blog (link) by Microsoft that laid out plans for the future of auditing. This was in the wake of the famous Storm-0558 attack, you can read the official write-up here. One of the positive things that came from this incident is that Microsoft promised some significant changes to the UAL. In this blog we want to highlight the status of some of these changes and also some issues we found.
Since you're interested in the UAL, you might be interested in our training which we offer OnDemand and at selected live events.
The basics
Before we go to far, if you're reading this you probably know that the UAL is a critical evidence piece for investigations in M365 environments, whether it's a standard BEC case or an APT. Another important fact is that the UAL is on by default for a few years now. Unfortunately, it happens in some of our cases as well that older tenants don't have the UAL enabled. If you want to check the status, open PowerShell and login with:
Connect-ExchangeOnlineManagement(this requires the Exchange Online Management PowerShell module)
Run the following command:
Get-AdminAuditLogConfig |Select-Object -ExpandProperty UnifiedAuditLogIngestionEnabled
If it's disabled, please enable the UAL with:
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
One last thing before we get to the interesting stuff is licensing. Generally speaking you'll encounter either Audit (Standard) or Audit (Premium) licenses, the differences are shown in the table below:
Change is coming
A lot is changing and has already changed in regards to the UAL, the most important changes:
- Default retention increase from 90 days to 180 days for Audit (Standard)
- New (Premium) logging available for Audit (Standard) environments
- Audit Search Graph API will be released
Default retention
One of the worst feelings as an investigator is when you find out that initial access happened outside of the default retention period. Well it might happen again, however the retention right now for the UAL has been increased from 90 days to 180 days. We're often critical of Microsoft, but this is just great and nothing to complain about. Getting 6 months of logging for free is great and it aligns for instance with Google Workspace logging that's also available for 6 months. One thing to keep in mind is that we've not found a good way in PowerShell to check the retention period of the UAL. For example if we run Get-AdminAuditLogConfig we can see that the retention for Admin Audit logging is 90 days still.
However this is not the retention period for the UA, because if we search for data older than 90 days let's say between November 1 and November 2, 2023 I will have data as shown below:
Keep in mind that the retention change has been implemented since October 17 2023, so from that moment forward you have 6 months of logs retained. Logs before October 17 aren't retained for 6 months. This is also the official statement of Microsoft, so when doing an investigation keep that date in mind.
As for your acquisitions, you should be using the Microsoft-Extractor-Suite which supports any retention. You can simply select the date/time period for your acquisition, for now the default acquisition period is 90 days.
Premium audit logging
We are more than excited for this change and to be very honest it's long overdue. With this change the following events will be added to the UAL for everyone.
While some of these aren't that interesting from a DFIR perspective we would like to highlight the following:
- MailItemsAccessed
- SearchQueryInitiated*
- ChatCreated
MailItemsAccessed
We can't even count the number of BEC cases where we couldn't establish what emails were accessed by the threat actor because our client didn't have a Microsoft E5 license with Premium audit logging. The MailItemsAccessed operation keeps track of what emails were accessed and or synchronized by a user. This will help answer the question "What emails were accessed by the threat actor?"
SearchQuery
This operation has two flavours SearchQueryInitiatedExchange and SearchQueryInitiatedSharePoint they will be generated when a user searches through SharePoint or Exchange and includes the search term that was used. This operation can be helpful in determining what data or emails the threat actor was interested in.
ChatCreated
External phishing via Teams messages has been the hype for some time now and tools like TeamsPhisher (GitHub) it's trivial to exploit. From a forensics perspective one of the operations that's recorded in the UAL when this tool is used is the ChatCreated operation. As such the availability of this operation is welcome for investigators.
As for the timeline of this change according to the official roadmap the rollout will start in June 2024. We can't wait for the logs to be available and we're sure this makes lives easier for DFIR people and victims across the world.
Graph API for the UAL
It is happening.... The UAL will be available for acquisition through the Graph API, hopefully this speeds up the acquisition significantly. Its already sort of implemented in the Graph Beta. It will be part of the auditLogQuery resource, you can take a look at the documentation here. The way you have to work with the API to get data is:
- (Optional) List records use this to see what logs are available.
- Create auditLogQuery, create a query to retrieve data that you want to acquire
- Get auditLogQuery, return the data from the log query
At this moment in time it's in beta stage, you can test it. For instance go to Graph Explorer and run the following query:
https://graph.microsoft.com/beta/security/auditCore/auditLogQueries
You'll receive an error like this:
So it doesn't seem to be working and another user reported the same behaviour. However, if you're part of the special group that Microsoft gives early access to, this might already work. Regarding the timeline, this change should be ready and rolled out in March 2024 most likely it will stay in beta stage for a while.
Search-UnifiedAuditLog issues
All of the above sounds amazing right? We want more logs and longer retention. However, one of the main problems right now is the PowerShell cmdlet that enables us to acquire all the logs, which is Search-UnifiedAuditLog. Our tool the Microsoft-Extractor-Suite leverages the Search-UnifiedAuditLog cmdlet to acquire the data. Over the years we have heard from multiple users about differences in the number of logs returned with our tool and the Purview portal or even when directly accessing Search-UnifiedAuditLog. However, we have never been able to reliable pinpoint this problem. Recently there was a really good blog by Tony Redmond who had experienced the same issue. The situation at the moment is that you can't completely trust what gets returned from the Search-UnifiedAuditLog cmdlet which is very bad from a forensics and IR perspective. It gets worse, because there's no alternative we can't use the Management API to get the data as it has very limited history (7 days) and don't get me started on the Purview portal it is useless for larger datasets as the export limit is 50k records.
Well there might be light at the end of the tunnel, we were alerted by one of our users that there was a new parameter HighCompleteness (source).
The HighCompleteness switch specifies completeness instead performance in the results. You don't need to specify a value with this switch. When you use this switch, the query returns more complete search results but might take significantly longer to run. If you don't use this switch, the query runs faster but might have missing search results.
As far as we know this wasn't communicated, but we suspect this parameter is an effort to make sure that when you run this cmdlet that all data will be returned. There's a lot to digest from this text. If we start at the end Microsoft is basically saying, if you don't use this optional switch your data might have missing search results. Which is maybe the closest we get to confirmation that this cmdlet isn't reliable. The other important word is 'completeness' maybe a native English speaker can help us out, but after reading this we're still not sure that if we use this parameter we will get all results? It says 'more complete search results' so we suspect Microsoft doesn't want to guarantee that all data will be returned. This is not great there are forensic investigations and legal cases that rely (partially) on this data source and we can't rely on the completeness of it. We have tested with the HighCompleteness switch and it sometimes work, but it's not reliable you will receive errors or it will just hang for ages.
Another undocumented parameter that was added is LongerRetentionEnabled.
We have some theories on what this flag will be used for, one is that it's to accommodate for the increase in retention from 3 to 6 months. The other option is that this cmdlet can also be used to acquire data from tenants with (premium) auditing which allows for a retention up to 10 years. Anyways we will keep monitoring this as well..
The future
The future of the UAL is exciting, between the increase in retention and the addition of more valuable events to the ability to acquire the data much via the Graph API lots is happening. However, in the meantime be aware of the reliability issues of the Search-UnifiedAuditLog when doing acquisitions and investigations based on the UAL. One thing we haven't discussed which is really interesting is the EnrichedOffice365AuditLogs which has been available in Entra Diagnostic settings for months. We will publish some new research on this later.
If you enjoyed this content, you might be interested in our training which we offer OnDemand and at selected live events.
Sign up for our newsletter to receive the blogs in your inbox right away.