BigBear Phishing Steals Microsoft 365 Sessions After MFA

CloudSEK published an investigation on 7 September into BigBear 2.0, a phishing-as-a-service panel built around the Evilginx2 reverse-proxy framework and configured to imitate Microsoft 365 sign-in. The researchers say they obtained access to the operator's panel and observed 42 virtual private server nodes over the campaign's lifecycle, with at least five affiliate operators receiving stolen data.

The report says the panel held 5,137 credential records, including 474 complete authentications in which MFA had been passed, 1,032 plaintext passwords and 4,148 session cookies. CloudSEK counted 3,331 unique victim IP addresses across more than 40 countries and said the operation remained active when its analysis was published. These figures come from the researcher's access to the campaign infrastructure; they are not a count independently confirmed by Microsoft.

In an adversary-in-the-middle attack, the fake site relays the victim's entries to the real Microsoft login service in real time. The page can therefore look familiar and the password and one-time code can genuinely work. Once Microsoft issues a signed-in browser session, the proxy captures the session cookie and an attacker can replay it without asking for that same one-time code again.

This is not the same as breaking the cryptography behind MFA. The victim completes the legitimate challenge through a hostile relay, and the relay takes the resulting session. CloudSEK says the campaign also used country-matched residential proxies, which can make location-based controls less useful and cause sign-in records to show infrastructure closer to the victim's region.

Treat the browser's address as part of the login. A valid HTTPS connection only says the connection to that domain is encrypted; it does not prove the domain belongs to Microsoft. Open the service from a saved bookmark or your organisation's known portal instead of following an unexpected email, Teams message, QR code or shared-document link that immediately asks you to authenticate.

Where an employer supports it, use phishing-resistant, origin-bound sign-in such as a properly configured FIDO2 security key or platform passkey. CloudSEK explains that these credentials bind approval to the real website origin, unlike SMS, authenticator codes or push approvals that a live proxy can relay. Organisations should also use managed-device requirements, token protection where available, short risk-based sessions and monitoring rather than relying on location alone.

Stop using the suspected page and contact the organisation's security or IT team through a known channel. From a clean, trusted session, revoke active sign-ins and refresh tokens, reset the password, review MFA methods and recovery details, and check mailbox forwarding rules, OAuth grants, SharePoint or OneDrive access and unusual sent messages. A password reset without session revocation may leave a stolen browser session usable.

Warn colleagues and external contacts if the account may have sent messages, because a real compromised mailbox can produce convincing follow-on requests. Preserve the phishing URL, message headers and sign-in details for investigators without reopening the link. Businesses should use identity-provider logs and incident-response procedures to determine what the captured session accessed.

A reputable VPN can protect traffic from local snooping on public Wi-Fi and reduce routine IP exposure. An enterprise may also require remote staff to use a controlled business VPN before reaching internal systems, which is a separate access-control layer.

A VPN cannot tell a Microsoft sign-in page from a convincing reverse proxy, prevent a user entering credentials into the wrong domain or invalidate a session cookie already issued through that proxy. The phishing site may itself use HTTPS, so an encrypted connection can still lead to the attacker. Domain verification, phishing-resistant authentication and rapid token revocation are the relevant controls.

The practical lesson is not that MFA is useless. MFA still blocks many password-only attacks, while origin-bound methods can resist this proxy pattern more effectively. The lesson is that different MFA methods protect against different threats.

For individuals, the most valuable habit is to stop before the sign-in screen and verify where the browser is actually going. For organisations, recovery must include sessions and tokens, not only passwords, because the object stolen by an adversary-in-the-middle campaign may be the already-authenticated session itself.