Most business breaches we investigate succeed in the same way: an attacker walking commodity tooling through Microsoft 365 configuration that has not been reviewed since the tenant was provisioned. Phishing kits. Token theft. OAuth abuse. Mailbox rules. None of it sophisticated. All of it sufficient.
These are five settings that close common exposure paths. None of them require a license uplift beyond what most mid-market tenants already have.
1. Mailbox auto-forwarding to external recipients
After a mailbox is compromised, one of the first persistence moves attackers make is a forwarding rule that silently copies inbound mail to an attacker-controlled address. The user keeps using their mailbox normally. The attacker watches the conversation — useful for wire fraud, vendor impersonation, and long-term reconnaissance.
Where to look. Multiple layers govern this: the outbound spam filter policy in Defender for Office 365 (the modern primary control), Exchange Online remote domain settings, mail flow rules, and the per-mailbox ForwardingAddress / ForwardingSmtpAddress attributes. Set automatic external forwarding to Off in the outbound spam policy, and check the mailbox attributes via PowerShell — both can be populated directly even when the user-facing forwarding controls are blocked.
What to alert on. New inbox rules that forward, redirect, or delete messages. The Microsoft 365 alert policy "Suspicious inbox forwarding rule" covers this if enabled — confirm it is on and that the alerts route to a mailbox someone actually reads, not a default tenantadmin@ that nobody monitors.
2. Legacy authentication protocols
Microsoft retired Basic authentication for most Exchange Online protocols in late 2022. SMTP AUTH was the deliberate exception, and it remains the legacy vector that still shows up in incidents today. Anywhere legacy auth is in play, MFA and Conditional Access do not apply — a credential stolen through phishing or password spray can be used directly, bypassing every modern protection. Password spray against SMTP AUTH and any surviving legacy endpoint is still one of the most reliable ways to take over a tenant that otherwise looks well-defended.
Where to look. Microsoft Entra → Monitoring → Sign-in logs → filter by Client app → "Legacy authentication clients". Anything in this list is a candidate for disablement. Some line-of-business apps (older scanners, ERP integrations, fax-to-email connectors) still use legacy SMTP AUTH; identify and migrate those, or carve out per-mailbox exceptions rather than leaving the protocol on tenant-wide.
What to change. In Entra → Security → Conditional Access, create a baseline policy that blocks legacy authentication for all users. SMTP AUTH can be disabled at the tenant level and re-enabled per-mailbox where genuinely required.
What to watch. Sign-ins from "Other clients" or "IMAP/POP" client app types in the sign-in logs. Any non-zero count after the policy is in place is either a misconfigured app or an attempted bypass — both worth chasing down.
3. Conditional Access for privileged roles
When MFA is "enabled" per-user but not enforced through Conditional Access — and the Global Admin account is the legacy break-glass that everyone is afraid to touch — the attacker only needs to land that one account. Privilege escalation in M365 is often not lateral movement; it is locating the one identity that escaped the controls applied to everyone else.
Where to look. Entra → Identity → Roles & admins → Global Administrator. Cross-reference each account against the Conditional Access policies in Entra → Security → Conditional Access. Verify every account holding a Tier 0 role is covered by a policy that requires MFA and blocks legacy auth.
What to change. Replace the assumption that "MFA is enabled per-user" with a Conditional Access policy targeting the privileged-role groups specifically. Use named locations sparingly — VPN exits and home IPs are not safer than the open internet, and named-location bypasses are how a break-glass account turns into a backdoor.
What to watch. Sign-in risk and user risk policies in Entra ID Protection. For privileged accounts, a medium-risk sign-in should require MFA reauth or block outright. Audit Tier 0 role membership monthly — privileged role assignments drift, especially in tenants that have changed MSPs.
4. SharePoint and OneDrive anonymous link settings
Once inside, attackers create anonymous sharing links to exfiltrate data through SharePoint and OneDrive. The traffic looks like normal Microsoft 365 use to most DLP and proxy tools. They also harvest existing anonymous links left behind by users — "anyone with the link" persists indefinitely on most default tenants.
Where to look. SharePoint admin center → Policies → Sharing. Default external sharing is often set to "Anyone (anonymous)". Pull an audit of existing anonymous links using the SharePoint Online Management Shell (Get-SPOSite, Get-SPOTenant) or run a sharing access review through Purview.
What to change. Set the default link type to "Specific people". For tenants that have a legitimate business case for anonymous sharing, set link expiration to 30 days on those "Anyone" links specifically — expiration is the control that matters most where anonymous sharing has to stay on. Restrict anonymous sharing to "Existing external users", or disable it entirely for tenants that have no business case for it. Mid-market tenants almost always discover, when they audit, that anonymous sharing was enabled by an admin years ago and used a handful of times since.
What to watch. New anonymous link creation, especially on sites containing finance, HR, or customer data. Surface this in Purview activity reports or build a Microsoft Sentinel detection on AnonymousLinkCreated events.
5. Audit log retention and unified audit search
Attackers count on you not being able to look back. Default Audit Standard retention is 180 days for records generated since October 2023. That sounds generous until you measure it against actual BEC dwell times — by the time someone notices the wire transfer, the audit window that would show the rule creation, the OAuth grant, and the suspicious sign-ins is often already gone or closing.
Where to look. Purview → Audit → Audit retention policies. Confirm what retention is actually in effect, not just what is licensed. E3 and E5 license tiers permit longer retention, but the actual retention policy still has to be created — licensing alone does not extend the window.
What to change. Extend audit retention to at least one year for all users, and longer for privileged accounts and executives. Confirm that the Unified Audit Log is enabled tenant-wide — there are still tenants where it was disabled at provisioning and never turned on.
What to watch. This one is preparation, not detection. The audit log is the artifact you need on the day you start an incident, not the day you ship the post-mortem.
Closing
These five are not a hardening framework. They are the configuration gaps we see most often in tenants that have never been formally reviewed. Each closes a path attackers used in actual cases this past year. None require new tooling — only attention to what is already in the tenant.
The most expensive M365 breaches we work are the ones where the answer to "when was the tenant last reviewed?" is "never, since we deployed it."