More on entries from other tenants visible in the Unified Audit log

An year ago, I blogged about some suspicious events in the Office 365 Unified Audit log, that seemed to correspond to some “Unknown” principal. The culprit turned out to be users clicking on sample links to files/sites hosted in my tenant’s SPO instance, which I’ve posted on various blog sites and forum posts. Since then, Microsoft has made some changes to the way events are being presented in the Unified audit log, and those “unknown” entries seem gone for good.

Now, it’s time for another round of the same, this time with Exchange Online being the culprit. When doing my regular review of the Unified Audit log earlier this week, I spotted few entries that puzzled me – a user from a different tenant was being shown as successfully logged in, with no additional related events/actions. Even more interesting was the fact that said events were nowhere to be found in either the Azure AD sign-in logs or the CAS audit trail. Only the Unified Audit log had such events, and they were all linked to the id of the Exchange Online service principal, 00000002-0000-0ff1-ce00-000000000000. Here’s a sample event:

As with our previous SharePoint-related investigations, the next step I took was to look at the extended event information for those entries. As expected, the ActorContextId value did not match the one for my tenant, so this was again a case of someone trying to access a resources in a different tenant. The user IDs visible form such entries most definitely did not correspond to a Guest user in my tenant, so I figured this is just an “updated” view of all the “Unknown” entries I’ve dealt with previously. Surprisingly though, I wasn’t able to see any of the SPO related entries in the log.

More importantly, while I had some understanding on how a user can generate such entries for SharePoint Online, the case of Exchange Online was a bit more puzzling. Yes, we do have a web-based endpoint for Exchange Online and we can use it in order to replicate the SPO behavior. I can simply login to my tenant, then try to access a mailbox from a different tenant via direct link such as https://outlook.office365.com/owa/user@othertenant.onmicrosoft.com. Such events have never been visible in the audit logs however, and a quick test on my end confirmed that this method indeed didn’t generate any new entries.

So I continued to look at the extended event information for additional clues, until I spotted the value of the ApplicationId, namely a0c73c16-a7e3-4564-9a95-2bdf47383716. You will not find this id listed anywhere in the Azure AD portal or PowerShell, however from my previous fiddlings with the ExO MFA PowerShell I was well aware that it corresponds to the “Microsoft Exchange Online Remote PowerShell” application. Knowing that, it was easy to reproduce the workflow that results in generating such requests. It was all due to users copy/pasting the PowerShell code samples from the above article, without changing the tenantID on the first line.

This in turn results in the user getting a token with incorrect issuer value, as shown below. While Azure AD issues such tokens in the first place is a different question, especially considering the scope (level of permissions) being issued as part of the token.

So, another mysterious entry in the Unified audit log got explained. As an added bonus, here’s also an explanation about some “random” events being generated from US-based IP addresses, such as the ones below:

All of these are events corresponding to running the PowerShell script sample for fetching events from the O365 Service Communications API, as detailed in this article. All the events were initiated from my home PC, located in Sofia, Bulgaria, and using a different IP address. Yet we only end up seeing the “proxied” requests in the log, bouncing off some server in Chicago. Not confusing at all, thanks Microsoft 🙂