How MFA is Being Bypassed in Microsoft 365

Multi-factor authentication is widely deployed across Microsoft 365 tenants. Yet account compromise continues at scale. 

This is not because MFA does not work. It is because attackers have largely stopped trying to defeat authentication itself. 

Instead, they operate after authentication. Session tokens, OAuth grants, and quiet configuration changes give attackers what they need to persist without triggering obvious alerts. Over the last 18 months, Microsoft and third-party threat research have shown this pattern repeatedly. MFA is being bypassed without being broken. 

This helps explains why organizations with strong password policies and universal MFA enforcement still experience business email compromise and lateral account abuse. 

Business Email Compromise Remains a High-Impact Risk 

Business email compromise continues to be one of the costliest cybercrime categories globally. 

According to the FBI, BEC accounts for billions in reported losses each year. Most incidents are tied to invoice fraud, wire transfer redirection, and vendor impersonation. 

The attack sequence is consistent across industries: 

• A user mailbox is compromised
• The attacker remains inactive to avoid detection
• Existing email threads and financial workflows are quietly monitored
• Legitimate conversations are hijacked at the moment of payment or approval

This is not opportunistic phishing. It is deliberate, context-aware fraud that depends on prolonged access inside Microsoft 365 mailboxes. 

That persistence is exactly what modern MFA bypass techniques are designed to enable. 

Why MFA Alone Does Not Stop Modern Microsoft 365 Attacks 

Session Theft Enables MFA Bypass Without Credential Theft 

Adversary-in-the-middle phishing attacks intercept legitimate Microsoft sign-in flows in real time. Users authenticate successfully, complete MFA, and receive valid sessions tokens. Attackers capture those tokens and reuse them from another device or location. 

At that point: 

• Passwords are no longer required
• MFA challenges are not triggered again
• Sign-ins appear successful and legitimate in logs

MFA protects the moment of sign-in. It does not protect the session that follows unless additional controls are in place. 

OAuth Consent Attacks Create Persistent Access Paths

OAuth consent phishing relies on users approving access for malicious applications. These applications impersonate legitimate services. Once consent is granted, they gain API-level access to mail, files, and calendar data. 

After consent is approved: 

• Password resets do not revoke access
• MFA re-registration does not remove access
• Mailbox rules and user behavior may appear unchanged

This attack path persists until enterprise application permissions are explicitly reviewing and revoked. That is why it often survives standard incident response steps. 

MFA Fatigue Still Works at Scale 

Push-based MFA remains vulnerable to approval fatigue. Repeated prompts increase the chance of accidental approval, especially during high-volume work periods or off-hours. 

Microsoft guidance now treats number matching as a baseline control rather than an optional enhancement. It directly reduces unintended approvals without adding session complexity. 

What Attackers Do After Access is Gained 

Once inside a tenant, attackers prioritize persistence and invisibility over speed. The goal is to stay present without disrupting normal activity or triggering security controls. 

Common post-compromise actions include: 

• Mailbox rules created to suppress security notifications or hide specific messages
• External auto-forwarding configured for quiet, ongoing data exfiltration
• Additional authentication methods added to maintain independent access
• OAuth applications registered to preserve long-term control

These techniques allow attackers to remain embedded long enough to observe financial workflows and impersonate legitimate activity. The longer they stay undetected, the less likely compromise triggers an immediate investigation. 

Microsoft 365 Security Baseline for Modern Identity and Token-Based Attacks

These controls focus on where modern attacks actually succeed, not just how they begin. 

Adopt Phishing-Resistant Authentication

Phishing-resistant authentication methods reduce exposure to adversary-in-the-middle attacks. They work by removing browser-bound credentials from the authentication flow. 

These methods include: 

• FIDO2 security keys
• Windows Hello for Business
• Certificate-based authentication
• Passkeys

Authentication occurs outside the browser session. This prevents tokens from being captured or replayed by phishing infrastructure, even after the user completes a legitimate sign-in. 

Bind Session Tokens to Devices with Conditional Access

Conditional Access Token Protection binds Microsoft Entra session tokens to a specific device. If a token is copied and replayed from another device or location, access fails. 

This control targets session theft directly rather than attempting to stop the initial phishing event. 

Apply Risk-Based Access Controls in Entra ID Protection

Risk-based access policies trigger automated responses when sign-ins show patterns tied to token theft or anonymized infrastructure. 

This approach is effective at detecting: 

• Session reuse from unfamiliar environments 
• Atypical sign-in behavior that completes successfully
• Access patterns that would otherwise appear legitimate in logs

Risk-based enforcement adds friction where it matters most, without treating all users or all sign-ins the same. 

Remove External Auto-Forwarding as a Default Capability 

External auto-forwarding remains one of the most reliable BEC persistence mechanisms. Disabling it tenant-wide and granting scoped exceptions removes a low-visibility data exfiltration path that attackers consistently abuse. 

Strengthen Defender for Office 365 Email Protections

Impersonation protection, Safe Links, and Safe Attachments reduces the volume of successful phishing attempts that reach inboxes. These controls do not prevent MFA bypass on their own. However, they reduce exposure to the attack paths that lead to token theft and consent abuse. 

Control OAuth Consent and Govern Enterprise Applications

OAuth abuse does not surface through mailbox rules or traditional email indicators. It persists at the application and token level. 

Controls should include: 

• Restricting user consent to verified publishers and low-risk scopes
• Requiring admin approval for broad or persistent permissions
• Regular review of enterprise applications with defined ownership and removal criteria

Effective app governance closes a persistence channel that standard account remediation does not address. 

Remove Conditions that Enable MFA Fatigue

Push-based MFA remains susceptible to accidental approval under repeated prompting. To reduce fatigue-driven acceptance without adding unnecessary friction: 

• Enforce number matching as a baseline

• Monitor for repeated failed challenges

• Limit approval-only methods where possible 

Security failures in Microsoft 365 are rarely caused by a single missing control. More often, they come from assumptions about where authentication ends and how trust is maintained afterward. 

MFA remains foundational. But its effectiveness depends on what surrounds it. Modern attacks operate inside authenticated sessions. They rely on stolen tokens, delegated access, and quiet persistence rather than credential misuse. 

Organizations that design controls with these realities in mind reduce both the likelihood and impact of compromise. Prioritizing session integrity, consent governance, and post-authentication visibility strengthens the tenant without adding unnecessary complexity. 

Interested in understanding how these risks apply to your Microsoft 365 environment or learning more about our Security Assessment? The Sourcepass MCOE team can help you identify gaps across sessions, tokens, and OAuth access.