Microsoft Sentinel – Microsoft365 Quick Start Guide
Last Updated: 13/01/2025
This Microsoft365 quick start guide is created to highlight the out of the box data connectors and analytical rules that should be enabled in Microsoft Sentinel for a typical Microsoft 365 environment. Whilst a lot of the out of the box content is useful, simply enabling all analytical rules can dilute the value of Microsoft Sentinel.
This Microsoft365 quick start guide is not an exhaustive list on the rules and connectors that you should be using, only initial examples to focus on to get quick value from Microsoft Sentinel. It is highly recommended that you review all out of the box rules and determine the relevance to your environment and tune the rules based on your detection requirements.
Data Connectors
It is highly recommended to enable the following Data Connectors:
- Microsoft 365 (formerly Office365)
- This allows activity and audit data to be ingested from services such as: Teams, SharePoint & Exchange.
- The data ingested is free of charge, assuming the M365 Services and Sentinel instance are in the same Entra ID Tenant.
- Microsoft Entra ID
- Scoped to Sign-In and Audit Logs at a minimum.
- Data ingestion is subject to standard ingestion costs.
- Provides key data on authentication and authorisation activities into your Azure & M365 Environment.
- Microsoft Defender XDR
- Initially scoped to alerts only.
- Alerts are ingested free of charge, whereas the raw logs are chargeable.
- Ingests alerts generated from Defender XDR, please note that if you are not using any XDR products this connector may be less relevant.
Microsoft365 Analytical Rules
Name: | Rare and potentially high-risk Office operations |
Reason: | Identifies activities that are rare/uncommon that typically provide useful capabilities to attackers. |
Notes: | Looks for activities that include altering mailbox permissions and mailbox rules. |
Name: | Office policy tampering |
Reason: | Identifies if any tampering is done to either auditlog, ATP Safelink, SafeAttachment, AntiPhish or DLP policy. |
Notes: | These types of policies will be seldom changed and would be subject to change management, any deviation of policy should be identified and investigated |
Name: | Multiple users email forwarded to same destination |
Reason: | Identifies when multiple (more than one) users mailboxes are configured to forward to the same destination. This could be an attacker-controlled destination mailbox configured to collect mail from multiple compromised user accounts. |
Notes: | Chances for false positives depending on how teams set Out of Office & Forwarding, however is easy to qualify with users. |
Name: | Exchange AuditLog Disabled |
Reason: | Identifies when the exchange audit logging has been disabled which may be an adversary attempt to evade detection or avoid other defences. |
Notes: | This policy/configuration will seldom change and would be subject to change management. Deviation of this policy/configuration should be identified and investigated. |
Name: | SharePointFileOperation via Previously unseen IPs |
Reason: | Identifies when the volume of documents uploaded or downloaded from SharePoint by a new IP address exceeds a threshold (default: 50) |
Notes: | This could indicate a compromised account attempting to exfiltrate data. |
Name: | Mail redirect via ExO transport rule |
Reason: | Identifies when Exchange Online transport rule configured to forward emails. |
Notes: | This could be an adversary mailbox configured to collect mail from multiple user accounts. This differs from the “Multiple users email forwarded to same destination” rule, this rule focuses on the mail transport rules that are defined within the Exchange Online admin centre. |
Microsoft Entra ID Analytical Rules
Name: | Authentication Methods changes for Privileged Account |
Reason: | Identifies authentication methods being changed for a privileged account. This could be an indication of an attacker adding an auth method to the account so they can have continued access. |
Notes: | Detects both admin and user edited/deleted security information. |
Name: | PIM Elevation Request Rejected |
Reason: | Identifies when a user is rejected for a privileged role elevation via PIM. |
Notes: | This could indicate a compromised account attempting to elevate permissions. Please note that using this rule will require the use of PIM. |
Name: | Rare Application Consent |
Reason: | This will alert when the “consent to application” operation occurs by a user that has not done this operation before or rarely does this. |
Notes: | This could indicate that permissions to access the listed Azure app were provided to a malicious actor. This rule can aid in detecting Oauth2 attacks. There are additional analytical rules for application consent that should also be investigated and utilised. |
Name: | Bulk Change to Privileged Account Permissions |
Reason: | Identifies changes to multiple users’ permissions made at once. |
Notes: | This could indicate an attacker escalating privileges for their account(s) or attackers revoking permissions from legitimate accounts |
Summary
Hopefully this Microsoft365 Quick Start guide gives you a good indication of some of the out of the box rules you can use with your Microsoft365 environment. There are many more out of the box rules that you can leverage, and I would encourage you to explore these. For all rules that you enable, please make sure you take the time to test and tune these rules.
Thank you for reading! And if you haven’t done so already, please check out my previous post of Automation with Microsoft Sentinel, as some of these rules can be linked to automation actions!
Nice article…are you planning on doing the ones for Azure?
Thanks Robyn! Its on the list to do and will likely start with the Azure subscription level events first, then include ones for services like: Azure Firewall, Key Vault, NSGs & Azure SQL.