# MFA Isn't Dead, But BigBear 2.0 Just Proved You've Been Trusting It Too Much
For years, the standard security playbook treated multi-factor authentication as a near-magical shield. Enable MFA on Microsoft 365, brief your users, move on. The breach statistics suggested this was mostly working — until the attackers industrialized the workaround.
BigBear 2.0, a phishing-as-a-service framework now linked to compromised credentials at 258 organizations, is the clearest evidence yet that the era of "MFA equals covered" is over. More than 5,000 Microsoft 365 accounts fell to this kit. The victims weren't breached because MFA failed — they were breached because the attackers never had to fight it.
## How a Proxy Turns Your MFA Against You
The technique driving BigBear 2.0 isn't new, but its packaging is. Adversary-in-the-middle (AiTM) phishing works by sitting a reverse proxy between the victim and the real Microsoft login portal. The user sees a pixel-perfect replica of the sign-in page — because it *is* Microsoft's sign-in page, relayed in real time. The victim enters credentials, completes their MFA challenge, and gets redirected to their inbox. They never notice anything wrong.
What the attacker captures isn't just the password. It's the authenticated session cookie — the token Microsoft issued *after* successful MFA. From that point, the attacker sidesteps the authentication flow entirely. No password needed. No MFA prompt triggered. They're already inside.
This is the same fundamental technique that powered Storm-0558's breach of U.S. government Exchange Online accounts, that Scattered Spider weaponized against Okta customers in 2022, and that frameworks like EvilProxy and Evilginx have offered to lower-tier operators for the better part of four years. BigBear 2.0 isn't an evolution of the attack — it's the maturation of a service model that keeps lowering the technical floor.
## 258 Organizations, One Toolkit
What makes the BigBear numbers significant isn't the scale in absolute terms — it's what they reveal about operational tempo. Phishing-as-a-service frameworks let a single campaign operator target dozens of organizations simultaneously without deep technical expertise. The infrastructure, the phishing templates, the credential harvesting and session cookie exfiltration — it's all managed. The buyer just supplies the target list and pays the subscription.
This commoditization creates a structural problem for defenders. When attackers needed genuine skill to execute AiTM attacks, the technique stayed in the hands of sophisticated threat actors — nation-states, organized crime groups with technical staff. That's still a serious threat, but it's a manageable one with good threat intelligence. When the same capability becomes a service accessible to mid-tier opportunists, detection and response strategies that calibrated against elite actors start showing gaps.
Microsoft 365's ubiquity makes it the obvious target. Somewhere north of 300 million commercial users. Shared tenant architecture where a single compromised account can pivot to SharePoint, Teams, OneDrive, and connected SaaS applications. For attackers running a subscription-based credential theft service, it's the highest-value, most standardized attack surface available.
## What Your Logs Won't Tell You
Here's the piece that makes incident response genuinely painful: when a session cookie is stolen and replayed, the authentication event in your logs looks legitimate. MFA was completed. The sign-in succeeded. The IP might be foreign, but not obviously so if the attacker is routing through a residential proxy. The anomalous signal — someone authenticated from London at 2 AM when they're a Phoenix-based employee — might fire an alert. But it might not.
Traditional MFA bypass detection relies on spotting failed authentication attempts, impossible travel, or known-bad IPs. Session cookie theft produces *successful* authentication from a plausible location, which makes behavioral baselines and anomaly detection do the heavy lifting. If your SIEM isn't correlating sign-in locations, device IDs, and session lifetimes against historical user behavior, you're probably not catching this in real time.
## The Phishing-Resistant Gap
The fix that actually works — phishing-resistant MFA, primarily FIDO2 hardware keys and passkeys — has been talked about for years and deployed almost nowhere at scale. The problem is practical: hardware key programs cost money, require IT logistics, and generate user friction. Passkeys are maturing but still face compatibility patchwork across enterprise environments. And certificate-based authentication, Microsoft's other phishing-resistant option, requires a PKI infrastructure that many organizations haven't built.
So most organizations are running authenticator apps and SMS codes — authentication factors that AiTM frameworks defeat by design.
---
## HackWire Analysis
The BigBear 2.0 story deserves attention not just for its victim count but for what it signals about where PhaaS is heading. Three patterns stand out that other coverage is underweighting.
First, the timing: BigBear 2.0 arrives while Microsoft is actively pushing organizations toward passwordless and phishing-resistant MFA under the CISA SCuBA guidance and its own Secure Future Initiative commitments. The attack surface being exploited is the transition gap — organizations that upgraded from SMS to authenticator apps and called it done. That gap is where industrialized AiTM lives, and it will remain exploitable for years given enterprise migration timelines.
Second, the target profile matters. 258 organizations is a large number for a single PhaaS campaign, but it's also a manageable dataset for researchers. When this toolkit gets detailed technical analysis, expect to see that victims skew toward mid-market companies — the 200-to-2000 employee range that has Microsoft 365 but lacks a dedicated security operations team watching for session anomalies. Enterprise customers with mature SIEM deployments and Entra ID Protection on premium tiers are harder targets. The mid-market is the yield zone.
Third: Conditional Access is doing less than security teams think. Most M365 tenants have some Conditional Access policies — require MFA, block legacy auth — but far fewer have Continuous Access Evaluation enabled, token binding configured, or sign-in frequency set aggressively enough to limit the replay window. A stolen session cookie in a tenant with a 24-hour access token lifetime gives attackers a full business day inside a mailbox before anything expires.
Defenders should prioritize three things immediately: audit your Conditional Access policies for session controls, enable Entra ID Protection risky sign-in detection with automatic remediation, and start the business case for phishing-resistant MFA rollout — even if full deployment is two years away, starting now matters.
The attackers are not waiting for your roadmap.
— HackWire Editorial
---
## Related Coverage