Login events in the Office 365 Audit log for the “Unknown” principal

Reviewing the Office 365 Audit log is one of the recommendations you will often find in any resource that focuses on Security and compliance. One such example is the Securing privileged access for hybrid and cloud deployments in Azure AD article. Similarly, the Secure Score tool will award you points if you do a weekly review of the Audit data as well as any related reports. Different whitepapers will feature the same recommendations.

Of course simply checking the events in the Audit log is one thing, actually understanding the data within is something else altogether. Although Microsoft has done a fairly good job in documenting the process, including a detailed list of events collected and the overall schema used, you can often find some oddities in the audit trail.

I stumbled into one such example recently when toying with the Audit logs. To my dismay, I noticed numerous entries corresponding to the UserLoggedIn and the UserLoginFailed events, all of which showed “Unknown” for the UserId responsible for the login attempt. Now, it’s normal to have lots of failed login attempts in the logs, as Office 365 tenants are often target of brute force attempts, however for all of these you should be able to see which user is being targeted and take any necessary action.

Audit log output

Seeing “Unknown” for the user object used in the attempts is not very useful though, and downright concerning when there are successful login attempts as well. Thus I set to investigate what’s happening. The first thing I noticed is that all of these events seem to be generated for the same application, 00000003-0000-0ff1-ce00-000000000000, or in other words SharePoint Online. Looking at the extended event information I was also able to see that different IP addresses are being used, and tracing those did not return any results corresponding to known Microsoft datacenter ranges.

The next thing I noticed is that the ActorContextId for those attempts did not match the objectID of my own tenant. In other words, somebody from a different Office 365 tenant was trying to access something in my SharePoint Online. Now, given the fact that we’ve had Guest users in SharePoint Online for a while, and more recently in other workloads, this can definitely explain the events I was seeing. However, in my scenario the only Guest users added to the tenant were test accounts used by me, and one more used by Tony Redmond. None of the IP addresses corresponding to these events matched any IP me or Tony have used. Even more importantly, Guest user logins should show the corresponding UsedID listed in the event data, and not “Unknown”.

At this point I turned to the Cloud App Security console, as it offers additional filtering capabilities and in general makes it easier to work with the Audit logs compared to the SCC. After spending some time adjusting the filter to get to the events in question, the first entry I reviewed provided the answer. No, those weren’t Guest users, but actual accounts from other Office 365 tenants trying to get access. How do I know that? Well, CAS is kind enough to actually surface the information about the user’s objectID. Don’t ask me how it gets this information, as it is not present even in the raw Audit logs we have access to. Together with the “human-readable” value of the UserTenantId (same as the ActorContextId), we get the full picture.

MCAS audit log details

As seen from the above screenshot, this attempt corresponds to a user not linked to my tenant, and more importantly never added as a Guest user. Why is the event shown as successful login then? Because it is, the user has actually authenticated against Azure AD and obtained a valid token to be used with SharePoint Online. He simply does not have access to anything in *my* SPO tenant. So to be clear, those events are being generated when the user tries to access any SharePoint Online resource in a tenant he doesn’t have access to. For example, in the screenshot below I’ve used one of my test accounts to access a different tenant’s SharePoint Online site, and since my account is not found in this tenant (either as a regular user or a Guest user), the following error page is displayed:

Error message

So, there you have it, next time you see an Unknown entry in your Audit log, check whether this is an login (attempt) corresponding to SharePoint Online. If you are subscribed to CAS, examine the entry there to get all the needed information easily.  To be on the safe side and make sure that no actual breach has occurred, make sure to review any additional activities performed by the same user (easily done by clicking on the entry in CAS, then selecting the “Go to User page” link). If you are not using CAS, take a look at the extended properties of the audit log entry and note the ActorContextId – if it does not match your own tenant’s objectID, you have stumbled into one of these.

7 thoughts on “Login events in the Office 365 Audit log for the “Unknown” principal

  1. Giulio Valeri says:

    Hi Vasil,

    many thanks for your really helpfull information and documentation links.

    Best regards,

    Giulio

    Reply
  2. Tim says:

    HI
    Thanks for the very interesting analysis.
    I have successful login events with unknown user in my logs but when I look to the additional information i see the Actor context is the same as my tenant ID so not exactly as you describe in the article.
    How do I work out what the application is from the ApplicationID GUID?
    I get user type 5 and as well as a succeeded status I have a LogonError value of “FaultDomainRedirect”

    should i be concerned?

    Reply
    1. Vasil Michev says:

      There are lists online with the most used appIDs, or you can just do a search against your Enterprises Apps tab in the Azure AD blade.

      Reply
  3. Michele says:

    Thanks for sharing this.
    It was driving me crazy…..the log is very misleading…

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.