BigBear 2.0 Phishing Service Hijacked Microsoft 365 Sessions at 258 Organizations

A phishing-as-a-service platform known as BigBear 2.0 compromised Microsoft 365 accounts at 258 organizations, using adversary-in-the-middle techniques to steal authenticated sessions after users completed multifactor authentication.

CloudSEK reported the findings on September 7, 2026, at 11:39 AM, after obtaining administrator access to the operation’s control panel. Researchers found 42 virtual private server nodes, each configured to target Microsoft 365 authentication.

The campaign collected more than 5,000 Microsoft 365-related credential records and affected thousands of IP addresses in over 40 countries. Its infrastructure was designed not to crack MFA, but to capture the session created after Microsoft accepted it.

That distinction makes the attack particularly dangerous. A user can enter a correct password, approve an MFA request, and still hand an authenticated cloud session to the attacker.

BigBear Converted Successful Logins Into Attacker Sessions

BigBear 2.0 is built on Evilginx2, an adversary-in-the-middle, or AiTM, phishing framework. Instead of presenting victims with a completely fabricated sign-in form, the service proxies traffic between the victim’s browser and Microsoft’s legitimate authentication systems.

The victim sees a Microsoft 365 login flow and submits a username and password. BigBear relays those details to Microsoft while remaining positioned between both parties.

When Microsoft requests an additional authentication factor, the victim completes that step through the proxied connection. BigBear can then observe authentication material and capture the session cookie issued after the login succeeds.

An affiliate can submit the stolen cookie through BigBear’s API and replay the authenticated session. Because Microsoft has already verified the password and MFA challenge, the attacker may enter the account without repeating the second-factor interaction.

This is session hijacking rather than a cryptographic defeat of MFA. The authentication factor can work exactly as designed while the resulting session is stolen.

The affected ecosystem includes:

• Microsoft 365
• Exchange Online
• Teams
• SharePoint
• OneDrive
• Entra ID authentication
• Applications connected through organizational single sign-on

The consequences depend on the victim’s permissions. An ordinary account could expose email, conversations, documents, and shared files. A privileged Entra ID identity could provide access to administrative resources or other applications that trust the same cloud identity.

No CVE identifier applies to the reported activity. This is an abuse of proxied authentication and stolen session cookies, not a disclosed software vulnerability affecting a defined set of Microsoft 365 versions.

The Panel Recorded Compromises Across More Than 40 Countries

BigBear’s wider targeting data listed 461 organizations. CloudSEK assessed that 258 had suffered at least one completed compromise involving MFA bypass through session theft.

The control panel also recorded 3,331 unique victim IP addresses distributed across more than 40 countries. An IP address does not necessarily correspond to one individual account, so that figure should not be interpreted as an exact victim count.

CloudSEK reported 5,137 exfiltrated credential records, with the following component figures:

• 474 completed authentications in which MFA protections were bypassed
• 1,032 plaintext passwords
• 4,148 authenticated session cookies

Those three figures add up to 5,654, not 5,137. It is not known whether the categories overlap, whether some entries were deduplicated, or whether one of the reported values is incorrect. The discrepancy remains unresolved and should not be corrected by assumption.

The panel was still accessible when the findings were reported. However, the related phishing infrastructure had reportedly been offline for nearly three weeks. That may have interrupted active collection, but it does not invalidate cookies, passwords, or tokens already obtained.

Previously stolen access could remain useful until defenders revoke sessions, expire tokens, change credentials, or impose new authentication requirements.

Affiliates Received Stolen Credentials Through Telegram

BigBear operated as a multi-user service rather than a tool reserved for one threat actor. Its panel was reportedly rented to at least five affiliate operators, allowing customers to run campaigns without building their own AiTM infrastructure.

CloudSEK connected those operators to live Telegram exfiltration bots. The bots delivered captured credentials to affiliates in real time, shortening the interval between a victim’s login and an attacker’s attempt to use the resulting session.

The platform used an “offy” configuration to position its proxy in the Microsoft authentication exchange. It also operated through 42 VPS nodes, indicating an infrastructure model intended to support multiple campaigns or customers.

No list of node addresses, phishing domains, file hashes, or other directly searchable indicators has been disclosed. Organizations therefore cannot rely solely on blocking known BigBear infrastructure.

Detection must focus on identity and session behavior as well. Relevant signals may include unusual use of authenticated sessions, access from unmanaged devices, unexpected mailbox or file activity, privilege changes, and token use inconsistent with a user’s normal working pattern.

Residential Proxies and WebAuthn Interference Reduced Detection

BigBear supported geo-matched residential proxy connections in 69 countries. These proxies allowed affiliates to generate authentication traffic from residential addresses near a victim’s apparent location.

That capability weakens controls based primarily on geography. A stolen session used from a distant country may trigger an impossible-travel or location-based alert, while a residential proxy in the expected region can make the same access appear less anomalous.

Location remains a useful signal, but it is not sufficient by itself. Device management state, session properties, application activity, token behavior, and account privilege should also influence access decisions.

CloudSEK additionally found custom JavaScript intended to disrupt browser support for FIDO2/WebAuthn. The apparent objective was to prevent or interfere with phishing-resistant authentication, pushing victims toward methods that can be relayed more easily through an AiTM proxy.

Properly enforced FIDO2/WebAuthn authentication is resistant to conventional credential phishing because authentication is bound to the legitimate web origin. BigBear’s response was therefore not to break that protection directly, but to try to make it unavailable during the victim’s login flow.

Organizations should investigate unexpected WebAuthn failures, especially when users are subsequently offered a weaker sign-in method. Allowing fallback can erase much of the security benefit of deploying phishing-resistant credentials.

Defenders Should Revoke Sessions, Not Just Change Passwords

A password reset alone may not remove an attacker who already possesses a valid session cookie. Incident responders should treat suspected BigBear exposure as both a credential compromise and a token-theft event.

Recommended actions include:

1. Reset passwords associated with exposed or suspicious accounts.
2. Revoke active Microsoft 365 sessions so captured cookies can no longer provide access.
3. Invalidate or refresh relevant tokens, including those used by connected cloud applications.
4. Force re-authentication for privileged identities, administrators, and other high-impact accounts.
5. Require phishing-resistant FIDO2/WebAuthn methods and restrict weaker fallback options where operationally possible.
6. Use Conditional Access policies requiring managed or compliant devices for sensitive services.
7. Review Exchange Online, Teams, SharePoint, OneDrive, and Entra ID activity for actions inconsistent with the user’s role or device history.
8. Avoid treating geographic consistency as proof of legitimacy, given BigBear’s residential proxy support.

CloudSEK said it notified law enforcement and several affected organizations. Exposed credentials were also included in responsible-disclosure reports.

The broader challenge is that malicious activity becomes harder to stop once it takes place inside a valid authenticated session. A cited Blue Report 2026 assessment found that only 37% of attacker actions performed with valid credentials were blocked across 338 million simulations in customer production environments. That result was not specific to BigBear, but it illustrates why post-authentication monitoring matters.

MFA remains necessary, but not every MFA method provides the same protection against AiTM phishing. For organizations facing services such as BigBear, the stronger model combines origin-bound authentication, managed-device requirements, rapid session revocation, and behavioral monitoring after login.