Most of us still think of MFA as the control that stops phishing. It isn't, and hasn't been for years. What MFA stops is reuse — someone taking your password and logging in later. What it does not stop is someone standing between you and Microsoft while you type it.
CloudSEK got access to the admin panel of a phishing operation called BigBear 2.0 and read its own records instead of inferring from the outside. What was in there is one of the clearer published pictures of how industrial credential theft actually runs:
- 5,137 records spanning 461 organisations
- 1,032 plaintext passwords
- 4,148 session cookies
- 474 confirmed sessions where MFA had been bypassed entirely
Those 474 are the number worth staring at. Not attempts. Finished jobs where the second factor was satisfied and the account opened anyway.
The mechanism: a proxy, not a fake page
The old phishing model was a counterfeit login form. It harvested your password and then failed, because the TOTP code you generated seconds later was useless to an attacker who needed it right then.
Adversary-in-the-middle (AiTM) kits solved that by removing the counterfeit part. BigBear runs Evilginx2, which is a reverse proxy:
- You get a link and land on what genuinely is Microsoft's login page, served through the attacker's domain.
- You type your password.
- Microsoft asks for your second factor. You supply it.
- Everything is relayed to Microsoft in real time.
- Microsoft is satisfied and issues a session cookie — which returns through the proxy, where the attacker keeps a copy.
Nothing was guessed. Nothing was cracked. The attacker watched a legitimate authentication happen and kept the receipt.
That cookie is the entire prize. Replaying it gives access to Outlook, calendar, Teams conversations, and everything in SharePoint and OneDrive, without triggering another prompt.
They deliberately disabled the one control that would have stopped them
FIDO2 hardware keys and passkeys defeat relay attacks completely. The credential is cryptographically bound to the origin. A proxied login presents the wrong origin, the key refuses to sign, and the attack fails with no user judgement required.
BigBear knew this. Its pages shipped custom JavaScript to disable FIDO2 and WebAuthn. With the strong option gone, users fell back to whatever remained — SMS codes and push approvals. Both are relay-friendly: you read six digits off your screen into the proxy, or you tap approve on a prompt you were already expecting.
If your org rolled out MFA and stopped there, that's the gap. "A second factor exists" and "a phishing-resistant second factor exists" are different statements.
Residential proxies hide it from exactly the people looking
The operation routed through a residential proxy pool covering 69 countries. Two jobs at once:
- Login attempts appear to come from real home connections in plausible locations, which helps them survive risk scoring.
- The pool actively filtered out visitors from data centres and VPNs — which is how researchers and scanners normally find these kits.
So a security team that tried to visit the phishing page from a corporate network or a cloud VM often saw nothing at all.
It's a business with customers
The panel was run by an operator using the handle "General Boss" and rented through a multi-user interface to at least five affiliates. Harvested credentials were pushed out in real time via a Telegram bot.
That structure explains the volume better than any technical detail. This is phishing-as-a-service: the person who builds the kit isn't the person who writes the emails, and the person who steals the session isn't the person who uses it. Some infrastructure has been taken down, but CloudSEK reported the operation was still active while it was being investigated.
What actually helps, ordered by risk removed
- Move to phishing-resistant factors. Hardware keys and passkeys are the only second factors that fail closed when the domain is wrong. Roll out to admins and finance first — they're the highest-value targets.
- Shorten session lifetime and bind sessions to device state. A stolen cookie is useful for as long as the IdP accepts it. Conditional Access policies that re-evaluate compliance and location cut that window down.
- Treat unexpected MFA prompts as hostile. Push fatigue is the attack. "Approve because it's probably me" is the whole mechanism.
- Remove SMS as an option where you can. It's the fallback these kits are engineered to force you into.
- Assume mailbox access means broad access. Once a session is held, password reset flows for other services are the next step.
The uncomfortable part
MFA was never a wall. It was a speed bump that raised the cost of credential reuse, and kits like this one route around it by not reusing anything. The 474 sessions aren't a failure of the users who typed their codes — they typed them into a real Microsoft page that asked for them.
"Turn on MFA" was the right instruction in 2018. In 2026 the instruction is "turn on MFA that cannot be relayed," and anything less is a checkbox that looks like protection while delivering considerably less than people assume.
Originally published at CyberPicks.
Top comments (0)