BigBear 2.0 Beat MFA at 258 Microsoft 365 Orgs

The interesting number here is not 258. It is the JavaScript the kit injects into every fake Microsoft sign in page, which quietly breaks WebAuthn so your security key never gets a chance to fire. BigBear 2.0's operators built a downgrade attack against the one control that would have stopped them, and that is the detail worth taking from BleepingComputer's report on the campaign.

Key Takeaways

• BigBear 2.0 is a phishing as a service framework that bypassed multifactor authentication at 258 Microsoft 365 organizations, out of 461 in the wider targeting set.
• CloudSEK found 5,137 stolen credential records in the operators' panel: 4,148 session cookies, 1,032 plaintext passwords and 474 authentications where MFA had already been satisfied.
• It runs on Evilginx2, an open source reverse proxy that sits between the victim and Microsoft's real login servers, taking the password on the way in and the session cookie on the way back.
• Injected JavaScript rejects WebAuthn requests in the victim's browser, so FIDO2 keys and passkeys silently fail and the login drops back to SMS, TOTP or push, the factors a proxy can relay.

What Is BigBear 2.0?

BigBear 2.0 is a rented phishing platform built on Evilginx2 and pointed exclusively at Microsoft 365. Not one crew but a multi user panel, with five affiliate operators taking stolen sessions off a Telegram feed. CloudSEK's analysts got administrator access to it and published the inventory in their BigBear 2.0 campaign analysis: 42 virtual servers at one hosting provider, all running the phishlet the operators named "offy", 26 of them already deleted by late July. That reads less like a shutdown than like housekeeping.

Targeting was not random. IT services and managed service providers made up 151 of the affected organizations, ahead of SaaS at 38 and oil and gas at 22. Hitting an MSP is leverage: one administrator mailbox carries trusted threads with dozens of downstream tenants.

How Does It Get Past MFA?

It does not get past MFA. It lets you complete MFA correctly, then steals the cookie Microsoft hands you as the reward. Which is why awareness training about checking the code carefully is beside the point here.

The victim lands on a domain the operators control, with a valid certificate and a padlock in the address bar. Every request is relayed to login.microsoftonline.com in real time and every response relayed back, so the victim sees the genuine Microsoft page because it is the genuine page, proxied. Password and one time code both cross in plaintext. Microsoft then issues an authentication cookie, and it reaches the attacker's database before the browser that earned it. This adversary in the middle relay is why Evilginx2 is catalogued as software S9003 in the MITRE ATT&CK knowledge base.

CloudSEK measured an 80 percent conversion from captured password to captured session cookie. Two touches raise the yield: the kit blocks Microsoft's telemetry so risk signals never leave the page, and it silently ticks "Keep Me Signed In". Residential proxies across 69 countries then replay the cookie from an IP matching the victim's city, defeating the impossible travel rules most tenants lean on. The same pattern appeared when one AiTM kit hijacked TikTok Business and Google accounts in a single flow.

Why Did the Kit Try to Disable FIDO2?

Because FIDO2 is the one factor the proxy cannot relay, so the only move left was stopping the browser from offering it. The injected script overrides navigator.credentials and rejects any request carrying publicKey options, the call a WebAuthn login makes. The key prompt never appears and the page falls back to the next registered method.

FIDO2 resists the proxy because of origin binding. A WebAuthn credential is tied cryptographically to the origin it was registered against, and the authenticator refuses to sign a challenge from any other. A relayed login from konceptenterprises[.]com is a different origin, so the key stays silent and the attack ends. CISA names FIDO2 and PKI smart cards as the standard, and one time codes and push as phishable, in its fact sheet on implementing phishing resistant MFA.

A downgrade attack is an admission: someone spent development time defeating hardware keys because the alternative was already working. And it only succeeds where a weaker method remains registered as a fallback, the default in most tenants that consider themselves to have deployed passkeys. Registration is not enforcement. Attackers are circling passkeys from other angles too, as in the pass-ta-key malware attacks on Google Password Manager.

What This Means for Your Inbox

Every one of those 5,137 records began as a message someone opened. The mailbox is the entry point and, once a session is stolen, the prize: a hijacked Microsoft 365 session reads mail, sends from the real address and passes SPF, DKIM and DMARC without a hitch.

That is why the second wave lands so well. The next lure arrives from a genuine partner address, inside a real reply thread, with nothing spoofed for a gateway to catch. Sender reputation scoring has nothing to score. The same blind spot showed up when SVG voicemail lures slipped past Microsoft filters at 5,527 organizations.

This is the third distinct MFA bypass against a major mail provider we have covered this year, after Russian operators abusing Gmail app passwords and the TikTok Business SSO campaign. Different vectors, one pattern: stop attacking the second factor and take the artifact issued once it succeeds. None of that is Microsoft specific. Google Workspace, Okta and every other OIDC provider hand out the same kind of cookie at the end of the same flow.

Session theft is not the only mail borne fraud scaling up. Microsoft counted over a million AI assisted invoice scam emails in a single campaign, built from fabricated executive threads rather than stolen cookies.

What Should You Do Now?

Treat the session cookie as the asset worth protecting, not the password. CloudSEK's remediation guidance and Microsoft's own advice converge on a short list, in this order.

• Revoke sessions, not just passwords. A reset alone leaves a stolen refresh token valid. Revoke sessions and refresh tokens for every suspect account, then force reauthentication.
• Enforce phishing resistant methods, do not merely offer them. Set a Conditional Access authentication strength that accepts only FIDO2 keys, device bound passkeys, Windows Hello for Business or certificate based authentication. If TOTP remains an acceptable fallback, the downgrade script wins.
• Require a compliant or managed device. A replayed cookie from an unmanaged machine fails the policy even when the geography looks right.
• Hunt the proxy's fingerprints. Evilginx2 traffic has historically carried headers in the x-evg- family, and CloudSEK published node IPs and phishing domains worth feeding to detections.
• Alert on impossible session characteristics, not impossible travel. Watch for one session identifier arriving with a new user agent or autonomous system, and for inbox rules created minutes after a sign in.

Token protection in Microsoft Entra binds a token to the device that obtained it, but coverage is partial and it does not stop the theft. Pilot it, do not lean on it.

Looking Ahead

The phishing infrastructure had been dark about three weeks when the research went out, while the administrator panel was still answering. Panels outlive nodes: the affiliate list, the phishlet and the cookie database survive any teardown. The Evilginx2 tooling itself is public and has been for years.

Expect the WebAuthn downgrade to become standard equipment in commodity kits, the way auto ticking "Keep Me Signed In" already has. The counter is available today: register hardware keys or device bound passkeys, then strip weaker methods out of policy so there is nothing left to downgrade to. BigBear 2.0's developers already told you which control they feared.