AiTM Phishing Bypassed MFA at Stryker — Why "Spotting the Red Flags" Isn't Enough Anymore

We've written before about teaching your front desk to spot a phishing email — misspelled sender addresses, urgent language, suspicious links. That advice still matters. But the attack that took down 80,000 devices at Stryker in March 2026 used a technique that a sharp-eyed office manager checking for red flags wouldn't have caught, because it was designed specifically to get past multi-factor authentication.

It's called adversary-in-the-middle (AiTM) phishing, and it's becoming one of the most common ways attackers break into small organizations with MFA already turned on.

How it actually works

In a normal phishing attack, a stolen password alone usually isn't enough — MFA stops the attacker at the login screen. AiTM phishing gets around that by putting the attacker's server in between the victim and the real login page.

The victim clicks a link that looks like a normal Microsoft or Google sign-in. It looks real because, in a sense, it is — the attacker's proxy server is quietly relaying the victim's login attempt to the real Microsoft servers in real time. The victim types their password, completes their MFA prompt exactly as they always do, and gets logged in normally. Meanwhile, the attacker's proxy has captured the session token generated after that successful login — a token that proves "this user is authenticated" without needing the password or a second MFA prompt ever again.

That's what happened to a Stryker IT administrator. Their credentials and MFA looked completely normal to them. The attacker walked away with a live, authenticated session and used it to reach Stryker's device management platform.

Why this matters more for small practices than it sounds

Larger organizations at least have security teams watching for unusual login patterns. Most small medical practices don't — which means an AiTM-captured session could sit unnoticed for days or weeks, giving an attacker time inside your Microsoft 365 tenant, your EHR portal, or your practice management system.

And because the login looked completely legitimate to the person who clicked it, this isn't a training problem in the traditional sense. No amount of "check the sender's email address carefully" catches a proxy page that's relaying a real login in real time.

What actually helps

The honest answer is that standard MFA — push notifications, SMS codes, authenticator app codes — does not fully stop AiTM phishing, because the attacker isn't trying to guess your code, they're relaying it. What does help:

Phishing-resistant MFA, specifically FIDO2 security keys or passkeys, which are cryptographically tied to the real website and simply won't authenticate against a lookalike proxy page, no matter how convincing it looks.

Conditional access policies that flag or block logins from unfamiliar devices or locations, even with a valid session token.

Reducing how many people carry standing admin access in the first place, so that even a successful AiTM attack against one account doesn't hand over the keys to everything.

Practical takeaways

Assume standard app-based or SMS-based MFA can be bypassed by a determined attacker, and treat it as a baseline, not a finish line. Move admin and high-privilege accounts to phishing-resistant MFA (security keys or passkeys) first. Ask your IT provider whether conditional access policies are in place to flag logins from new devices or unusual locations. Keep teaching staff to spot obvious phishing — it still stops the majority of everyday attempts — but don't assume that training alone covers this newer class of attack.

Red-flag training and better MFA aren't competing strategies. You need both. The practices that get caught out by attacks like this one are usually the ones that stopped at the first.