474 Microsoft 365 Sessions Already Beat MFA. Here Is How BigBear Did It
Disclosure: Some links on this page are affiliate links. If you purchase through them, we may earn a commission at no extra cost to you. Full affiliate disclosure.
Most security advice still treats multi-factor authentication as the wall that stops phishing. It is not, and it has not been for several years. What MFA stops is the attacker reusing your password later. What it does not stop is an attacker standing between you and Microsoft while you type it.
CloudSEK obtained access to the admin panel of a phishing operation called BigBear 2.0 and read its own records rather than guessing from the outside. What was inside is the clearest published picture yet of how industrial credential theft actually runs: 5,137 records spanning 461 organisations, 1,032 plaintext passwords, 4,148 session cookies, and 474 confirmed sessions where MFA had been bypassed entirely.
Those 474 are the number worth sitting with. They are not attempts. They are finished jobs where the second factor was satisfied and the account was open anyway.
Editor’s take: The detail that matters is not the proxy - it is that 474 sessions succeeded because conditional access was not enforced, and an adversary-in-the-middle kit only works when the tenant lets it. Residential proxies made the logins look routine, which is why nothing alerted. Phishing-resistant MFA (FIDO2, passkeys) closes this specific attack, and no amount of user training does.
Editor's Take
If one thing should come out of this incident, it is that SMS codes and push approvals are not phishing resistance, they are just a second thing an attacker can relay in real time. The fix is not more factors but a different kind: origin-bound credentials like passkeys or hardware keys, which simply cannot be replayed to a proxy site. MFA fatigue prompts are a design smell, not a control.
The Mechanism: A Proxy, Not a Fake Page
The old model of phishing was a counterfeit login form that harvested your password and then failed, because the code you generated seconds later was useless to an attacker who needed it immediately. Adversary-in-the-middle kits solved that by removing the counterfeit part.
BigBear runs Evilginx2, which acts as a reverse proxy. You receive a link, you 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 and you supply it. Every one of those keystrokes is relayed to Microsoft in real time, and when Microsoft is satisfied it issues a session cookie — which comes back 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 whole prize. Replaying it grants access to Outlook, calendar, Teams conversations, and everything in SharePoint and OneDrive without triggering another prompt. The 474 bypassed sessions were usable immediately.
They Turned Off the One Thing That Would Have Stopped Them
There is a class of authentication that defeats relay attacks completely: FIDO2 hardware keys and passkeys. These bind the credential cryptographically to the domain you are actually on. A proxied login presents the wrong origin, the key refuses to sign, and the attack fails with no user judgement required.
BigBear knew this, so 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 a six-digit number off your screen and type it into the proxy, or you tap approve on a prompt you were already expecting.
If your organisation rolled out MFA and stopped there, this is the gap. The presence of a second factor is not the same as the presence of a phishing-resistant one.
Residential Proxies Make It Look Ordinary
The operation routed traffic through a residential proxy pool covering 69 countries. This does two jobs at once. Login attempts appear to originate from real home connections in plausible locations rather than a data centre, which helps them survive Microsoft's risk scoring. And the pool actively filtered out visitors arriving from data centres or VPNs, which is how researchers and scanners usually find these kits.
In practical terms: a security team that tried to visit the phishing page from their corporate network or a cloud VM often saw nothing at all. The kit hid from exactly the people looking for it.
This Is a Business With Customers
The panel was managed by an operator using the handle "General Boss" and rented out through a multi-user interface to at least five affiliate operators. Harvested credentials were pushed out in real time through a Telegram bot.
That structure matters more than the technical details, because it explains the volume. This is phishing-as-a-service: the person who builds the kit is not the person who writes the emails, and the person who steals the session is not the person who uses it. Specialisation is why a single operation reaches 461 organisations. Some infrastructure has since been taken down, but CloudSEK reported the operation was still active while it was being investigated.
What Actually Helps
Ordered by how much risk each one removes, not by how easy it is.
- Move to phishing-resistant factors. Hardware keys and passkeys are the only second factors that fail closed when the domain is wrong. If you do one thing after reading this, make it this, and roll it out to administrators and finance staff first — they are the targets worth the most.
- Shorten session lifetime and bind sessions to device state. A stolen cookie is useful for as long as Microsoft accepts it. Conditional Access policies that re-evaluate device compliance and location reduce that window substantially.
- Stop treating MFA prompts as benign. The single highest-value user habit is rejecting any prompt you did not personally trigger. Push fatigue is the attack, and "approve because it's probably me" is the whole mechanism.
- Remove SMS as an option where you can. It is the fallback these kits are engineered to force you into. Eliminating it removes their preferred path.
- Assume mailbox access means broad access. Once an attacker holds a session, password reset flows for other services become the next step. Our identity theft protection comparison covers what monitoring catches after the fact, and our dark web monitoring guide explains how credentials surface before they are used.
Worth checking today: whether your own email and phone number are already circulating in broker and stealer data. That is the raw material these operations use to make a phishing message specific enough to work.
For the user-side version of this — the specific tells in a login page and a prompt — our phishing identification guide walks through what to look at, and our password manager comparison covers the tools that refuse to autofill on a mismatched domain.
The Honest Read
MFA was never a wall; it was a speed bump that raised the cost of credential reuse. Kits like this one route around it by not reusing anything. The 474 sessions are not a failure of the users who typed their codes — they typed them into a real Microsoft page that asked for them.
The uncomfortable conclusion is that the defensive advice has to change shape. "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 providing considerably less of it than people assume.
