How BigBear 2.0 beat MFA at 258 organizations

CloudSEK gained administrator access to a phishing control panel and found an operation that had defeated multi-factor authentication at 258 organizations. The kit behind it, BigBear 2.0, is a phishing-as-a-service built on the Evilginx2 reverse proxy. It sits between the victim and the real login page and copies the session the moment the user completes the legitimate MFA challenge. ¹

The user enters the right password and approves the right prompt, but the attacker captures the completed session first, before the browser gets to use it.

The interception flow

BigBear 2.0 uses a configuration called “offy,” an Evilginx2 phishlet that proxies Microsoft 365 logins. When a victim clicks the link in the email, the phishing domain serves a page that looks like the legitimate Microsoft login. It terminates the victim’s TLS connection with a valid Let’s Encrypt certificate and opens a second TLS connection to Microsoft through a proxy. The proxy relays every field the victim types and every MFA response to the real portal, and copies each one on the way through. ²

The attacker ends up with a complete, authenticated session cookie. The user’s own browser also holds a copy and proceeds to the mailbox, so nothing looks wrong to the victim. From that point on, the attacker can reuse the stolen cookie to get back in without typing a password or completing MFA a second time.

The offy injections

Stock Evilginx2 is a known tool. The operation layers three JavaScript injections on top, and they carry the attack. The first disables the browser’s FIDO2/WebAuthn support, pushing users away from passkeys and back onto methods the proxy can intercept. The second blocks the telemetry and canary tokens Microsoft uses to detect phishing. The third is the quiet one: it checks the “Keep me signed in” box, which stretches how long the stolen cookie stays valid. ²

The net effect is that the interception stays hidden and the stolen session stays usable for longer.

The infrastructure behind it

CloudSEK found 42 virtual servers running the proxy and a pool of residential proxies covering 69 countries. The proxy geo-matches the victim, so the login comes from a residential address in the same region as the user, which keeps the activity from tripping the geolocation checks that would otherwise flag it. ¹

At least five affiliates ran the panel. Researchers identified each one by the individual Telegram bot token it used to receive stolen credentials in real time. Across all of them, the panel exfiltrated 5,137 records: 474 complete MFA-bypassed authentications, 1,032 plaintext passwords, and 4,148 session cookies, spread across 3,331 unique victim IP addresses in more than 40 countries. ¹ Attackers targeted India the most, and IT service and managed service providers took the heaviest hit, which fits because a compromise of one provider can spread to the clients it manages. ²

The operation ran from late June. It slowed around mid-July, the operators started pulling nodes around July 27, and no new victims showed up after July 29. The panel and the affiliate bots stayed online at the time of the report, so the campaign is not clearly over. ²

MFA did its job

The user’s MFA worked, and the attacker did not need it. The finished session sits downstream of the factor. An attacker who captures that session skips the factor entirely, so no amount of MFA at login protects against a stolen session.

That is why phishing-resistant authentication matters. FIDO2/WebAuthn passkeys bind to the site and the specific challenge. A proxy that copies a session without completing the binding has nothing to replay. The offy phishlet has to disable that support to keep working, which is both a tell and a gap.

The controls that hold

My fix list follows the defenders who found this. Revoke the exposed sessions and refresh tokens, reset the affected passwords, and force re-authentication for privileged accounts. Then make the policy call that holds: require phishing-resistant FIDO2/WebAuthn and back it with Conditional Access managed-device requirements rather than geolocation signals, because the operators built the proxy to fake the geography. ¹

I also read the geo-match as a detection cue. A login that is too clean on location, coming from a residential address, with no device telemetry behind it, matches the shape of this kit.