How Hackers Hack Office 365 / Microsoft 365 — and How to Protect Yourself
How attackers compromise Microsoft 365 tenants and what defenders need to monitor.
🛡️
Defender's Guide
This is a defender-focused resource covering attack patterns at a conceptual level so you can recognise threats and protect yourself or your organisation. The page does not include step-by-step exploitation procedures. If you suspect you are currently being targeted or have been compromised, scroll to the recovery section below.
What attackers want from Office 365 / Microsoft 365
Microsoft 365 (formerly Office 365) is the single most-attacked enterprise identity system. The product line hosts email, file storage, collaboration, authentication, and identity for hundreds of millions of business users — which means a successful M365 tenant compromise grants attackers access to corporate email, SharePoint documents, Teams conversations, OneDrive files, and in many cases downstream SaaS applications that use M365 for SSO. Business Email Compromise (BEC) fraud, data exfiltration, and ransomware-positioning all commonly start with M365 account compromise.
The threat landscape is dominated by credential-based attacks: phishing for credentials (increasingly via real-time proxies that bypass TOTP MFA), password spraying against tenants, OAuth consent-grant phishing (malicious apps with excessive permissions), and session-token theft via info-stealer malware. Vulnerability-based attacks exist but credential attacks dominate by volume; the 80/20 of M365 defence is account security, not server security.
This page is written for IT and security teams managing M365 tenants. Microsoft provides strong security capabilities in the platform, but many of them are not enabled by default — they require active configuration through Security Defaults, Conditional Access, Microsoft Defender for Office 365, and identity-protection tooling. The gap between "default M365 tenant" and "hardened M365 tenant" is substantial; closing it is one of the highest-leverage defensive investments available.
How attackers actually do it
Conceptual attack categories, not exploitation procedures. Understanding these patterns is what lets you recognise and defend against them.
Adversary-in-the-Middle (AiTM) phishing bypassing traditional MFA
Modern phishing kits (Evilginx, Modlishka, commercial kits sold on underground markets) proxy the victim through the real Microsoft login in real time, capturing credentials AND the completed MFA response, then stealing the resulting session token. Defeats TOTP, push-notification MFA, and SMS MFA. Phishing-resistant MFA (FIDO2 keys, Windows Hello for Business, certificate-based) is the answer.
Password spraying against tenant users
Low-and-slow attempts using common passwords (Winter2024!, CompanyName1, Password123) against lists of tenant users enumerated via Autodiscover or social engineering. Avoids account lockout by trying few passwords per account across many accounts. Widely used baseline attack against all M365 tenants.
OAuth consent-grant phishing
Attacker-controlled Azure AD applications request OAuth permissions from victims. Victim approves (often via plausible-looking "new productivity app" phishing), granting the attacker token-based access to read email, calendar, SharePoint, OneDrive. Persists independently of password changes because it uses OAuth tokens, not credentials. Requires active hunting for malicious enterprise applications.
Session-token theft via info-stealer malware
Info-stealers on user endpoints exfiltrate M365 session cookies and tokens, allowing attacker replay without ever needing the password or MFA. Amos, Atomic Stealer, RedLine, Raccoon — all prominent stealers harvest M365 tokens. Countered by Conditional Access policies that validate device health and location.
Business Email Compromise after account takeover
Once an attacker has access to an executive or finance-team M365 mailbox, the BEC playbook runs: inbox rules forward copies of incoming mail to external addresses, fraudulent payment instructions sent from the legitimate account to finance/vendors, wire transfers redirected. Average BEC loss per incident is substantial ($150K+ commonly); individual incidents reach millions. M365 compromise is the most common BEC entry point.
Exchange and Graph API abuse for data exfiltration
Once in the tenant, attackers use Exchange Web Services or Microsoft Graph API to exfiltrate email data at scale, search for sensitive content (payment instructions, credentials, personal information), and establish persistence via inbox rules and forwarding addresses. Graph API traffic is often under-monitored compared to interactive login activity.
On-premises Exchange vulnerabilities (ProxyLogon, ProxyShell, Log4Shell-adjacent issues) and SharePoint vulnerabilities have produced major enterprise compromise waves. Microsoft 365 (cloud) is less affected than on-premises installations but hybrid environments inherit on-premises exposure. Organisations running on-premises Exchange in 2026 should be actively planning migration or acknowledging significant risk.
Conditional Access policy bypass and misconfiguration exploitation
Attackers who gain initial access enumerate Conditional Access policies and find exploitable gaps — legacy-authentication protocols not blocked, break-glass accounts without MFA, trusted-location bypasses, service accounts with weak protection. Misconfigured CA policies are routinely exploited; regular policy review and red-team testing reveal the gaps.
How to recognise compromise
Signs that your office 365 / microsoft 365 may have been compromised:
Sign-in logs showing impossible-travel or unusual-location logins
Azure AD sign-in logs with correlations showing same user authenticating from geographically impossible locations within short time windows. Microsoft Entra ID Protection surfaces these automatically at P2 licensing; Sign-in Risk events at any licensing level. Actionable signal for account compromise.
Inbox rules creating external forwarding
Post-compromise standard pattern. Auto-forward or inbox rules sending copies of incoming mail to external addresses. Microsoft Defender for Office 365 surfaces these; also hunt via PowerShell: `Get-InboxRule` across mailboxes. Any external forwarding from accounts that should not have it = investigate immediately.
Unusual enterprise application grants
Azure AD → Enterprise Applications shows all OAuth-granted apps. Unexpected entries or unusual permission grants (full mail read, full SharePoint read) from applications you did not approve = OAuth consent phishing or attacker persistence. Review monthly; alert on high-risk permission grants.
New global administrator or role assignments
Any new privileged role assignment not tied to a change-management ticket warrants investigation. Attackers with access commonly add themselves or create new privileged accounts for persistence. Azure AD audit logs surface role assignment events.
Legacy authentication protocol usage from unusual sources
POP3, IMAP, SMTP AUTH, and other legacy protocols should be disabled tenant-wide; any use after disablement attempts indicates either misconfiguration or attacker use of legacy protocols to bypass Conditional Access (which legacy protocols cannot enforce).
Suspicious downloads from SharePoint or OneDrive
Mass-download activity from individual accounts — sudden download of hundreds or thousands of files from SharePoint or OneDrive. Either exfiltration in progress or an unusually-busy user; either way worth investigation. Microsoft Purview Insider Risk and Defender for Cloud Apps surface these.
What actually protects you
Concrete actions ranked by impact. Items marked critical are the highest-leverage protections; do those first.
Enable Security Defaults (minimum) or Conditional Access (recommended)
Security Defaults (free with any M365 subscription): enforces MFA for all users, blocks legacy authentication, protects privileged actions. Conditional Access (Azure AD Premium P1+): granular control over who can access what from where under what conditions. Every M365 tenant should have at minimum Security Defaults enabled; most organisations should move to full Conditional Access policies.
Phishing-resistant MFA for privileged accounts
FIDO2 security keys (YubiKey, Titan), Windows Hello for Business, or certificate-based authentication. Microsoft fully supports these. Required for administrators, executives, finance team, legal, and anyone with access to sensitive systems. AiTM phishing defeats traditional MFA; phishing-resistant authentication is the answer.
Block legacy authentication protocols
POP3, IMAP, SMTP AUTH, ActiveSync (legacy), and other pre-modern protocols cannot enforce MFA. Block them tenant-wide via Conditional Access policy or Security Defaults. Legacy protocols are the most common MFA-bypass mechanism in documented M365 incidents. There are very few legitimate reasons to keep them enabled in 2026.
Deploy Microsoft Defender for Office 365 (Plan 2 ideally)
Safe Attachments (detonates attachments in sandbox), Safe Links (URL rewriting with click-time checking), Anti-phishing policies, Attack Simulation Training. Plan 1 for the basics; Plan 2 for automated investigation, threat hunting, and Explorer capabilities. Meaningful improvement over stock Exchange Online Protection.
Configure Conditional Access policies for risk-based authentication
Require MFA for all users, block legacy auth, require compliant devices for sensitive apps, require MFA for risky sign-ins (Azure AD Identity Protection integration), restrict admin actions to trusted networks, block anonymous VPN and Tor sources for sensitive applications. Each policy adds detection and blocking layer. Plan policies carefully; test before enforcing broadly.
Audit enterprise applications and OAuth grants monthly
Azure AD → Enterprise Applications. Remove unused apps. Investigate unfamiliar entries. Block user consent for high-risk permission sets; require admin review for app registrations. Prevents most OAuth consent phishing outcomes.
Deploy privileged identity management (PIM) for admin roles
Azure AD PIM (requires Premium P2) converts permanent admin role assignments to just-in-time elevation with justification, time-limiting, and approval workflows. Reduces standing privilege substantially; admin accounts become less valuable targets because elevation requires additional steps.
Enable audit logging and retain for adequate duration
Unified Audit Log should be enabled. Default retention is 90-180 days depending on licensing; Microsoft Purview enables longer retention for compliance needs. Audit logs are the forensic foundation for any incident investigation — ensure they exist before you need them.
Threat-hunt proactively with Microsoft 365 Defender or integrated SIEM
M365 Defender portal provides hunting queries across identity, endpoint, email, and SharePoint data. Microsoft Sentinel (SIEM) integrates all of this with broader security telemetry. Scheduled hunting for known attack patterns (AiTM phishing indicators, suspicious OAuth grants, inbox-rule creation patterns) catches incidents that automated detection misses.
Separate admin accounts from user accounts
Administrators should use dedicated admin accounts (admin.alice@tenant.com) distinct from their user accounts (alice@tenant.com). Admin accounts should be cloud-only (not synced from on-prem AD), have strongest possible authentication, and be used only for admin activities. Reduces blast radius of administrator-account compromise substantially.
Frequently Asked Questions
Phishing-resistant MFA (FIDO2 security keys, Windows Hello for Business) deployed at minimum to administrators, executives, and anyone with access to sensitive systems. AiTM phishing defeats traditional MFA (TOTP, push) — phishing-resistant authentication is the only reliable defence. Combined with blocking legacy authentication protocols, this single pair of changes defeats the majority of actual M365 compromise paths observed in the wild.
Security Defaults is the absolute minimum — MFA for all users, legacy auth blocked, privileged actions protected. Adequate for very small organisations with minimal threat exposure; insufficient for most mid-to-enterprise scenarios. Conditional Access policies (Azure AD P1+) are the normal upgrade path, providing granular control over authentication requirements based on user, device, location, and application.
Modern phishing technique where the attacker's server proxies the victim's login through the real Microsoft login page in real time. Victim types credentials and completes MFA prompt; attacker captures both and steals the resulting session token. Defeats TOTP, push notifications, SMS — anything except phishing-resistant MFA (FIDO2, Windows Hello for Business, certificate-based authentication). Evilginx is the well-known open-source kit; commercial kits are sold on underground markets. This is the current dominant M365 phishing technique.
Signal sources combined: Azure AD sign-in logs with unusual-location or impossible-travel entries, Unified Audit Log showing unexpected admin actions, inbox rules creating external forwarding, unfamiliar enterprise applications in Azure AD, mass data-access patterns in Defender for Cloud Apps or Purview Insider Risk. No single signal is definitive; correlation across sources produces defensible detection. Requires SIEM integration or regular manual review of these logs. Organisations without this capability routinely have ongoing M365 compromise that they do not know about.
For general users: reasonable choice — better than SMS, app-based rather than hardware. For administrators and high-value accounts: insufficient. Microsoft Authenticator with number-matching is better than without, but still vulnerable to AiTM phishing in principle. For administrators, use phishing-resistant MFA (FIDO2 security keys minimum). Microsoft Authenticator remains a reasonable second factor for normal users while hardware keys are deployed for high-risk roles.
Attacker creates a malicious Azure AD application (or compromises a legitimate one) and tricks users into granting OAuth permissions. Users see a plausible "Sign in with Microsoft" prompt; approve; the attacker now has token-based access to email, files, or whatever permissions were granted. Prevention: restrict user consent for unverified applications (Azure AD settings), require admin review of application consent, audit enterprise applications regularly. Detection: monitor for unusual consent grants and high-risk permission scopes.
Potentially very bad. Executive account compromise enables BEC fraud, sensitive data access, authorisation for privilege changes, and reputational damage. Immediate actions: revoke sessions, force password change, add phishing-resistant MFA, audit inbox rules and forwarding, review recent sent mail for BEC attempts, notify finance team to verify any payment changes. Consider engaging incident response. For regulated industries, potential regulatory notification obligations. CEO compromise is among the highest-severity M365 incidents; treat urgency accordingly.
For most organisations — yes, especially Plan 2. Safe Attachments and Safe Links alone catch substantial phishing volume that reaches Exchange Online Protection. Automated investigation and threat-hunting capabilities in Plan 2 reduce SOC burden. Attack Simulation Training provides phishing-awareness testing. Cost-benefit strongly favours deployment for any organisation with meaningful email-based risk, which is essentially all of them.
Break-glass accounts (emergency-access accounts that bypass MFA) exist for legitimate reasons — MFA infrastructure failure, all other admins locked out — but are high-risk targets. Best practices: cloud-only (not synced), extremely complex passwords stored physically in sealed envelopes in secure locations, phishing-resistant MFA ideally still present, strict monitoring (alert on any use), regular testing to ensure they work when needed, annual rotation of passwords. Not having break-glass accounts is also risky (account lockout scenarios); the balance is creating them but protecting them like nuclear codes.
Azure AD Premium P1+ feature that evaluates sign-in attempts against configurable policies — allowing, blocking, or requiring additional authentication based on user, device, location, application, and risk level. Examples: require MFA only for risky sign-ins, block access from anonymous VPN sources, require compliant device for finance applications, require phishing-resistant MFA for admins. Essentially mandatory for any organisation beyond the smallest — provides the granular control needed for modern security architecture.