You might think of Azure Sentinel in the context of connecting the logs of third party devices (such as physical firewalls), to add the full picture of your environment for your Security, Information Event and Management processes. Azure Sentinel can also include other Microsoft solutions as data sources, such as Azure Active Directory, Microsoft Cloud App Security and Microsoft 365. Let’s take a look at the built-in threat hunting queries available for Microsoft 365.
NB: Previously known as Office 365, some remnants of this original name still exist, like the data connector name.
Ingesting Microsoft 365 data
First, you’ll need to add the Office 365 data connector to Azure Sentinel. A pre-requisite for this is that unified audit logging must be enabled on your Office 365 deployment. You can use the Microsoft 365 Security and Compliance Center to check the status of unified audit logging. Then you can enable the Office 365 log connector in Azure Sentinel, in the Data Connectors blade.
At the time of writing, this data connector supports the ingestion of data from Exchange Online, SharePoint Online, OneDrive for Business and Microsoft Teams. For a full and current list of supported audit log data, visit the OfficeActivity Logs Reference.
Built-in threat hunting queries for Microsoft 365
There are currently 27 queries available in Azure Sentinel that Microsoft provides for the OfficeActivity logs. Queries with a * can include other data sources, like SignInLogs or even AWS Cloud Trail:
- Multiple password reset by user*
- Permutations on logon attempts by UserPrincipalNames indicating potential brute force*
- Rare domains seen in Cloud Logs*
- Tracking Privileged Account Rare Activity*
- Exploit and Pentest Framework User Agent*
- New Admin account activity seen which was not historically
- SharePointFileOperation via previously unseen IPs
- SharePointFileOperation via devices with previously unseen user agents
- Non-owner mailbox login activity
- Powershell or non-browser mailbox login activity
- SharePointFileOperation via clientIP with previously unseen user agents
- Multiple users email forwarded to same destination
- Preview – TI (threat intelligence) map File entity to OfficeActivity Event*
- Multiple Teams deleted by a single user
- Summarize files uploaded in a Teams chat
- Bots added to multiple teams
- User made owner of multiple teams
- External user from a new organisation added
- User added to Team and immediately uploads file
- Exes with double file extension and access summary
- Mail redirect via ExO transport rule
- New Windows Reserved Filenames staged on Office file services
- Office Mail Fowarding – Hunting Version
- Files uploaded to teams and access summary
- External user added and removed in a short timeframe
- Previously unseen bot or application added to Teams
- Anomalous access to other user’s mailboxes
These queries give you common scenarios you might want to search the logs for, and the Kusto Query Language (KGQL) to run these queries at the click of a button. After filtering or searching the list of queries across all of the data sources, you can even click Run displayed queries to execute multiple searches at once.
Check out the public Hunting query repository on GitHub too, for more queries shared by the community.
Scenario: Mail forwarding
The magic comes from deciding which queries are relevant to your organization and relevant to the potential security threat you’re proactively investigating. You can always build your own with KQL (or start with a built-in one and clone it to modify it), but the built-in queries offers some insights “out of the box” to get you started.
Let’s choose the Office Mail Forwarding – Hunting version query.
This query highlights cases where user mail is being forwarded and shows if it is being forwarded to external domains as well. It might be normal in your organization for mail to be forwarded, so monitoring and alerting on this every time it happens may generate noise you then start to ignore, because you know it’s normal. But if you’d been alerted of some abnormal employee behaviour, running this query can easily give you some more details.
The results show that meganb set up a mailbox rule to automatically forward emails to someone at an external email domain, and the time, client IP address and email server involved.
While that query ran once at a point in time, looking at historical data, we could use it to run a livestream session, notifying us via the Azure portal notifications when new events occur, or elevating that livestream session to an alert. For more details, visit Use livestream to hunt.
Other steps in the threat hunt
The scenario has highlighted a particular activity by a user, MeganB, so let’s dig a little deeper. Now I’m going to use the User and Behaviour Analytics to look at activity related to Megan’s account. This isn’t a straight query – again, Megan may have done a lot of valid work that we would need to try and filter out. Instead, UEBA analyzes the data sources and builds baseline behavioural profiles, using a variety of techniques and machine learning to identify anomalous activity. The results are presented as timeline and as a set of insights.
I also have the option to click the Investigate button, and use the investigation graph to explore related data. Visit Tutorial: Investigate incidents with Azure Sentinel.
Want to learn more?
Check out the the following free learning paths on Microsoft Learn, which are also resources for the SC-200 Microsoft Security Operations Analyst exam (currently in beta):
To help improve the threat response in your organization, a powerful tool like Azure Sentinel, plus the right data sources, is just the start. You don’t need to be faced with a blank canvas, having to decide which queries to build. Azure Sentinel’s built-in threat hunting queries for Microsoft 365 are a great way to start investigating potentially malicious user behaviour.