You Turned On MFA and Still Got Hacked: How Attackers Steal Session Tokens

SmallBizSecurityGuide is reader-supported. If you buy through links on this page we may earn a commission at no extra cost to you.

The email looks like a voicemail, and the login page is perfect

Your office manager gets a message that looks like it came from a coworker: a shared document, or a missed-call notification with an audio attachment. She clicks. A tab opens, spins, then lands on a Microsoft 365 sign-in page. Not a bad one — the real logo, the real font, the real “Pick an account” list, even the company’s own background image, because that image is pulled live from Microsoft’s servers. The URL is a domain she has never read carefully in her life, and it looks close enough.

She types her password. The page asks for the second factor, exactly as it should. Her phone buzzes. She opens the authenticator app, matches the number, taps approve. The page thinks, then drops her onto a real, boring SharePoint document. Nothing looks wrong. She has no reason to mention it to anyone.

Eleven minutes later, someone in another country is reading her mailbox. They never typed her password into Microsoft and never got an MFA prompt. They pasted a cookie.

This is the failure mode nobody warned you about when you turned MFA on. If you are still deciding whether to enable it at all, start with what multi-factor authentication is and why every business needs it — that article covers switching it on. This one covers how accounts still get taken over once it already is.

MFA bypass starts with an adversary-in-the-middle proxy, not a fake page

The old phishing page was a dead end: it collected your password, showed a fake error, and the attacker used the password later. MFA killed that business model.

What replaced it is a reverse proxy. The attacker does not build a copy of the Microsoft login page; he builds a machine that sits in the middle and passes traffic in both directions. Your employee loads the fake domain, the proxy fetches the genuine Microsoft page and hands it over. She types her password, the proxy types it into Microsoft. Microsoft issues the MFA challenge, the proxy relays it in real time. She approves it on her phone — and she is approving the attacker’s session, because as far as Microsoft is concerned there is one login attempt happening and it looks legitimate.

The technique is called adversary-in-the-middle, or AiTM, and the tooling is not exotic. Evilginx is the open-source reverse-proxy framework the category grew out of; the criminal market turned it into a subscription product. Microsoft’s security researchers published a breakdown of Tycoon2FA in March 2026 describing a phishing-as-a-service kit that reached more than 500,000 organizations a month, rented to affiliates for roughly $120 per ten days. Europol, Microsoft and private-sector partners disrupted that infrastructure in early 2026.

Do not read that as good news. Barracuda’s January 2026 threat spotlight reported that known phishing kits doubled during 2025 and that roughly 90% of high-volume phishing campaigns ran on phishing-as-a-service kits. Successors — Mamba 2FA, Sneaky 2FA, Whisper 2FA, CoGUI — picked up the slack.

Why the session token is the prize, and why a password reset does not touch it

Logging in is a one-time event. Staying logged in is not. When you finish authenticating, the service hands your browser a session token — a cookie that says “this browser already proved who it is, let it through.” That is why you do not get an MFA prompt every time you open Outlook. The token is a receipt for an authentication that already happened.

An AiTM proxy is not really after the password. It is after that receipt. The proxy sits in the data path, so when Microsoft or Google issues the session cookie, the proxy captures it in transit. The attacker imports that cookie into his own browser and he is inside the mailbox. No login, no password prompt, no MFA challenge — because the token exists precisely to represent an MFA challenge that was already satisfied.

So when the owner finds out and does the obvious thing — resets the password — the attacker’s session keeps working. A reset changes what is needed to get a new token. It does nothing to the token already issued. Microsoft access tokens are good for about an hour, but the refresh tokens behind them keep renewing far longer, which is how attackers sit quietly in a mailbox for weeks. You have to explicitly kill the session, and almost nobody does, because nothing on the reset-password screen tells you to.

This is a different animal from password reuse. If old passwords are being replayed from a breach dump, that is a credential stuffing attack, and unique credentials from one of the best password managers for small business fix it. Token theft is not solved by better passwords at all.

The other MFA bypass: push bombing, and which attacks MFA really stops

The other way MFA gets beaten does not need a proxy. The attacker already has a working password and hammers the login button, firing approval prompts at the employee’s phone over and over — often at 2 a.m., sometimes followed by a call claiming to be from IT asking them to “clear the notifications.” Enough buzzing, and someone taps approve to make it stop. That is MFA fatigue, or push bombing.

The fix is number matching: instead of a yes/no button, the login screen shows a two-digit number the user must type into the authenticator app. You cannot approve a prompt you did not trigger, because you cannot see the number. Microsoft now enables number matching for all Microsoft Authenticator push notifications and users cannot opt out, so on Microsoft 365 this one is already handled. Google Workspace’s equivalent is number matching on the Google prompt.

It is a real win against push bombing and does nothing against AiTM, because there the employee is the one who triggered the prompt. She will match the number correctly every time.

Attack	Does app or SMS MFA stop it?	What actually stops it
Password guessed or sprayed	Yes	MFA, plus lockout thresholds
Password reused from a breach dump	Yes	MFA, plus unique passwords in a manager
Push bombing / MFA fatigue	Only with number matching	Number matching (default in Entra); phishing-resistant factors
SIM swap against SMS codes	No	Drop SMS as a factor; app, key or passkey instead
AiTM proxy phishing (session token theft)	No	FIDO2 security keys or passkeys; token binding; fast session revocation
Stolen cookie replayed from attacker’s browser	No	Revoking sessions; device-bound sessions; conditional access on device state
Malicious OAuth app granted by the user	No	Restricting third-party app consent in the admin console

Read that table both ways. MFA is still the highest-value control a small business can turn on — Microsoft’s research paper How effective is multifactor authentication at deterring cyberattacks? measured a 99.22% reduction in compromise risk across the accounts studied. Nobody should finish this article and turn MFA off. It is necessary. It is just not sufficient.

Phishing-resistant factors: why a security key cannot be proxied

FIDO2 security keys and passkeys break AiTM by design, and the reason is worth understanding rather than taking on faith.

When you register a security key with Microsoft 365, it generates a private key that never leaves the hardware and permanently staples that credential to the domain name you registered it against — login.microsoftonline.com. Later, when a site asks the key to prove identity, the browser tells the key which domain is actually asking. The key checks whether that origin matches the credential. If it does not, the key refuses. It does not warn, and it does not offer an override. It simply has no credential for that domain and produces nothing.

An AiTM proxy has to live on a domain it controls — that is the entire premise of the attack. So the proxy asks for a signature, the key sees a domain it has never met, and the ceremony dies there. The employee cannot be talked into it or click through it. That is what “phishing-resistant” means: not that users are harder to fool, but that fooling them stops mattering.

Passkeys use the same WebAuthn machinery in software, so they carry the same origin binding. The full path to going passwordless is covered separately in passkeys for small business; the point here is narrower — a phishing-resistant factor is the one control that makes an AiTM proxy useless against you. If the difference between “two-factor” and “multi-factor” is still fuzzy, two-factor vs. multi-factor authentication clears that up.

Hardware keys are the practical starting point: they work on machines you already own and cannot be phished or copied. Budget two per person who matters — one carried, one in a drawer, because a single key with no spare is a lockout waiting to happen. Reasonable options: a YubiKey 5 NFC for mixed laptop and phone use, a plain FIDO2 USB-C security key for newer laptops, a USB-C key with NFC for people who live on their phones, and a nano-format key for a desktop it can stay plugged into.

Roll it out to the accounts that move money first: owner, bookkeeper, anyone with admin rights or the ability to change bank details. In Google Workspace, require it under Security > Authentication > 2-Step Verification, where the Methods setting has an Only security key option that now accepts passkeys too. In Microsoft 365, enforce it with a Conditional Access policy using the built-in phishing-resistant authentication strength.

If it already happened: what your incident response actually has to be

Resetting the password is step one of six. Stopping there is why so many businesses get re-breached a week later. Work the whole list, in order.

1. Reset the password from an admin account — not by asking the user to do it on a machine that may be compromised.
2. Kill every session. In Microsoft 365: Users > Active users, select the person, Account tab, Sign out of all sessions. That can take up to an hour to bite, because an access token is good for about that long; for an immediate cut use the Entra admin center — Entra ID > Users > All users > the user > Revoke sessions — or the Revoke-MgUserSignInSession cmdlet. In Google Workspace: Directory > Users > the user > Security > Sign-in cookies > Reset.
3. Hunt the mail rules. The most common persistence trick, and it survives everything above. In Microsoft 365, look for inbox rules that forward, redirect, or bury messages containing “invoice,” “wire,” “bank,” or “payment” in an obscure folder — and check the mailbox-level forwarding address separately, since that is not an inbox rule and is easy to miss. In Gmail, check both Filters and Blocked Addresses and Forwarding and POP/IMAP.
4. Check the registered authentication methods. If the attacker added his own authenticator app or phone number while inside, he walks back in through the front door after your reset. In Entra, review the user’s authentication methods and delete anything you cannot account for. In Google, check their 2SV settings and registered keys.
5. Review OAuth app grants. A consented third-party app holds its own token and does not care about your password reset. In Entra, review the user’s consented enterprise applications; in Google Workspace, Security > Access and data control > API controls > Manage Third-Party App Access.
6. Read the sent items and check for wire fraud. AiTM operators monetize mailboxes by hijacking invoice threads. Anyone who received payment instructions from that account during the exposure window needs a phone call on a number you already had.

If you are working through a live takeover right now, the fuller step-by-step is in how to recover a hacked business email account.

Conditional access and device binding — with an honest note on licensing

The other way to beat token theft is to make a stolen token useless anywhere else. Microsoft’s token protection Conditional Access control binds sign-in tokens to a registered device, so a replayed cookie fails from the attacker’s machine; it is generally available for Windows native apps against Exchange Online, SharePoint Online and Teams, and in preview elsewhere. Google’s Device Bound Session Credentials is on by default for Workspace accounts and binds Chrome sessions to hardware — it needs a recent Chrome on Windows with a TPM to do anything for you.

The licensing reality: Conditional Access needs Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium — so most small businesses on Business Premium already own it and are not using it. Risk-based policies that react to a suspicious sign-in need Entra ID P2, which Business Premium does not include. On the Google side, Context-Aware Access is limited to Enterprise Standard and Plus, Frontline Standard and Plus, Enterprise Essentials Plus, Education tiers, and Cloud Identity Premium — if you are on Business Standard or Business Plus you cannot get there without an upgrade. Put that money into security keys instead. They cost less and stop more.

What to do this week

1. Confirm SMS is not an allowed second factor for anyone with admin rights or payment authority — an authenticator app at minimum.
2. Order two hardware security keys for each of your highest-risk accounts — owner, finance, IT admin. Enroll one, put the spare in the safe.
3. On Microsoft 365 Business Premium, build one Conditional Access policy requiring phishing-resistant authentication strength for admin roles. You already pay for it.
4. Write “revoke all sessions” into your incident checklist directly under “reset password,” and make sure whoever answers the phone at 6 p.m. knows both.
5. Audit inbox rules and mail forwarding across every mailbox once, today, as a baseline. You may find something already sitting there.
6. Tell your staff the one sentence that matters: if a login page appears after you click a link in an email, close it and reach the site by typing the address yourself. In an AiTM attack everything looks correct — because everything is.