When a business discovers that an email account was compromised, one of the first things the owner says is: “We had MFA turned on. How is that possible?” It’s a fair question. Security guidance for years has listed multi-factor authentication as one of the single most effective steps an organization can take. That guidance is correct. MFA is highly effective against a specific category of attack. The problem is that some attacks don’t target the authentication step at all.
What MFA Actually Protects Against
Multi-factor authentication was designed to make a stolen password insufficient on its own. If an attacker obtains a password through phishing, credential stuffing, or another compromise, the attacker still has to satisfy the account’s additional authentication requirement. That makes MFA one of the most effective controls against ordinary credential-based account takeover. MFA materially reduces exposure to attacks that rely on a stolen password alone. The limitation is that some modern attacks target what happens after authentication rather than trying to defeat the second factor itself.
Disabling or deprioritizing MFA because it doesn’t stop everything would be a mistake. The goal is understanding what it does and doesn’t protect, so you know what additional controls belong alongside it.
Where the Gap Is: Attacks That Target the Session, Not the Login
MFA secures the authentication step: the moment you prove you are who you say you are. Once that step succeeds, the platform issues a session token, a credential that tells the application this user has already authenticated. That token is what keeps you logged into your email without re-entering your password and MFA code every five minutes. It is also what certain attacks are now targeting instead of the password.
The attacker sets up a realistic replica of a Microsoft 365 or Google sign-in page, but with a key difference: it’s a real-time proxy. When the target enters their credentials and approves the MFA prompt, the proxy silently relays each step to the legitimate Microsoft or Google server. The server responds normally; authentication succeeds. In the same moment, the proxy captures the authenticated session token that Microsoft or Google issued.
The attacker does not need to defeat MFA directly. They let the target complete a legitimate authentication and capture the resulting session token. Once the attacker obtains a usable authenticated session, they may be able to access the same services and data available through that session without completing MFA again. In a Microsoft 365 environment, that can include email and other cloud resources available to the compromised user.
Microsoft documented a large AiTM campaign in May 2026 in which attackers used multi-stage phishing pages to capture authentication tokens, then used those tokens to access cloud resources without re-authenticating.
A related technique abuses Microsoft’s OAuth Device Authorization flow. The attacker sends a link that directs the target to authenticate on a legitimate Microsoft page for what appears to be a routine approval. In the background, the attacker polls the OAuth token endpoint and captures the access and refresh tokens after the user completes their MFA challenge. Again, the authentication itself was legitimate. The token is what gets stolen.
Both techniques share the same structural characteristic: the attacker is not trying to defeat MFA. They are waiting for the user to complete MFA successfully and then taking the credential the platform issues afterward. Standard MFA has no mechanism to distinguish a legitimate sign-in from one where the resulting token will be captured by a proxy sitting between the user and the platform.
What an Attacker Can Do With a Stolen Session
When an attacker obtains a usable authenticated session token, they may be able to read and export email, send messages as the account owner, create inbox rules that forward incoming mail to an external address, and access files and other cloud resources available to that account without completing MFA again. The organization’s security tools often have no way to distinguish the attacker’s activity from the legitimate user’s until something triggers a review.
The consequences of that kind of access are not theoretical. In 2019, a phishing attack against PIH Health, a California healthcare network, compromised forty-five employee email accounts. HHS later reported that the incident exposed unsecured electronic protected health information belonging to 189,763 individuals, including names, Social Security numbers, diagnoses, lab results, treatment information, and financial information. OCR settled the resulting HIPAA investigation for $600,000 in April 2025, finding violations that included inadequate risk analysis and failure to notify affected individuals within the required timeframe. The government’s notice does not identify the specific attack method used, but the case illustrates how much sensitive information can be exposed once an attacker gains access to business email accounts.
A practice email inbox typically holds appointment confirmations with patient names, referral messages with diagnoses, billing correspondence with insurance and financial details, and attachments ranging from lab results to signed consent forms. A law firm inbox holds matters, client names, and communications that may be privileged. A financial services inbox holds account information, transaction records, and wire instructions. The scope of what an attacker can read, forward, or act on depends entirely on what was in the account and how long the access went undetected.
What to Do When This Happens
Don’t clean up before preserving evidence. The sign-in logs, inbox rules, OAuth application grants, forwarding configurations, and message headers are what you’ll need to reconstruct what the attacker accessed and when. Your IT provider can begin containment and evidence capture in parallel. If the organization is subject to HIPAA or other regulatory obligations, legal or compliance counsel should be notified at the same time.
In Microsoft 365, an administrator can revoke active sign-in sessions and reset the account password. In Google Workspace, the admin console allows sign-out of all active sessions. Revoking sessions terminates sign-in access and forces re-authentication, but may not immediately invalidate all application tokens already issued; your IT provider can confirm full termination and check for persistent app grants that may need to be separately revoked.
Check the compromised account for inbox rules that hide or redirect mail; attackers commonly create rules to delete security alerts, forward a copy of all incoming mail, or move messages into obscure folders to avoid detection. Review OAuth application grants and delegated access for anything the attacker may have added. Document what sensitive information was in the account during the window of unauthorized access, because that scope determines the notification and remediation obligations that follow.
What Actually Stops This Type of MFA Bypass
The most effective control against adversary-in-the-middle phishing is phishing-resistant MFA. FIDO2 hardware security keys and passkeys work by cryptographically binding the authentication to the specific legitimate site. When a phishing proxy tries to relay the authentication to Microsoft or Google, the authentication is cryptographically bound to the legitimate service, preventing the phishing proxy from successfully relaying that authentication in the same way. Standard push notifications, one-time codes, and SMS codes don’t have this property, which is why they can be relayed in real time. Both Microsoft 365 and Google Workspace support FIDO2 and passkeys natively. Note that phishing-resistant MFA specifically addresses AiTM-style attacks; a compromised endpoint with malware capable of stealing cookies directly from the browser represents a separate threat surface.
Conditional Access can add another layer by evaluating the context of each sign-in and enforcing stronger requirements when appropriate. Organizations can require phishing-resistant authentication methods, restrict access to compliant or managed devices, and apply policies based on user, device, location, application, or sign-in risk. What is available depends on the organization’s Microsoft 365 licensing tier and what has been configured. An organization can have the right licensing and still have no Conditional Access policies in effect.
Monitoring for suspicious activity closes a gap that preventive controls alone don’t cover. Unusual sign-in behavior, atypical travel, unexpected changes to inbox rules, and suspicious forwarding activity can all provide indicators that an account has been compromised. Microsoft 365 and Entra ID generate much of this telemetry, but the signals only help if they are being collected, reviewed, and acted on.
Frequently Asked Questions
MFA remains one of the highest-impact security controls available to small and mid-sized organizations. Disabling MFA because it doesn’t stop every attack would leave organizations exposed to the much larger volume of password-based account takeovers it does prevent. The goal is layering additional controls on top of MFA, not replacing it.
The same way they end up on any phishing page: a convincing email with a link. The phishing proxy pages used in these attacks are often visually indistinguishable from the real Microsoft or Google sign-in experience. The URLs are different, but users who haven’t been trained to check URLs carefully, or who are using a mobile device where the full URL isn’t visible, routinely complete the sign-in without noticing. The attack doesn’t require any technical error by the user. It just requires that they click a link and log in, which is a normal daily activity.
Standard Microsoft 365 settings with push-notification MFA enabled provide meaningful protection but leave the session-hijacking gap open. Closing it requires deploying phishing-resistant MFA methods (FIDO2 or passkeys), configuring Conditional Access policies that enforce device compliance and session lifetime limits, and enabling the audit logging and anomaly detection that would catch a compromise in progress. Many organizations on Microsoft 365 have the right licensing for these features but haven’t configured them. Reviewing the current configuration against what’s available in your license tier is the right starting point.
Vision Quest Cyber helps Greater Sacramento businesses assess their Microsoft 365 and Google Workspace security configurations, deploy phishing-resistant authentication, and set up monitoring designed to detect suspicious account activity before it becomes a larger incident.
