Why MFA Is Not Enough Anymore: Real Microsoft 365 Attack Paths

MFA still matters. Any account without MFA, especially an administrator account, is an avoidable exposure.

The problem is treating MFA coverage as the main measure of identity security. In Microsoft 365 incidents, attackers often do not need to break MFA cryptographically. They need one valid session, one approved prompt, one Conditional Access exclusion, one over-permissioned OAuth app, or one support process that lets them take over the account.

Microsoft Secure Score may show strong MFA adoption. Microsoft Entra ID sign-in logs may show successful MFA. The tenant can still be exposed if a stolen token from an unmanaged device is allowed to reach Exchange Online, SharePoint, Teams, or Microsoft Graph.

The better question is not, "Do we have MFA?" It is, "What can an attacker still do after MFA is present?"

MFA stops many basic credential attacks. It does not reliably stop adversary-in-the-middle phishing.

In this path, the user opens a fake SharePoint, Teams, voicemail, DocuSign, or Microsoft 365 sign-in link. The page proxies the real Microsoft sign-in flow. The user enters the password, completes MFA, and sees a normal result. The attacker captures the authenticated session token or cookie.

From the attacker's perspective, MFA has already succeeded. If Conditional Access allows browser access from unmanaged devices, untrusted locations, or unknown endpoints, the stolen session can be useful until it expires, is revoked, or is blocked by risk and device controls.

Common follow-on actions include:

• Creating inbox rules that hide security alerts, payment discussions, or vendor messages.
• Searching mailbox history for invoices, wire instructions, contracts, and password reset emails.
• Adding or changing authentication methods if registration policies allow it.
• Accessing OneDrive and SharePoint content.
• Sending internal phishing from the compromised account.

The control is not more prompts. Use phishing-resistant authentication, Conditional Access authentication strengths, device compliance requirements for sensitive apps, sign-in risk policies where Microsoft Entra ID P2 is licensed, and a tested token revocation process.

Push-based MFA is convenient, but it can still be abused. After obtaining a password through phishing, credential reuse, infostealer logs, or password spraying, attackers try to get the user to approve access.

Microsoft Authenticator number matching reduces accidental approvals and is now the expected baseline for Microsoft push notifications. It does not eliminate social engineering. Attackers can call a user pretending to be IT, reference a real maintenance window, and coach the user through the approval.

High-risk users should not rely on commodity push MFA. Prioritize phishing-resistant methods for administrators, finance, payroll, executives, help desk staff, and users with access to regulated or customer-sensitive data. Strong options include FIDO2 security keys, passkeys where available, Windows Hello for Business, and Microsoft Entra certificate-based authentication.

Use Conditional Access authentication strengths to require stronger methods for privileged actions and sensitive apps.

MFA deployments often decay through exceptions. A break-glass account is excluded. A legacy workflow is excluded. A public IP range is trusted. A third-party integration is bypassed. A VIP receives a temporary exception that never expires.

Common findings include:

• Policies scoped to "All users" with long exclusion lists and no owner.
• Administrator roles excluded from user policies but not covered by dedicated admin policies.
• Guest users accessing sensitive SharePoint sites with weaker requirements.
• Trusted locations based on broad public IP ranges, including VPN egress used by unmanaged devices.
• Policies that require MFA but do not require compliant devices for high-value apps.
• Service accounts or old clients that keep legacy sign-in paths alive.

MFA coverage is not the same as effective access control. Strong Conditional Access design evaluates the user, role, device, location, application, sign-in risk, user risk, authentication strength, and session controls.

Treat Conditional Access like production infrastructure: document policies, test changes in report-only mode, use named owners for exceptions, set expiration dates for bypasses, and review sign-in logs from an attacker’s perspective.

OAuth abuse is a common Microsoft 365 persistence path. Instead of stealing only a password or session, an attacker convinces a user or administrator to consent to a malicious application. The app may request delegated or application permissions to read mail, read files, send mail, or maintain access through Microsoft Graph.

Once consent is granted, password resets may not remove the access. MFA may not be prompted in the way stakeholders expect. The user may not realize that they authorized ongoing access.

This is most dangerous when users can consent to third-party apps broadly, admin consent is granted without permission review, or enterprise applications and service principals are not monitored.

Reduce the risk by restricting user consent, allowing only verified low-risk permissions where appropriate, using admin consent workflows, reviewing enterprise applications and service principals, monitoring new OAuth grants, and using Microsoft Defender for Cloud Apps app governance capabilities where licensed.

An account-takeover response that only resets the password and requires MFA can leave OAuth persistence untouched.

Attackers target the processes around MFA. If a help desk can reset MFA, add a phone number, issue a Temporary Access Pass, or approve an authentication method change after weak identity proofing, the attacker may not need the original factor.

Review who can manage authentication methods in Microsoft Entra ID. Limit these rights to dedicated administrative roles, use separate admin accounts, and require stronger verification for executives, finance users, administrators, and help desk staff.

Monitor and alert on authentication method registration, deletion, default method changes, Temporary Access Pass creation, and suspicious self-service password reset activity. These events often appear before mailbox abuse or data access.

Some older clients, protocols, and service account patterns do not support the same controls as modern authentication flows. Exchange Online Basic authentication has been broadly disabled by Microsoft, but tenants can still carry risk through SMTP AUTH exceptions, outdated clients, unattended scripts, weak app registrations, and shared accounts.

Inventory non-interactive sign-ins, service principals, SMTP AUTH usage, and accounts excluded from Conditional Access. Replace shared service accounts with managed identities, certificates, workload identity controls, or properly scoped app registrations where possible.

Every exception should have an owner, business justification, compensating controls, monitoring, and a retirement date.

Start with identity hygiene. Use separate admin accounts for administration. Protect privileged accounts with phishing-resistant MFA. Use Microsoft Entra Privileged Identity Management where Microsoft Entra ID P2 is licensed. Keep emergency access accounts cloud-only, intentionally excluded from Conditional Access dependencies, tightly monitored, and tested.

Harden authentication. Move administrators and high-risk users away from basic push approval. Use Conditional Access authentication strengths for privileged roles and sensitive apps. Remove legacy sign-in paths and document any remaining exceptions.

Bind access to trusted conditions. For high-value apps, require compliant devices, Microsoft Entra hybrid joined devices, or approved mobile app protection patterns where appropriate. Do not allow a stolen browser session from an unmanaged device to have the same access as a known corporate endpoint. Use Microsoft Entra ID Protection risk signals when licensed.

Control sessions. Use sign-in frequency, persistent browser session settings, Continuous Access Evaluation-aware apps, Microsoft Defender for Cloud Apps session controls where licensed, and a repeatable process to revoke refresh tokens after compromise.

Monitor the actions attackers use: inbox rules, mailbox forwarding, suspicious sign-in properties, impossible travel, authentication method changes, OAuth consent grants, new service principals, privileged role activations, mass file access, and unusual Microsoft Graph activity.

MFA is one control. The goal is to make stolen credentials, stolen sessions, and tricked users insufficient for meaningful compromise.