That distinction matters for Windows users, Microsoft 365 administrators, and managed service providers. A password reset may stop continued password use, but it does not necessarily invalidate a session already taken by an attacker. Defending against this class of attack requires controls that reduce phishing exposure, make sessions less reusable, constrain access to managed devices, and ensure incident responders revoke tokens as well as credentials.
What BigBear 2.0 reportedly did
CloudSEK reported discovering BigBear 2.0 in June 2026 after gaining administrator access to its panel. Its assessment describes a rebranded, Evilginx2-based phishing-as-a-service operation using an “offy” phishlet aimed at Microsoft 365 authentication. It also reported observing 42 virtual private server nodes during the campaign lifecycle.
The important feature is the adversary-in-the-middle, or AiTM, design. A victim who follows a convincing phishing link can be presented with a page that relays their activity to the real Microsoft sign-in experience. From the victim’s perspective, the normal username, password, and MFA prompts may appear to work. But the proxy can capture the authenticated session material produced after that process completes.
Microsoft classifies this outcome as token theft: an attacker compromises and replays tokens issued to a user even after that user has satisfied MFA. In practical terms, the attacker is attempting to reuse proof that the user already signed in, rather than trying to guess a password or repeatedly approve MFA prompts.
This is why describing the incident simply as “MFA bypass” can be misleading. MFA was still performed by the legitimate service. The failure point is that a phishing relay obtains a usable authenticated session afterward. That is a serious account-security problem, but it is different from a flaw in MFA cryptography or a vulnerability in Microsoft 365 itself.
The numbers require careful reading
CloudSEK published several substantial figures: 5,137 total records, 474 records labelled “Complete (MFA Bypass),” 1,032 captured passwords, 4,148 session cookies, 461 targeted organizations, 3,331 unique victim IPs, and 42 VPS nodes. One node was described as active when its report was published.
Separately, reporting of a CloudSEK clarification said that 258 distinct organizations had at least one completed MFA-bypass compromise. That number should be understood as CloudSEK’s clarified assessment, not as independently confirmed victim reporting. No named victim organizations, customer-side forensics, Microsoft incident confirmation, or law-enforcement confirmation establishes the full scope in the available material.
The figures also should not be added together or treated as unique people, accounts, or compromises. The three subcategories for completed bypasses, passwords, and cookies total more than the reported record total. CloudSEK’s public material does not explain the record schema, overlap between categories, or how the 474 completed records map to the reported 258 organizations. Repeated captures, multiple artifacts associated with one victim, or other overlap are possible, but not established publicly.
The defensible conclusion is narrower: CloudSEK observed a campaign with a large claimed collection of credentials and session artifacts, aimed at hundreds of organizations, and reported completed session-replay-related compromises. The precise number of distinct accounts or organizations successfully accessed cannot be derived from the published table alone.
Why MSPs and IT service firms deserve special attention
CloudSEK listed IT services and managed service providers as the largest represented sector, with 151 organizations. That does not demonstrate that the customers of any MSP were compromised. It does, however, make the risk model more consequential.
An MSP administrator may hold broad visibility or delegated access across customer environments. If a session associated with such a role is taken, the potential impact can extend beyond one mailbox or one tenant, depending on the permissions attached to that session. This is a downstream supply-chain concern, not evidence of a documented customer breach.
For organizations that use outside IT providers, the practical questions are straightforward:
- Are provider accounts separated from ordinary user identities and protected by stronger sign-in requirements?
- Are administrative privileges limited to the smallest practical set of accounts and tasks?
- Can the organization review unusual changes to roles, mailbox rules, authentication devices, or application consent quickly?
- Do supplier incident procedures specify how sessions and refresh tokens will be revoked after a suspected phishing compromise?
These questions matter just as much for internal administrators. A captured browser session can be especially damaging when it belongs to a user with elevated rights or access to sensitive cloud resources.
FIDO2 was not shown to be broken
CloudSEK said BigBear used 69 country-specific residential proxies intended to geo-match visitors and custom JavaScript intended to interfere with FIDO2/WebAuthn browser functionality. Its reported objective was to steer targets toward weaker or non-phishing-resistant ways to authenticate.
That is not evidence that BigBear bypassed the cryptographic protections of FIDO2 or WebAuthn. The reported behavior concerns suppressing or disrupting the browser flow so that a victim may choose, or be pushed toward, a less resistant alternative. It is an important distinction because it informs the defensive response.
Microsoft advises moving away from traditional factors such as SMS codes, email-based one-time passwords, and push notifications where possible, noting that those methods can be intercepted or spoofed in man-in-the-middle phishing. It recommends phishing-resistant methods including FIDO2 and passkeys.
For Microsoft 365 administrators, the lesson is not merely to offer stronger authentication as an optional enrollment choice. Where operationally feasible, organizations should enforce a phishing-resistant authentication strength for users and especially privileged roles. That rollout needs planning for recovery, unsupported workflows, shared-device use, and emergency access. A technically strong factor does not help consistently if users can still fall back to a weaker method during a phishing encounter.
A password reset alone is not enough
A suspected AiTM compromise should be handled as possible session theft, not only credential theft. Changing the password is appropriate, but it may leave an attacker’s active session or refresh capability intact.
Microsoft’s response guidance for a compromised Microsoft 365 account starts with revoking active sign-in sessions and invalidating existing refresh tokens. Administrators should then investigate the account for signs that persistence or privilege expansion was attempted. Key checks include:
- Review registered authentication methods and devices for suspicious additions or changes.
- Inspect user-consented applications, because delegated application access can persist independently of a password change.
- Examine role assignments for unexpected administrative privileges.
- Check mailbox forwarding configuration and inbox rules, including rules intended to hide or redirect security notices and business correspondence.
- Preserve and review relevant sign-in and audit evidence before it ages out under the organization’s retention settings.
For a Windows user who believes they entered Microsoft 365 credentials into a suspicious page, the safest course is to report it immediately through the organization’s support or security channel. Delay gives an attacker more time to use a stolen session, create a forwarding rule, or establish another means of access. Users should not assume that a successful MFA prompt proves the site was legitimate.
Add device state to the access decision
Phishing-resistant sign-in is a major layer, but it should not be the only layer. Conditional Access can require a device accessing organizational resources to be marked compliant with an organization’s Intune compliance policies. This gives administrators a device-state control in addition to signals such as network location.
A compliant-device requirement can make access controls more selective by tying access to an enrolled and assessed device. But it is not a policy to deploy casually. Microsoft recommends first creating and validating the underlying Intune compliance policy, testing the Conditional Access policy in report-only mode, and excluding emergency-access accounts before broad enforcement.
Those safeguards are operational necessities, not bureaucratic extras. A poorly designed compliance policy can block legitimate work or lock administrators out during an incident. Organizations should test critical Windows device types, mobile access patterns, support processes, and break-glass procedures before making the rule mandatory.
Detection should focus on behavior, not one indicator
CloudSEK published defanged infrastructure indicators and Sigma rules relating to BigBear and Evilginx activity, including suspicious cookies, headers, Telegram credential-exfiltration behavior, and known VPS communications. These can be useful starting points for threat hunting.
They should not be treated as proof of compromise on their own. CloudSEK labelled some rules experimental and warned of false-positive risk, including the possibility that IP addresses are reassigned. Security teams should correlate an indicator hit with account activity, device context, sign-in timing, changes to authentication methods, mailbox-rule creation, application consent, and privilege events.
The broader detection objective is to identify the aftermath of session theft: unexpected sessions, account configuration changes, unusual consent grants, and access patterns that do not fit the user’s normal device or activity profile. This is more durable than relying exclusively on a short-lived list of phishing infrastructure.
Do not overstate the campaign’s current status
The available reporting contains a time-bound status conflict. CloudSEK said the operation was active when it published on September 7, 2026. Separate reporting said its administration panel remained online, while the phishing infrastructure had been offline for nearly three weeks. CloudSEK also reported that the operator deleted 26 of the 42 observed VPS nodes after late July.
These statements can reflect the difference between a control panel, historical infrastructure, and currently serving phishing nodes. They do not establish that the phishing service remains operational now. Nor does the reported multi-user model establish the real-world identity of the operator, who CloudSEK associated with the alias “General Boss.”
Even if this particular infrastructure has changed or gone quiet, the method remains relevant. AiTM phishing and session replay turn a familiar security assumption on its head: completing MFA is not always the end of the attack. For Microsoft 365 environments, the strongest response combines phishing-resistant authentication, carefully tested device-compliance policies, tight privilege controls, and an incident process that revokes sessions and refresh tokens rather than stopping at a password reset.