How to Stop MFA Bypass and Cookie Theft on Microsoft 365

If your security strategy assumes that multi-factor authentication is the line that stops account takeover, you are working from a 2019 threat model. In 2026, attackers do not break MFA. They sidestep it by stealing the session cookie Microsoft hands out after you complete MFA, then signing in as you with no password and no second factor required.

Microsoft tracks more than 600 million identity-based attacks per day, and adversary-in-the-middle (AiTM) phishing combined with session token theft is the fastest-growing category. Off-the-shelf phishing kits such as Evilginx, EvilProxy, Tycoon 2FA, and Rockstar 2FA are sold on Telegram for $200 to $500 a month. They turn MFA bypass into a point-and-click operation that any moderately motivated attacker can run.

The good news is that you can defend against every form of this attack today, using tools you almost certainly already pay for in your Microsoft 365 licensing. This guide is the playbook for doing so. It is organized in three layers: user training, security settings, and detection and response. Work through each layer in order, and you will close the gap that AiTM and token theft exploit.

---

The Short Version of How the Attack Works

Before the defenses make sense, it is worth understanding what they are defending against. There are three forms of MFA bypass in active use against Microsoft 365 tenants right now.

Adversary in the middle. The user clicks a phishing link that points to a reverse proxy run by the attacker. The proxy fetches Microsoft's real login page in real time and shows it to the victim, character for character. The victim types their password. The proxy forwards it to Microsoft. Microsoft prompts for MFA. The victim approves the push or types the code. The proxy forwards that, too. Microsoft authenticates successfully and sets the session cookie, and that cookie passes through the proxy on its way to the victim's browser. The attacker captures it and replays it from their own machine. No password is needed. No further MFA is requested.

Infostealer malware. If a user device is infected with commodity infostealer malware such as LummaC2, Vidar, RedLine, or StealC, every browser cookie on the device is exfiltrated within seconds. That dump is sold for as little as $10 per session on underground markets. The buyer imports the cookies into their own browser and is now signed in to the victim's Microsoft 365 tenant without any phishing email or MFA prompt at all.

MFA fatigue. The attacker already has the password, usually from a credential dump. They trigger MFA push notifications repeatedly until the exhausted victim approves one just to make it stop. This is how Uber was breached in 2022 and the pattern remains in active use, especially against help desk staff who clear notifications quickly.

The defenses below address all three. None of them require new licensing if you are on Microsoft 365 Business Premium or Entra ID P1 or higher.

---

Layer 1: User Training

Technology can do most of the work, but it cannot do all of it. Users still see phishing emails before any technical control engages, and the form those emails take in 2026 looks nothing like the broken English and obvious typos most security training was built around.

1. Teach the URL Inspection Habit

The only reliable visual giveaway of an AiTM phishing site is the URL. The page itself is the real Microsoft login page, proxied through the attacker's server, so logos, fonts, and form fields all look perfect. Train every employee on a single, consistent rule: before entering any Microsoft password, look at the address bar and confirm the domain ends in login.microsoftonline.com or login.microsoft.com. Anything else, including lookalike domains such as login.micros0ft.com or microsoft-login.security-team.io, is a fake.

Run this drill quarterly. Real-world phishing simulations from KnowBe4, Hoxhunt, or Microsoft Attack Simulation Training can measure who is actually checking and who is clicking through reflexively.

2. Make Password Managers the Default

A password manager will not auto-fill credentials on a fake domain. The mismatch between the saved entry's URL and the attacker's URL prevents the password from appearing at all. This single behavior, more than any training session, will catch AiTM phishing attempts at the moment of attack.

Standardize on 1Password Business, Bitwarden Enterprise, or the password manager built into Microsoft Edge for Business. Mandate that all corporate passwords live in the manager and that auto-fill is the only acceptable way to log in.

3. Establish a "Never Approve Unexpected MFA" Rule

If an MFA prompt arrives on a phone or authenticator app and the user was not actively trying to sign in, the answer is always deny, then change the password immediately. Make this a written policy and reinforce it in training. The cost of a false-negative deny is a 30 second re-authentication. The cost of a false-positive approve is a breach.

For organizations still using push notifications, enable number matching in Microsoft Authenticator. This forces the user to type a number shown on the sign-in screen into the app, which defeats fatigue attacks where the user just taps approve to dismiss notifications.

4. Train on the New Phishing Channels

Phishing no longer arrives only as an email with a link. In 2026, the highest-success-rate channels are:

• Microsoft Teams external chat messages. Attackers compromise one tenant, then use the federated chat feature to message users at other tenants with malicious links. Most users assume Teams messages are internal and safe
• QR codes in PDF attachments and printed materials. Often called quishing. The QR code points to a phishing URL on the user's personal phone, which is typically outside enterprise security controls
• Microsoft Forms and SharePoint sharing links. Because the link genuinely originates from a Microsoft domain, email filters and users alike give it benefit of the doubt
• Calendar invites with phishing links in the description field. These bypass many email security gateways that scan only the body of the message

Cover each channel in security awareness training and run periodic simulations that use all four, not just email.

5. Build a No-Blame Reporting Culture

The single most valuable detection signal is a user reporting "I think I clicked something I should not have." If users fear being scolded or fired for reporting a mistake, you lose that signal entirely and the attacker gets hours of head start.

Deploy the Microsoft "Report Message" or "Report Phishing" add-in across all of Outlook. Make the reporting button easy to find and the response from IT supportive rather than punitive. Publish metrics on report volume, not on who clicked, so the culture is about catching attacks together rather than blaming individuals.

---

Layer 2: Security Settings in Microsoft 365 and Entra ID

Most of the technical defenses live in Entra ID Conditional Access. If your tenant does not have Conditional Access policies configured, that is the highest-priority project on your security roadmap, ahead of almost any other security investment.

6. Roll Out Phishing-Resistant MFA

Three authentication methods qualify as phishing-resistant under current CISA and Microsoft guidance:

• FIDO2 security keys such as YubiKey 5 series, Feitian, or Google Titan. The key cryptographically signs a challenge tied to the exact origin URL, so a proxy on a different domain cannot solicit a valid signature
• Passkeys in Microsoft Authenticator, Windows Hello for Business, or Apple Platform SSO. The same cryptographic binding applies, but the private key lives in the device TPM or secure enclave and is unlocked locally with biometrics or a PIN
• Certificate-based authentication, where a client certificate delivered through Intune authenticates the device itself to Microsoft

Issue FIDO2 keys to every Global Administrator, Privileged Role Administrator, and account with elevated permissions. This is non-negotiable. These accounts are the ones attackers want, and the cost of a YubiKey is roughly $50. Enable passkeys for the general user population once admins are covered.

7. Block Legacy Authentication Tenant-Wide

Legacy authentication protocols such as POP, IMAP, basic SMTP, and older Exchange clients cannot enforce MFA at all. They are the easy back door. Create a Conditional Access policy that blocks legacy authentication for all users, and audit your sign-in logs for any successful legacy auth events in the last 90 days before flipping the block so you do not break a forgotten service account.

8. Require Compliant or Hybrid-Joined Devices

Configure Conditional Access to require a compliant or Entra-hybrid-joined device for access to Exchange Online, SharePoint Online, and Teams. A stolen cookie replayed from an attacker machine fails the device check, even when the cookie itself is valid. This is the single most effective defense against the infostealer pathway, because attacker machines are never on your Intune compliance roster.

9. Enable Token Protection

Microsoft's Token Protection feature in Conditional Access binds refresh and session tokens to the originating device. A token replayed from a different machine fails authentication entirely. Token Protection is generally available for Exchange Online, SharePoint Online, and Microsoft Graph in desktop applications, with broader coverage rolling out through 2026. Pilot it with a small group first, then expand to high-risk apps.

10. Turn On Continuous Access Evaluation

Continuous Access Evaluation allows token revocation in near real time when a risk event is detected, such as a password reset, account disable, location anomaly, or IP risk. Without CAE, a stolen session token remains valid for the full lifetime of the access token, typically an hour, even after the account is disabled. CAE is on by default in newer tenants but should be verified and explicitly required in Conditional Access policies.

11. Enable Identity Protection Sign-In Risk Policies

If you have Entra ID P2 (included in Microsoft 365 E5 or available as a standalone add-on), enable sign-in risk and user risk policies in Identity Protection. These automatically require additional verification or block sign-ins flagged as high-risk based on Microsoft's threat intelligence, which sees signals from every other tenant globally. Combined with the device compliance policy, this catches the vast majority of attempted token replays.

12. Restrict User Consent to Third-Party OAuth Apps

OAuth phishing is the next attack vector after AiTM matures. Attackers register malicious apps and trick users into granting them permissions to read mail, send mail, or access files. Once consented, the app does not need a password or session cookie. It has its own access through OAuth tokens.

In Entra ID under Enterprise Applications, set user consent for applications to "Allow user consent for apps from verified publishers, for selected permissions" or, for higher-security environments, "Do not allow user consent." Implement an admin consent workflow so users can request access to legitimate apps without being able to grant it themselves.

13. Reduce Token Lifetimes for High-Risk Scenarios

For administrators and accounts that touch sensitive data, configure sign-in frequency in Conditional Access to require re-authentication every 4 to 12 hours. This shortens the window in which a stolen token is useful. For the general user population, leaving default lifetimes in place is fine, since aggressive re-authentication frustrates users and drives security workarounds.

---

Layer 3: Detection, Response, and Hygiene

14. Deploy EDR That Catches Infostealers

Microsoft Defender for Endpoint, CrowdStrike Falcon, or SentinelOne. Any of the major endpoint detection and response platforms will catch LummaC2, RedLine, and StealC variants before the cookie theft completes. Basic antivirus is not sufficient. Infostealers are specifically tested against signature-based detection and are updated faster than signatures can catch up.

Pair EDR with a managed detection and response (MDR) service so detections are investigated at 2 AM, not just logged for someone to find on Monday morning.

15. Monitor for Anomalous Sign-Ins

Configure alerts in Microsoft Defender for Cloud Apps (or your SIEM) for:

• Impossible travel between sign-in locations
• Sign-ins from anonymizing IP addresses or known malicious networks
• Mass file downloads from SharePoint or OneDrive
• Inbox rules that auto-forward or auto-delete email (a common attacker persistence technique)
• OAuth app consent events for any non-verified publisher

The first 30 minutes after a token theft is the highest-value window for response. Automated alerts are what make a 30 minute response possible.

16. Tighten Browser and Endpoint Hygiene

• Standardize on Microsoft Edge for Business or Chrome with enterprise policies. Both support managed configurations that prevent users from disabling SmartScreen, installing arbitrary extensions, or syncing personal cookies into corporate browser profiles
• Block unmanaged browser extensions through Intune policy. Malicious extensions are an emerging infostealer delivery vector
• Encourage users to keep work and personal browsing in separate browser profiles. A personal Chrome profile with 47 extensions is the path of least resistance for cookie theft on the same device

17. Plan for the Compromise You Did Not Prevent

Even the best defenses occasionally fail. Have a written incident response runbook for token theft that includes:

• Disable the account in Entra ID
• Revoke all refresh tokens for the account immediately (this invalidates active sessions)
• Force password reset and re-enrollment of MFA methods
• Review the user mailbox, OneDrive, and SharePoint activity for the past 30 days for unauthorized access
• Check for newly created inbox rules, mailbox forwarding, OAuth app consents, and MFA method changes
• Notify any external parties who may have received phishing from the compromised account

Drill this runbook at least annually. The first time you run it should not be during a real incident.

---

The Bigger Pattern: Identity Is the New Perimeter

For two decades, network firewalls and VPNs defined the security boundary. An attacker had to get inside the network before they could do real damage. That model is over. Modern attackers do not need to be on your network. They need to be signed in to your identity provider. Once they have a valid Microsoft 365 session, they have access to email, OneDrive, SharePoint, Teams chat history, and frequently the keys to your entire SaaS stack through single sign-on.

Every modern cybersecurity framework, from NIST 800-207 to the CISA Zero Trust Maturity Model, has converged on identity as the primary control surface. The question is no longer "is the attacker inside the perimeter." It is "is this sign-in actually the person who owns the account, on a device we trust, doing something this user normally does."

The 17 controls above are how you answer that question reliably.

---

Bottom Line

If your Microsoft 365 tenant still relies on SMS codes, TOTP apps, or basic push notifications as its MFA strategy, you are exposed to a $300 a month phishing kit. The technology to defend against this is already in your Microsoft licensing. The work is in configuring it correctly, rolling it out to users without breaking productivity, and monitoring the result.

If you do not know whether Conditional Access is enforced on your tenant, whether your admins are on phishing-resistant MFA, or whether you would detect a stolen-cookie sign-in from an attacker machine right now, those are the questions worth answering this quarter.

ITP360 manages Microsoft 365 security for businesses across Miami and South Florida. If you want a clear answer on your tenant exposure to AiTM and token theft, contact our team for a free Microsoft 365 security review. We can help you roll out passkeys, configure Conditional Access policies that actually work, and deploy the layered cybersecurity and Microsoft 365 management that keeps a stolen session from turning into a stolen business.