CloudSEK reports that the BigBear 2.0 phishing service captured Microsoft 365 passwords and authenticated session cookies from organizations across more than 40 countries. The researchers say they gained administrative access to the service's control panel and observed 5,137 credential records, including 1,032 plaintext passwords, 4,148 session cookies and 474 completed authentications in which the victim had passed an MFA challenge.
BleepingComputer reports that 461 organizations appeared in the broader targeting data, while CloudSEK clarified that 258 had at least one completed MFA-bypass compromise. Those numbers come from CloudSEK's panel analysis; Microsoft, affected organizations and law enforcement have not publicly confirmed the complete victim set.
The operational lesson is narrower and immediately useful: a password and an authenticated session are different secrets. Resetting one does not necessarily revoke the other. Recovery therefore has to invalidate sessions and refresh tokens before a team distributes replacement credentials.
What the BigBear 2.0 research supports
CloudSEK describes BigBear 2.0 as an Evilginx2-based phishing-as-a-service operation aimed exclusively at Microsoft 365. Its infrastructure relays the victim's interaction with Microsoft's real sign-in service through an attacker-controlled domain. The victim enters a password and completes an MFA challenge; the relay can then capture the session material returned after successful authentication.
That is why "MFA bypass" needs careful wording. The report does not show BigBear breaking MFA cryptography. It describes the service stealing an already authenticated browser session and replaying it. CloudSEK also reports that custom browser-side code tried to suppress FIDO2 and WebAuthn options on the relayed page so victims would fall back to methods that an adversary-in-the-middle flow could capture.
The researchers observed 42 VPS nodes over the campaign lifecycle and say the panel used country-matched residential proxies to make malicious sign-ins resemble the victim's normal location. At publication, BleepingComputer reported that the administration panel remained online while the phishing infrastructure had been offline for almost three weeks. That mixed status is another reason not to describe every observed node as active.
A password reset is not the end of a session-theft incident
An incident team that changes a password but leaves active sessions, refresh tokens or attacker-added authentication methods in place can preserve the attacker's access. The same risk applies when a compromised mailbox can reset downstream SaaS accounts or when an identity provider grants access to several services through single sign-on.
- Contain the identity and trusted device path. Restrict the affected account and confirm that administrators are working from known-clean endpoints.
- Revoke sessions and refresh tokens. Force reauthentication instead of assuming a password change invalidated every browser and application session.
- Review authentication methods. Remove unknown passkeys, MFA devices, recovery addresses, application passwords and other attacker-added methods.
- Inspect delegated access. Review OAuth grants, enterprise applications, mailbox rules, forwarding, shared-mailbox permissions and administrative role changes.
- Scope the data reached by the session. Examine sign-in and audit logs for access to Exchange, Teams, SharePoint, OneDrive, Entra ID and connected SaaS services.
- Rotate reachable secrets in dependency order. Start with credentials that can issue, reset or retrieve other access, then replace lower-privilege application secrets.
- Require phishing-resistant authentication where practical. Microsoft recommends passkeys, FIDO2 security keys, Windows Hello for Business and other phishing-resistant methods, enforced through Conditional Access according to the environment.
Move replacement credentials outside the compromised channel
Response teams often need to deliver a temporary administrator password, recovery code, API token or small recovery file. Copying that replacement into the same mailbox, Teams thread or incident ticket under investigation can expose it to the session the team is trying to remove. Keep the case record for authorization and evidence, but do not turn it into a durable plaintext store for the new value.
Verify the recipient through a known contact path, confirm that the receiving device and browser are outside the suspected compromise, and limit the new credential to the smallest useful scope and lifetime. For high-impact access, use a second approver and a separately controlled recovery identity.
Secretus can provide a time-limited, one-time delivery path for that narrow handoff after the people, devices and authorization have been verified. It can reduce persistent plaintext in email, chat and ticket history. It does not detect BigBear, revoke Microsoft sessions, make a compromised endpoint safe or prove that a recipient is who they claim to be.
What remains unknown
The public reporting does not name the affected organizations, show independent forensic confirmation from victims or establish how many captured records were later used for fraud, data theft or lateral movement. The 5,137 entries are credential records, not a count of unique people. CloudSEK's 461 targeted organizations and the 258 organizations with a completed compromise describe different subsets and should not be interchanged.
CloudSEK says it notified law enforcement and affected organizations, but no public authority statement confirms attribution to a named operator or the full scale of the campaign. Treat the panel measurements as primary researcher findings and preserve those qualifications as further evidence emerges.
Sources
- CloudSEK: primary BigBear 2.0 panel research, campaign measurements and technical analysis
- BleepingComputer: independent reporting and clarification of targeted versus compromised organizations
- Microsoft: phishing-resistant MFA guidance and supported authentication methods
- Microsoft Security: technical background on AiTM session-cookie theft and replay
