BigBear 2.0 phishing is targeting Microsoft 365 users by capturing authenticated session cookies after victims complete multifactor authentication. CloudSEK found thousands of credential and cookie records linked to 461 organisations across more than 40 countries.
BigBear 2.0 phishing campaign exposed
CloudSEK uncovered the phishing-as-a-service operation in June 2026 after gaining access to its administrative panel. The campaign, known as BigBear 2.0, provides affiliates with infrastructure for conducting adversary-in-the-middle phishing against Microsoft 365 accounts.
According to the data visible in the panel, the operation held 5,137 credential records. These included 4,148 captured session cookies and 1,032 plaintext passwords, showing that the service was collecting several forms of authentication material rather than relying on passwords alone.
CloudSEK identified 474 records involving completed logins where the attackers captured the authenticated session created after MFA. In these cases, victims had successfully responded to Microsoft’s authentication checks, but the resulting session cookie was intercepted by the phishing infrastructure.
The records were associated with 461 targeted organisations in more than 40 countries. This geographical spread, combined with the number of captured records, indicates that BigBear 2.0 phishing was being operated as a repeatable service rather than a narrowly targeted campaign.
IT providers were the most represented sector
IT services businesses and managed service providers accounted for 151 of the identified organisations. They were the most heavily represented sector in CloudSEK’s campaign data.
These organisations can offer attackers access beyond one compromised mailbox. Employees at IT providers and MSPs may have privileged accounts, customer administration rights, remote management access or visibility across several environments, making a stolen Microsoft 365 session particularly valuable.
The panel also showed that BigBear 2.0 was a multi-user service. CloudSEK identified at least five affiliate operators, suggesting that several individuals or groups were using the same platform and attack methods against different targets.
How BigBear 2.0 phishing bypasses MFA
BigBear 2.0 is built on Evilginx2, a framework that can place an attacker-controlled reverse proxy between a victim and Microsoft’s legitimate authentication service. This is commonly described as an adversary-in-the-middle, or AiTM, phishing technique.
Instead of presenting a completely separate imitation login form, the proxy relays information between the victim and the real Microsoft service. The user sees a convincing sign-in process, enters their username and password, and completes MFA in the normal way.
Microsoft then issues an authenticated session cookie to the browser. Because the connection is passing through the attacker’s infrastructure, BigBear 2.0 can intercept that cookie and make it available to the affiliate operating the phishing campaign.
The attacker can then attempt to replay the cookie and enter the existing Microsoft 365 session. If successful, this avoids the need to enter the password or complete another MFA challenge because the session has already been authenticated.
The attack sequence documented by CloudSEK can be summarised as follows:
- The victim is directed to a Microsoft 365 phishing link controlled by the attacker.
- Evilginx2 proxies the victim’s connection to Microsoft’s genuine authentication service.
- The victim enters valid credentials and responds to the MFA request.
- Microsoft creates an authenticated session and issues a session cookie.
- The phishing proxy captures the cookie as it passes through the infrastructure.
- An affiliate can attempt to reuse the cookie to access the authenticated account.
Residential proxies help disguise malicious access
The operation also uses residential proxies chosen according to the victim’s country. This allows subsequent traffic to appear as though it is coming from a location that is geographically consistent with the legitimate user.
That technique may reduce the effectiveness of Conditional Access policies that depend heavily on country, region or unusual travel signals. A cookie replay attempt from an expected country can appear less suspicious than access from a distant hosting provider or an unfamiliar jurisdiction.
CloudSEK observed 42 virtual private server nodes associated with the campaign. Twenty-six had been deleted from the administrative panel since late July 2026, showing that the infrastructure recorded by researchers changed over time.
FIDO2 and WebAuthn controls were targeted
Researchers found custom code intended to disable FIDO2/WebAuthn authentication on the campaign’s phishing pages. This could steer victims away from stronger, phishing-resistant authentication and towards methods that can be relayed through an adversary-in-the-middle proxy.
This distinction is important. BigBear 2.0 phishing does not technically break MFA or defeat its cryptography. It manipulates the live authentication flow and steals the session material produced after the user has satisfied the required checks.
Current scale and exploitation status
The administrative data provides direct evidence of credential collection and authenticated session interception. The 474 completed login records are especially significant because they show that the campaign progressed beyond sending phishing links and reached the point where post-MFA sessions were captured.
The available reporting does not establish how many stolen cookies were successfully replayed or how many accounts were ultimately accessed. Session cookies can also become unusable if they expire, are revoked or encounter additional access controls.
However, the combination of captured cookies, plaintext passwords, affiliate operators and distributed infrastructure demonstrates operational capability at scale. By packaging Evilginx2, residential proxies and cookie capture as a service, BigBear 2.0 reduces the expertise required to run this type of attack.
Why Microsoft 365 session theft matters
The campaign shows why a successful MFA prompt should not be treated as conclusive evidence that the resulting session is safe. Session cookies, access tokens and refresh tokens are valuable authentication material because they can represent an identity that has already passed security checks.
A hijacked Microsoft 365 session could expose email, files, contacts and other services available to the affected account. Where an MSP or IT administrator is compromised, the potential impact may extend to privileged systems or connected customer environments.
Actions tied to the BigBear 2.0 campaign
Organisations should review Microsoft 365 sign-in and session activity for unexpected access, particularly where authentication appears to come from residential networks or where a session behaves differently after a legitimate MFA event. Investigations should consider cookie theft even when logs show that MFA succeeded.
- Revoke active sessions and tokens when an account is suspected of compromise.
- Prioritise phishing-resistant authentication, including properly enforced FIDO2 or WebAuthn methods.
- Review Conditional Access policies that rely mainly on geographical location.
- Monitor high-privilege accounts at IT providers and MSPs for unusual session use.
- Investigate unexpected changes to authentication methods, inbox rules and account permissions.
BigBear 2.0 phishing demonstrates that protecting the login event is only part of the task. Organisations also need controls that can detect, restrict and invalidate suspicious authenticated sessions after MFA has been completed.
Originally reported by csoonline.com.
