What is the app@sharepoint Account in my Azure Sentinel Data?

Azure Sentinel, Office 365 1 Minute

This is just a quick blog post for clarification purposes.

We’ve had some internal discussion around this, but what predicated this blog post is the number of customers who’ve also asked about this most recently. Because we’re continuing to improve the data and types of data that are exposed through our table schema and automated analysis (Analytics Rules), customers are finding all sorts of new and curious things that they didn’t know existed before. Some can be real headscratchers.

This latest one is the app@sharepoint account that shows up in query results. This “user” account is logged in the OfficeActivity table because as the account name suggests, it’s part of SharePoint (or OneDrive) operations.

Here’s a query to see it at work in your environment:

OfficeActivity
| where UserId == "app@sharepoint"
| distinct Operation
app@sharepoint operations

app@sharepoint is an account that is utilized as a service principal for SharePoint-based operations (including OneDrive, Teams, Yammer, etc.).

The next logical customer question usually goes something like this: “Well, if it’s a service principal, can I whitelist the account?”

Personally, I have issue with whitelisting any account. Any account can be compromised. To maintain complete security, we need to monitor and report suspicious activity for any account under our purview.

However, you can get clever and whitelist specific accounts from existing Analytics Rules but then create a new Analytics Rule to specifically track those accounts you’ve deemed worthy of whitelisting. Just adjust the severity, the schedule, and threshold a bit. This helps minimize noise in the system, but also ensures all accounts are still being monitored.

The next piece, of course, is how to tie app@sharepoint operations to the user account for which the service principal was providing proxy operations.

Run something like the following:

OfficeActivity
| where UserId == "app@sharepoint" or UserId contains "<yourdomain>"
| distinct TimeGenerated, Operation, UserId

…and then locate the duplicate TimeGenerated entries.

[Want to discuss this further? Hit me up on Twitter or LinkedIn]

Author

Published