Why Microsoft 365 Accounts Get Compromised (And How to Stop It)

Microsoft 365 accounts get compromised because attackers do not need to break in. They walk in. Stolen tokens bypass MFA. OAuth apps persist after passwords are reset. Legacy authentication skips modern security entirely. Understanding which attack path was used is the only way to properly contain and prevent the next one.

Why Microsoft 365 Is the Primary Target

Microsoft 365 centralises everything behind a single cloud identity.

Email, files, Teams, SharePoint, OneDrive, and every connected SaaS application all authenticate through one account. For a business, that consolidation is efficient. For an attacker, it means one compromised password or stolen token gives access to everything.

Attackers do not need sophisticated exploits. They need one thing: access to your Microsoft 365 credentials or session tokens. Once they have that, the rest of the attack runs inside Microsoft’s own platform using legitimate tools.

The ASD Cyber Threat Report 2024 identified Business Email Compromise as one of the top three cybercrime categories by financial impact on Australian businesses. BEC almost always begins with a Microsoft 365 account compromise.

Attack Path 1: Phishing With AiTM Token Capture

This is the most dangerous and most misunderstood attack path in 2026.

Traditional phishing steals your password. AiTM (adversary-in-the-middle) phishing does something much worse. It steals your session token after you have already completed MFA.

Here is exactly how it works:

Step 1: You receive a phishing email with a link that looks like a Microsoft login page.

Step 2: The link actually leads to an attacker-controlled proxy that sits between you and the real Microsoft login.

Step 3: You enter your credentials and complete MFA normally. The real login succeeds.

Step 4: The attacker’s proxy captures your session cookie, which is the token that proves to Microsoft you have already authenticated.

Step 5: The attacker replays that session cookie from their own device. Microsoft sees a valid, authenticated session and grants access.

Your password was never stolen. You completed MFA correctly. The attacker still has full access to your account.

This is why resetting the password after a compromise does not fix the problem. The attacker’s session token remains valid until it is explicitly revoked.

Phishing toolkits like Evilginx and Modlishka have automated this attack. Non-technical attackers can run AiTM campaigns with minimal skill.

How to block it: Phishing-resistant MFA (FIDO2 passkeys, Windows Hello for Business, hardware security keys) is the only authentication method that defeats AiTM at the credential layer. Unlike push notifications or TOTP codes, phishing-resistant MFA is cryptographically bound to the legitimate Microsoft domain. An AiTM proxy cannot intercept it. See our conditional access policy examples for implementing phishing-resistant MFA in Entra ID.

Attack Path 2: MFA Fatigue Push Bombing

This attack works without any technical sophistication. It relies entirely on human patience running out.

How it works:

An attacker has your Microsoft 365 credentials, either from a previous breach, a password spray attack, or a phishing campaign that captured your password but not your MFA code.

They trigger repeated MFA push notification requests to your phone, sometimes dozens in quick succession. At 11pm when you are trying to sleep, or during a meeting when you just want the notifications to stop, you approve one.

That single approval is all they need.

Reported MFA fatigue attacks against Australian businesses increased significantly in 2024. The attack works because standard push-based MFA without number matching provides no context about what is being approved. The user sees “Approve” or “Deny” with no information about which login attempt triggered the notification.

How to block it: Enable number matching in Microsoft Authenticator. With number matching, the login screen shows a two-digit number and the user must enter that same number in the authenticator app to approve. An attacker triggering a push request from a different device will show a different number. The user will notice the mismatch. For high-value accounts, move to FIDO2 passkeys entirely. Our Entra ID Protection guide covers the Conditional Access configuration.

Attack Path 3: OAuth Application Consent Abuse

This is the attack path that survives remediation most often. Many businesses “remediate” a compromise, reset passwords, revoke sessions, and declare the incident closed. Two weeks later the attacker still has access. OAuth is usually why.

How it works:

The attacker sends a phishing email or creates a convincing fake Microsoft app. The user is prompted to grant an application access to their Microsoft 365 data, specifically mail, calendar, contacts, files, or directory data.

The user clicks Accept, assuming it is a legitimate business application.

The attacker’s application now has an OAuth token granting it access to that user’s data. This token is independent of the user’s password and MFA state. Resetting the password does not revoke it. The application continues to access the mailbox, read emails, forward messages, and exfiltrate data long after the incident is considered resolved.

OAuth consent abuse is sometimes called “illicit consent grant” in Microsoft security documentation. It is one of the most common long-lived persistence mechanisms in compromised tenants.

How to block it: In the Entra Admin Centre, restrict user consent to verified publishers and low-risk permissions. Require administrator approval for any application requesting access to sensitive scopes (mail, calendar, files, directory). Audit all enterprise applications in your tenant regularly. Remove any application that is not recognised or no longer needed. See our shadow IT risks guide for the broader risk of unapproved applications in your environment.

Attack Path 4: Legacy Authentication Exploitation

Legacy authentication protocols, including POP3, IMAP, SMTP AUTH, and older Office client authentication, do not support modern MFA challenges. They were designed before multi-factor authentication existed.

An attacker using a legacy authentication client can initiate a login using only a username and password. No MFA prompt is sent. No second factor is required.

This means that even if your Microsoft 365 tenant requires MFA for all users through Conditional Access, a single legacy authentication pathway completely bypasses that requirement.

Many businesses block legacy authentication for standard logins but leave it active for specific applications. Shared mailboxes accessed via IMAP. Multifunction printers that email via SMTP AUTH. CRM systems with old Office connectors. Each one is an open door.

According to Microsoft’s own telemetry, more than 99% of password spray attacks and a significant proportion of credential stuffing attacks target legacy authentication endpoints specifically, because attackers know MFA cannot intervene.

How to block it: Create a Conditional Access policy blocking all legacy authentication for all users with no exceptions. Use the sign-in logs in Entra ID to identify any legacy authentication traffic before enabling the block. Address each application or device generating legacy authentication traffic individually, either by updating to modern authentication or by configuring an alternative. A Conditional Access policy blocking “Other clients” and “Exchange ActiveSync clients” closes this path entirely.

Attack Path 5: Password Spray Using Breached Credentials

Password spray attacks attempt a small number of common passwords against a large number of accounts. Credential stuffing attacks test actual username and password combinations harvested from previous breaches.

Microsoft 365 accounts are heavily targeted by both. Attackers purchase breach databases containing millions of email address and password combinations. They test these credentials automatically against Microsoft 365 tenants because a valid Microsoft 365 login is extremely valuable.

Even with MFA in place, a valid password shortens the attack timeline. Combined with MFA fatigue, AiTM, or a legacy authentication path, a reused password can still lead to a full account compromise.

How to block it: Enable Entra ID Password Protection to ban common passwords and custom banned password lists. Enable Microsoft Entra ID Smart Lockout so accounts are temporarily locked after repeated failed login attempts. Entra ID Protection (included in Business Premium via the P1 licence) flags accounts that appear in known breach databases and can require them to reset passwords automatically. Enforce a minimum password length of 12 characters with complexity requirements.

What Happens After an Account Is Compromised

Attackers rarely move to fraud the moment they gain access. The more profitable approach is to stay hidden, observe, and act at precisely the right moment.

The typical post-compromise sequence:

Stage 1: Establish persistence quietly. The attacker creates inbox rules to automatically delete or redirect incoming emails that might alert the legitimate user. They register an additional authentication method to the account. They grant an OAuth application persistent access. These actions happen within the first hours of access and are designed to go unnoticed.

Stage 2: Observe and learn. The attacker monitors the mailbox. They read email threads about pending invoices, payment workflows, vendor relationships, payroll schedules, and executive approvals. This observation phase can last weeks. The attacker is building intelligence, not committing fraud yet.

Stage 3: Act at the right moment. Once the attacker understands how payments are processed and who approves them, they insert themselves at a precise moment. A supplier invoice arrives. The attacker intercepts it, changes the bank account details, and sends it on. A payroll change request is intercepted and the account details are substituted. An executive approval is impersonated.

By the time the fraud is discovered, days or weeks have passed. Multiple transactions may have been redirected. The attacker has already exited.

Most BEC attacks are discovered when a genuine supplier follows up on an unpaid invoice or when a bank queries an unusual transfer. By that point, the money has moved through multiple accounts and is extremely difficult to recover.

How to Know If Your Microsoft 365 Account Is Compromised

These are the indicators to look for:

Inbox rules you did not create. Rules that delete specific emails, forward messages to external addresses, or mark security alerts as read and file them away are a primary compromise indicator. Check inbox rules in Outlook Settings immediately if you suspect a compromise.

Sign-in activity from unfamiliar locations or devices. In Entra ID, review the sign-in logs for the affected account. Look for successful logins from countries where the user does not operate, from devices not in your Intune inventory, or at times outside the user’s normal working hours.

Applications you do not recognise. In Entra ID, review the user’s application consent grants. Any application you do not recognise that has mail or files access should be revoked immediately and investigated.

Emails you did not send. Check the Sent Items folder. Attackers sending phishing emails or BEC emails from a compromised account sometimes leave traces in Sent Items.

Password reset or MFA method changes you did not initiate. An alert for a new authentication method registration or a password reset you did not request is a confirmed compromise indicator.

Our mailbox auditing in Exchange Online guide covers the audit log configuration that makes these indicators detectable.

What to Do When a Microsoft 365 Account Is Compromised

Speed matters. Every hour of delayed response extends the attacker’s access and observation window.

Step 1: Revoke all active sessions immediately. In the Entra Admin Centre, go to the affected user’s profile and click Revoke Sessions. This invalidates all current session tokens, including any the attacker holds. This is the step most businesses skip. Resetting the password without revoking sessions leaves the attacker’s session active.

Step 2: Reset the password. After revoking sessions, reset the password to a strong unique value.

Step 3: Review and remove inbox rules. Open Outlook for the affected account and check All Settings for any rules that were not created by the user.

Step 4: Review and revoke OAuth application permissions. In Entra Admin Centre, check My Applications for the affected user and remove any applications that are unrecognised or no longer needed.

Step 5: Review authentication methods. Confirm that only the user’s legitimate MFA methods are registered. Remove any method that was not set up by the user.

Step 6: Review sign-in logs for the scope of access. Use the Entra ID sign-in logs and the Exchange Online audit log to determine what data was accessed and when. This scoping is required for any Privacy Act NDB assessment.

Step 7: Assess NDB obligations. If personal information held in the mailbox or connected applications was accessed, a Notifiable Data Breach assessment is required under the Privacy Act 1988. If the assessment concludes that serious harm is likely, notification to the OAIC and affected individuals must follow.

The Fastest Wins: Controls That Stop Most M365 Compromises

These are the settings that have the highest impact and are included in Microsoft 365 Business Premium at no extra cost.

Block legacy authentication via Conditional Access. Single policy, blocks entire categories of credential attacks.

Enable number matching in Microsoft Authenticator. Simple configuration change that defeats MFA fatigue attacks immediately.

Restrict user OAuth consent to verified publishers. Prevents OAuth abuse without impacting legitimate application use.

Require compliant devices for sensitive data access. Blocks access from unmanaged personal devices that carry higher compromise risk.

Enable Entra ID Protection. Provides risk-based sign-in policies that challenge or block logins matching attacker behaviour patterns automatically.

Enable mailbox auditing. Confirms that forensic evidence will be available if a compromise is later discovered.

For the full Conditional Access policy configuration, see our conditional access policy examples. For the identity governance framework these controls sit within, see our what is identity and access management guide.

Australian Compliance: Why M365 Compromise Has Legal Consequences

Privacy Act 1988 and Notifiable Data Breaches

A compromised Microsoft 365 mailbox that contains client personal information, employee records, health information, or financial data is a potential Notifiable Data Breach under the Privacy Act 1988.

The OAIC requires organisations to notify affected individuals and the OAIC when they believe a breach is likely to result in serious harm. The assessment must happen promptly. Delay in identifying or reporting an eligible breach can increase regulatory exposure.

The practical challenge: without mailbox audit logging in place before the compromise, it is extremely difficult to determine exactly what an attacker accessed and for how long. This pushes organisations toward a conservative NDB assessment that assumes all mailbox content was exposed.

Essential Eight

The Essential Eight Multi-Factor Authentication control at Maturity Level 2 and above requires phishing-resistant MFA for privileged accounts. The control at Maturity Level 3 extends this requirement to all accounts. AiTM-resistant MFA methods (FIDO2, Windows Hello for Business) are the specific implementations that satisfy this requirement.

The Restrict Administrative Privileges control requires that admin accounts are separate from standard user accounts and that admin access is used only for administrative tasks. A compromised standard user account that also holds admin privileges gives an attacker immediate administrative access to the entire Microsoft 365 tenant.

For the full Essential Eight mapping, see our Essential Eight checklist.

Microsoft 365 Account Compromise Checklist

Use this to audit your current Microsoft 365 security posture.

Prevention:

• All users enrolled in MFA via Conditional Access (not legacy per-user MFA)
• Number matching enabled in Microsoft Authenticator for all users
• Phishing-resistant MFA required for all admin accounts
• Legacy authentication blocked via Conditional Access for all users
• User OAuth consent restricted to verified publishers and low-risk permissions
• Admin approval required for application consent to sensitive scopes
• Entra ID Password Protection enabled with custom banned password list
• Entra ID Protection enabled with risk-based sign-in policies

Detection:

• Mailbox audit logging confirmed active in Microsoft Purview for all users
• Entra ID sign-in logs retained for at least 30 days (90 days with P1 licence)
• Alert policy active for new inbox rule creation in any mailbox
• Alert policy active for new MFA method registration
• Alert policy active for external mail forwarding configuration
• Impossible travel or unfamiliar location sign-in alerts configured

Response readiness:

• Incident response runbook documents the M365 account compromise response steps
• Entra Admin Centre access confirmed for all IT team members
• Session revocation procedure tested and documented
• NDB assessment process documented and assigned to a named owner

Related Reading

• Conditional Access Policy Examples – The specific policies that block each attack path described in this article
• Entra ID Protection – Risk-based identity protection that detects and blocks compromise attempts automatically
• Mailbox Auditing in Exchange Online – The audit configuration that makes M365 compromise investigations possible
• Spear Phishing vs Phishing – Understanding the phishing techniques that initiate most M365 compromises
• What Is Identity and Access Management – The broader IAM framework that M365 security sits within
• How Security Monitoring Works – Detecting M365 compromise through SIEM and security monitoring
• Microsoft 365 Security – The complete M365 security configuration guide
• Microsoft Teams Security Best Practices – Securing the Teams environment that attackers also target after M365 compromise

Frequently Asked Questions

Why do Microsoft 365 accounts get compromised even with MFA enabled?

MFA in Microsoft 365 gets bypassed in three main ways. AiTM phishing captures your session token after MFA completes, giving the attacker a valid authenticated session without needing your MFA code. MFA fatigue attacks flood your phone with push notifications until you approve one, which requires no technical skill to execute. Legacy authentication protocols bypass MFA entirely because they do not support modern authentication challenges. Addressing all three requires phishing-resistant MFA for high-risk accounts, number matching for all push-based MFA, and a Conditional Access policy blocking all legacy authentication.

What is AiTM phishing and why is it so dangerous?

AiTM (adversary-in-the-middle) phishing uses a proxy server that sits between you and the real Microsoft login page. When you enter your credentials and complete MFA, the proxy captures your session cookie, which is the token Microsoft uses to confirm you are already authenticated. The attacker replays that session cookie from their own device and gains full access to your Microsoft 365 account. Your password was not stolen. You completed MFA correctly. The attack still succeeded. This is why standard MFA does not stop AiTM, and why phishing-resistant MFA (FIDO2 passkeys, Windows Hello for Business) is required to defeat this attack at the authentication layer.

Is resetting the password enough to recover from an M365 compromise?

No. Resetting the password does not invalidate active session tokens. An attacker who captured a session token through AiTM phishing or obtained one through other means continues to have access to the account after the password is changed, because their session token remains valid. The first action in any M365 compromise response must be session revocation in the Entra Admin Centre, not password reset. After revoking all sessions, reset the password, remove malicious inbox rules, revoke OAuth application permissions, and verify that no additional authentication methods were registered by the attacker.

What is OAuth consent abuse in Microsoft 365?

OAuth consent abuse occurs when an attacker tricks a user into granting an application access to their Microsoft 365 data, typically mail, files, contacts, or directory information. Once the user approves the consent prompt, the attacker’s application receives an OAuth token that grants ongoing access to the user’s data. This token is independent of the user’s password and MFA state. Resetting the password and revoking sessions does not revoke OAuth application permissions. The attacker’s application continues to access the mailbox until the OAuth permission is explicitly revoked in the Entra Admin Centre. OAuth consent abuse is one of the most common reasons a “remediated” compromise recurs.

Does Microsoft 365 account compromise trigger Privacy Act obligations in Australia?

It may. If a compromised Microsoft 365 mailbox contained personal information, including client details, employee records, health information, or financial data, the organisation must assess whether the breach is likely to result in serious harm under the Notifiable Data Breaches scheme. If the assessment concludes serious harm is likely, the OAIC and affected individuals must be notified. The assessment must happen promptly after the organisation becomes aware of the breach. Without mailbox audit logging in place before the compromise, determining exactly what an attacker accessed is very difficult, which typically results in a conservative NDB assessment that treats all mailbox content as potentially exposed.

How do attackers use a compromised Microsoft 365 account?

After gaining access, attackers typically go through three stages. First, they establish persistence by creating inbox rules to hide their activity, registering additional authentication methods, and granting OAuth applications persistent access to the mailbox. Second, they observe the mailbox for weeks, reading email threads about payment workflows, invoice approvals, vendor relationships, and executive communications. Third, they act at a precisely chosen moment, often intercepting a payment request and substituting bank account details, impersonating an executive to authorise a fraudulent transfer, or redirecting a payroll change. The observation phase is what makes BEC attacks so financially damaging. By the time fraud is discovered, significant funds have already moved.