Microsoft 365 Security Monitoring: What to Watch and Why

Why Microsoft 365 Is the #1 Attack Target

The numbers explain the targeting: Microsoft 365 has over 400 million commercial paid seats worldwide. Every one of those seats is an email inbox, a SharePoint site, a OneDrive storage location, and an Azure AD identity that can be compromised. For attackers looking to conduct Business Email Compromise, steal sensitive documents, or establish persistence in an organization, M365 is the single most valuable target available.

The attack surface compounds because M365 sits at the center of organizational identity. Compromise an M365 account and you don't just get email — you get access to Teams conversations, SharePoint files, calendar data showing when the CFO is traveling, and potentially SSO access to every third-party SaaS application the organization has connected.

The 156-day average dwell time for compromised M365 accounts is particularly damning. An attacker with 156 days of access to email, SharePoint, and Teams can conduct a comprehensive business intelligence operation — reading emails to understand financial decisions, identifying key personnel for social engineering, building a picture of the organization's vendor relationships, and preparing a wire fraud attack timed to the next large transaction.

The Microsoft 365 Unified Audit Log: Your Primary Data Source

The Unified Audit Log (UAL) is the central security data source for Microsoft 365. It captures user and admin activity across Exchange Online, SharePoint, OneDrive, Teams, Azure AD, and Power Platform. Every sign-in, every file access, every email forwarding rule, every admin action — it's all there.

Several operational realities you need to know before building detection on the UAL:

• It's not enabled by default in legacy tenants: Organizations that have been on Microsoft 365 since before 2019 may need to manually enable UAL. Verify this — a disabled audit log is a complete security blind spot.
• Retention depends on your license: E3 licenses retain audit logs for 90 days. E5 licenses retain them for 1 year. If you need longer retention for compliance or forensics, you need to export to an external system — which is exactly what ZonForge Sentinel does automatically.
• Not all events are equal: The UAL contains hundreds of event types. The vast majority are routine productivity actions. Security detection focuses on a specific subset of event types that indicate account compromise, privilege abuse, or data exfiltration.
• Audit logs have latency: UAL events are typically available within 60–90 minutes of the activity occurring. For real-time detection, combine UAL with Azure AD sign-in logs (available via Microsoft Graph or Entra ID diagnostic settings), which have near-real-time availability.

Critical Detection 1: Suspicious Mailbox Access

Unauthorized mailbox access is the foundation of most BEC attacks. The attacker needs to read emails to understand financial processes, identify the right time to intercept a payment, and gather intelligence on tone and relationships for convincing impersonation.

The mailbox access events to monitor in the UAL:

• MailboxLogin by a non-owner: The MailboxLogin event with a different actor than the mailbox owner indicates delegate access or impersonation. Monitor for non-owners accessing executive mailboxes, finance team mailboxes, or HR mailboxes — all high-value BEC targets.
• New-InboxRule with external forwarding: Any inbox rule that forwards to an email address outside the organization's domain should trigger an immediate alert. There are extremely few legitimate business reasons for a rank-and-file employee to automatically forward all their email to a personal Gmail account.
• UpdateInboxRules that hide messages: Rules that move email to an obscure folder, mark emails as read, or delete specific messages are a cover-up mechanism — attackers hiding vendor reply emails so the victim doesn't see warnings about the fraudulent account change.

Critical Detection 2: OAuth Application Grants

OAuth application abuse is one of the fastest-growing attack vectors in Microsoft 365 environments. Rather than maintaining persistent access through a compromised password (which triggers MFA), attackers trick users into granting OAuth permissions to a malicious app registered in Azure AD. That app then has API-level access to the user's mailbox, calendar, files, and Teams — and continues to work even after the user changes their password.

The UAL events to monitor for OAuth abuse:

• Add app role assignment to service principal: This event fires when an application is granted permissions via admin consent. Any app gaining Mail.Read, Mail.ReadWrite, Files.ReadWrite.All, or MailboxSettings.ReadWrite permissions deserves scrutiny.
• Consent to application: User-level OAuth consent grants should be monitored for permissions that exceed what a legitimate productivity tool would need. An app requesting Mail.ReadWrite and Contacts.Read from a user who opened a phishing email is an OAuth phishing attack.
• Add OAuth 2.0 permission grant: Tracks both delegated and application permissions granted to apps. Build a baseline of legitimately sanctioned applications and alert on any new grant that doesn't match the known-good list.

The recommended control: disable user-level OAuth consent for apps registered outside your organization's Azure AD tenant, and require admin approval for all third-party app grants. This eliminates the entire OAuth phishing attack surface.

Critical Detection 3: Azure AD / Entra ID Sign-In Anomalies

Azure AD (now Microsoft Entra ID) sign-in logs provide the richest source of identity threat signals in Microsoft 365. Combined with the UAL, they give you a complete picture of who signed in, from where, on what device, with what authentication method, and whether the sign-in was flagged as anomalous by Microsoft's own risk engine.

Impossible Travel

The classic behavioral anomaly: a user signs in from London at 9:00 AM and from Singapore at 9:45 AM. The physical impossibility of that travel pattern is a strong indicator of account compromise. Entra ID Identity Protection flags these as high-risk sign-ins; your SIEM or detection platform should treat Entra ID risk events as high-priority signals.

Unfamiliar Location Sign-Ins

A user whose last 180 days of sign-ins are exclusively from the United States suddenly authenticating from a Netherlands IP address — while not impossible — is worth investigating, especially if followed by mailbox access or file downloads. Behavioral baselining per user is essential here; a blanket geographic block misses attackers using VPNs and creates false positives for legitimate travelers.

Legacy Authentication Protocols

Sign-ins using legacy protocols — SMTP AUTH, IMAP, POP3, or Basic Authentication — bypass Conditional Access policies and MFA entirely. Any successful authentication to Exchange Online using a legacy protocol for an account that normally uses modern authentication is either a misconfigured application or an attacker using a legacy protocol specifically to avoid MFA. This signal has an extremely low false-positive rate once legitimate legacy protocol users are baselined.

Critical Detection 4: Admin Privilege Changes

Administrative role changes in Azure AD are the M365 equivalent of IAM privilege escalation in AWS. The events are captured in both the UAL and the Azure AD audit log.

• Add member to role (Global Administrator): Any addition of a user to the Global Administrator role should be treated as a high-severity event requiring immediate review. Global Admin in M365 is the equivalent of root in AWS — it grants unrestricted access to everything. Even planned additions to this role should generate an alert so the security team can verify it was expected.
• MFA removal from accounts: The Update user — StrongAuthenticationRequirements event in the UAL captures MFA changes. Removing MFA from a privileged account is a backdoor creation technique — alert on any MFA removal for admin accounts immediately.
• Add a member to a privileged group: Beyond Global Admin, monitor additions to Exchange Administrator, Security Administrator, Privileged Authentication Administrator, and Global Reader roles. These all grant significant access that can be abused post-compromise.

Critical Detection 5: Data Exfiltration Signals

Data exfiltration from Microsoft 365 most commonly involves SharePoint and OneDrive for files, and Exchange Online for email archives. The UAL captures both.

Mass Download from SharePoint

Monitor for FileDownloaded events where a single user downloads an unusual volume of files in a short window — particularly from document libraries they don't normally access. The threshold varies by environment, but a user who normally downloads 10 files per day suddenly downloading 800 files over two hours warrants investigation.

Also watch for AnonymousLinkCreated and SharingInvitationCreated events that share sensitive document libraries with external users or create anonymous access links for bulk document sets.

Mailbox Export to PST

The New-MailboxExportRequest event in Exchange Online administrative audit logs captures when a mailbox is exported to a PST file. Legitimate use cases exist (HR or legal holds during investigations), but this operation should be tightly controlled and any unexpected mailbox export — especially of executive or finance team mailboxes — is a high-severity exfiltration signal.

BEC Attack Pattern: The Full Kill Chain

Understanding the complete BEC kill chain helps build detection coverage at every stage, rather than only catching the final fraud attempt:

1. Initial Access: Credential phishing (password spray, AiTM phishing) or password reuse from a third-party breach. Detected via Entra ID sign-in risk events, unusual sign-in locations, or sign-in anomalies.
2. Account Verification: The attacker calls GetCallerIdentity equivalents — accessing the victim's profile, calendar, and inbox structure to confirm access and understand the target. Detected via anomalous mailbox access events shortly after a suspicious sign-in.
3. Persistence Establishment: Creating inbox forwarding rules, granting OAuth permissions to a persistent app, or adding a recovery email address. Detected via New-InboxRule and OAuth consent events.
4. Intelligence Gathering: Reading email over days or weeks to understand financial processes, relationships, and timing. This stage is the hardest to detect without behavioral baselining — it looks like normal email reading.
5. Action on Objective: Sending a fraudulent invoice change or wire transfer request at the right moment. Detected via email send anomalies, messages referencing financial accounts, or direct observation of the fraud.

The BEC attacks that succeed are the ones where detection coverage only exists at stage 5. By that point, the money is already moving. Effective M365 threat detection requires coverage at stages 1 through 3, where the attacker is still conducting reconnaissance and hasn't yet committed the fraud.

Microsoft Defender for Office 365 vs External SIEM for M365 Monitoring

Microsoft Defender for Office 365 (MDO) provides solid first-party threat detection for email-borne threats: anti-phishing, anti-malware, and safe links/attachments. It's a valuable layer and organizations with M365 E5 licenses should have it fully enabled.

However, MDO has meaningful gaps for comprehensive security monitoring:

• Limited correlation across data sources: MDO operates within the M365 ecosystem. It cannot correlate M365 events with your AWS CloudTrail, endpoint detection, or network logs to identify a multi-vector attack that spans M365 and your cloud infrastructure.
• No behavioral baselining per user: MDO uses Microsoft's global threat intelligence models, not per-user behavioral baselines specific to your organization. A user who legitimately accesses large volumes of SharePoint files may generate false positives, while a user who rarely accesses files conducting a small targeted download may go undetected.
• Alert output requires manual triage: MDO generates alerts into the Microsoft 365 Defender portal, which is a separate queue from your other security tooling. For organizations using a SIEM or security platform, this creates parallel workflows and potential for incidents to fall through the cracks.

How ZonForge Sentinel Connects to Microsoft 365

ZonForge Sentinel integrates with Microsoft 365 via the Microsoft Graph API and Microsoft Entra ID diagnostic settings, pulling the Unified Audit Log, Entra ID sign-in logs, and Entra ID audit logs in near-real-time. The integration requires an application registration in your Entra ID tenant with the appropriate Graph API permissions — a setup that takes approximately 15 minutes.

Once connected, ZonForge Sentinel applies the M365-specific detection rule library to your tenant's activity data. The pre-built detections cover all five critical detection categories described in this guide, along with behavioral baselining that calibrates thresholds to your specific user population and usage patterns.

The result: M365 security signals appear in the same ZonForge Sentinel alert queue alongside your cloud infrastructure, endpoint, and network detections. An attack that begins with an M365 account compromise and then pivots to AWS via SSO is visible as a connected incident — not as two separate, unrelated alerts in different tools.

Conclusion: Microsoft 365 Security Monitoring Starts with Knowing What to Watch

The data to detect every BEC attack, every account compromise, and every OAuth abuse incident in your Microsoft 365 environment is already being captured in the Unified Audit Log. The gap is not data collection — it's knowing which events matter, having the detection logic to identify attack patterns, and connecting those M365 signals to the broader security picture.

Prioritize Microsoft 365 security monitoring around the five critical detection categories: suspicious mailbox access (especially inbox forwarding rules), OAuth application grants, Azure AD sign-in anomalies, admin privilege changes, and data exfiltration signals. Build detection on behavioral baselines rather than static thresholds, and make certain your M365 data feeds into the same investigation workflow as your other security data sources.

The organizations with 156-day dwell times for M365 compromise aren't missing data. They're missing detection. ZonForge Sentinel bridges that gap.