# BigBear hit 258 organizations by disabling WebAuthn in the browser and catching the fallback

Source: https://startwithidentity.com/blog/2026-09-07-bigbear-phishing-service-disabled-webauthn-to-force-a-downgrade/
Last updated: 2026-09-14
License: content by Start with Identity. Cite the source URL.

---

CloudSEK researchers obtained admin panel access to BigBear 2.0, an Evilginx2-based phishing-as-a-service platform targeting Microsoft 365, and disclosed the contents to law enforcement and affected organizations. The panel held 5,137 exfiltrated credential records: 4,148 session cookies, 1,032 plaintext passwords, and 474 complete MFA-bypassed authentications, from 3,331 unique victim IP addresses across more than 40 countries. At least 258 organizations had one or more completed compromises. Beyond standard adversary-in-the-middle proxying, the kit injects custom JavaScript that disables FIDO2 and WebAuthn in the victim's browser, pushing the sign-in onto a weaker factor the proxy can relay.

## Why it matters

The downgrade is the part that deserves attention, because it is the first thing on our beat that treats a phishing-resistant credential as an obstacle to route around rather than a wall to give up at.

Phishing-resistant authentication works by binding the assertion to the real origin, so a proxy cannot produce one. BigBear does not try. It removes the option from the page, and the user, presented with a sign-in that simply does not offer the security key, does the sensible thing and uses the method that remains. The credential was never defeated. It was never invoked. Every deployment that keeps a phishable method enabled "for fallback" is carrying this exact failure mode, and the fallback is not a safety net, it is the attack surface.

The control follows directly and is unpopular: make phishing-resistant methods the only permitted methods for the accounts that matter, enforced by [Conditional Access](https://startwithidentity.com/glossary/conditional-access/) that rejects the weaker authentication strength rather than merely preferring the stronger one. CloudSEK's other recommendation is worth repeating too: condition access on a managed device rather than on geolocation, since the proxy sits wherever the attacker rents it. Then revoke sessions and reset passwords for anyone in the exposed set, because 4,148 of those records are [session cookies](https://startwithidentity.com/techniques/session-cookie-theft/) and a password reset does not touch them.

Sources: [BleepingComputer](https://www.bleepingcomputer.com/news/security/bigbear-microsoft-365-phishing-service-bypassed-mfa-at-258-organizations/)