A phishing-as-a-service operation targeting Microsoft 365 users has harvested thousands of session cookies that could be used to hijack authenticated sessions after victims complete multifactor authentication, CloudSEK said. The cybersecurity firm said in a report that it uncovered the operation, known as BigBear 2.0, in June after gaining access to its administrative panel. The panel contained 5,137 credential records linked to 461 targeted organizations across more than 40 countries. CloudSEK also reported 4,148 captured session cookies and 1,032 plaintext passwords. The firm said 474 records showed completed logins in which attackers captured the authenticated session created after MFA. BigBear 2.0 is built on Evilginx2, a framework that places an attacker-controlled reverse proxy between the victim and Microsoft’s legitimate authentication service. The victim signs in through the proxied page and completes MFA as usual. Once Microsoft issues an authenticated session cookie, the phishing infrastructure can intercept it and allow the attacker to reuse the session without completing the authentication process again. The operation also uses residential proxies selected according to the victim’s country, which can make malicious authentication traffic appear geographically consistent with the user. CloudSEK said this technique can weaken location-based checks used in Conditional Access policies. Researchers also found custom code designed to disable FIDO2/WebAuthn authentication on the phishing pages, potentially steering users toward weaker, phishable authentication methods. CloudSEK described BigBear 2.0 as a multi-user service with at least five identified affiliate operators. The company said it observed 42 virtual private server (VPS) nodes over the campaign, with 26 deleted from the panel since late July. IT services and managed service providers accounted for 151 of the organizations identified by CloudSEK, making them the most heavily represented sector in its data. Such organizations can present especially valuable targets because employees may hold privileged access to customer environments and administrative systems. ## Session theft moves into the mainstream The significance of BigBear 2.0 is not just its ability to capture authenticated sessions after MFA, but the way it packages techniques once associated with more skilled attackers into a service that can be used at scale, said Keith Prabhu, founder and CEO of Confidis. The underlying technique is not new, said Akshat Tyagi, associate practice leader at HFS Research. “What BigBear 2.0 changes is accessibility and scale,” Tyagi said. “It packages AiTM phishing, residential proxies and automated cookie replay into a service that lowers the expertise needed to run these attacks.” That shift means enterprises need to think beyond protecting the authentication event itself, he said, because a captured session may give an attacker access to Microsoft 365 without another password or MFA challenge. Prabhu added that successful MFA should no longer be treated as proof that an account or session remains secure. Session cookies and access and refresh tokens should be treated as high-value authentication material rather than technical artifacts behind the password, said Sakshi Grover, senior research manager for cybersecurity products and services at IDC Asia Pacific. The risk, she said, is that many enterprise controls are still geared toward detecting credential theft rather than the hijacking of an already authenticated session. ## Phishing-resistant authentication becomes critical OTP, SMS, and push-based MFA should not be relied on as standalone defenses against this type of attack, Tyagi said, because the attacker can allow the legitimate user to complete authentication before stealing the resulting session. Tyagi said enterprises should enforce phishing-resistant authentication such as FIDO2/WebAuthn passkeys rather than merely making it available alongside weaker alternatives. Prabhu pointed to Windows Hello for Business and certificate-based authentication as additional options, with stronger methods enforced through Conditional Access authentication strengths. Grover said organizations should also use Continuous Access Evaluation and token protection where Microsoft 365 supports them, but cautioned against treating token protection as a complete solution because coverage varies across platforms, clients and workloads. The problem is also operational, Grover said. Identity and access tools are not always sufficiently integrated with security operations or SIEM platforms, leaving potentially useful identity signals disconnected from the analysts responsible for detecting attacks. ## Password resets are not enough “Treat the event as an active session compromise, not merely a stolen-password incident,” Prabhu said. He recommended disabling or containing the affected account, revoking Entra sign-in sessions and refresh tokens, and forcing reauthentication. Incident responders should then examine Microsoft 365 logs for evidence of mailbox access, malicious inbox rules, unusual OAuth consent, newly registered MFA devices, privilege changes, and access to other cloud applications. Tyagi cautioned that IP location may provide limited reassurance in such investigations because residential proxies can make attacker activity appear geographically consistent with the legitimate user. Responders should instead focus on reconstructing what occurred during the compromised session, he said. Investigators should also determine whether the stolen session was used to reach other employees, customers, or external contacts, Prabhu added. Grover said organizations should also include session hijacking in tabletop exercises, testing how identity, security operations, messaging, and cloud teams would coordinate during an authenticated-session compromise. Such exercises can expose gaps that may not emerge in simulations centered on conventional credential theft or ransomware, she said.

A phishing-as-a-service operation targeting Microsoft 365 users has harvested thousands of session cookies that could be used to hijack authenticated sessions after victims complete multifactor authentication, CloudSEK said. The cybersecurity firm said in a report that it uncovered the operation, known as BigBear 2.0, in June after gaining access to its administrative panel. The panel contained 5,137 credential records linked to 461 targeted organizations across more than 40 countries. CloudSEK also reported 4,148 captured session cookies and 1,032 plaintext passwords. The firm said 474 records showed completed logins in which attackers captured the authenticated session created after MFA. BigBear 2.0 is built on Evilginx2, a framework that places an attacker-controlled reverse proxy between the victim and Microsoft’s legitimate authentication service. The victim signs in through the proxied page and completes MFA as usual. Once Microsoft issues an authenticated session cookie, the phishing infrastructure can intercept it and allow the attacker to reuse the session without completing the authentication process again. The operation also uses residential proxies selected according to the victim’s country, which can make malicious authentication traffic appear geographically consistent with the user. CloudSEK said this technique can weaken location-based checks used in Conditional Access policies. Researchers also found custom code designed to disable FIDO2/WebAuthn authentication on the phishing pages, potentially steering users toward weaker, phishable authentication methods. CloudSEK described BigBear 2.0 as a multi-user service with at least five identified affiliate operators. The company said it observed 42 virtual private server (VPS) nodes over the campaign, with 26 deleted from the panel since late July. IT services and managed service providers accounted for 151 of the organizations identified by CloudSEK, making them the most heavily represented sector in its data. Such organizations can present especially valuable targets because employees may hold privileged access to customer environments and administrative systems. ## Session theft moves into the mainstream The significance of BigBear 2.0 is not just its ability to capture authenticated sessions after MFA, but the way it packages techniques once associated with more skilled attackers into a service that can be used at scale, said Keith Prabhu, founder and CEO of Confidis. The underlying technique is not new, said Akshat Tyagi, associate practice leader at HFS Research. “What BigBear 2.0 changes is accessibility and scale,” Tyagi said. “It packages AiTM phishing, residential proxies and automated cookie replay into a service that lowers the expertise needed to run these attacks.” That shift means enterprises need to think beyond protecting the authentication event itself, he said, because a captured session may give an attacker access to Microsoft 365 without another password or MFA challenge. Prabhu added that successful MFA should no longer be treated as proof that an account or session remains secure. Session cookies and access and refresh tokens should be treated as high-value authentication material rather than technical artifacts behind the password, said Sakshi Grover, senior research manager for cybersecurity products and services at IDC Asia Pacific. The risk, she said, is that many enterprise controls are still geared toward detecting credential theft rather than the hijacking of an already authenticated session. ## Phishing-resistant authentication becomes critical OTP, SMS, and push-based MFA should not be relied on as standalone defenses against this type of attack, Tyagi said, because the attacker can allow the legitimate user to complete authentication before stealing the resulting session. Tyagi said enterprises should enforce phishing-resistant authentication such as FIDO2/WebAuthn passkeys rather than merely making it available alongside weaker alternatives. Prabhu pointed to Windows Hello for Business and certificate-based authentication as additional options, with stronger methods enforced through Conditional Access authentication strengths. Grover said organizations should also use Continuous Access Evaluation and token protection where Microsoft 365 supports them, but cautioned against treating token protection as a complete solution because coverage varies across platforms, clients and workloads. The problem is also operational, Grover said. Identity and access tools are not always sufficiently integrated with security operations or SIEM platforms, leaving potentially useful identity signals disconnected from the analysts responsible for detecting attacks. ## Password resets are not enough “Treat the event as an active session compromise, not merely a stolen-password incident,” Prabhu said. He recommended disabling or containing the affected account, revoking Entra sign-in sessions and refresh tokens, and forcing reauthentication. Incident responders should then examine Microsoft 365 logs for evidence of mailbox access, malicious inbox rules, unusual OAuth consent, newly registered MFA devices, privilege changes, and access to other cloud applications. Tyagi cautioned that IP location may provide limited reassurance in such investigations because residential proxies can make attacker activity appear geographically consistent with the legitimate user. Responders should instead focus on reconstructing what occurred during the compromised session, he said. Investigators should also determine whether the stolen session was used to reach other employees, customers, or external contacts, Prabhu added. Grover said organizations should also include session hijacking in tabletop exercises, testing how identity, security operations, messaging, and cloud teams would coordinate during an authenticated-session compromise. Such exercises can expose gaps that may not emerge in simulations centered on conventional credential theft or ransomware, she said. _The article originally appeared on CSO._

CVE-2026-1727 is a vulnerability classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) affecting Google Cloud Gemini Enterprise (formerly Agentspace). The root cause lies in the use of predictable Google Clou