Eighty percent of password captures on BigBear 2.0's panel turned into live Microsoft 365 session cookies. According to CloudSEK on 7 September 2026, the Evilginx2-based phishing-as-a-service platform run under the General Boss branding proxied real Microsoft 365 and Entra ID logins, captured passwords plus MFA completions such as TOTP, push, and SMS, and exfiltrated 4,148 session cookies so affiliates could replay them into mail, Teams, SharePoint, and connected SaaS without another authentication challenge. Custom JavaScript disabled browser WebAuthn and FIDO2 during the reverse-proxy relay, 258 organizations had at least one completed compromise, and 5,137 credential or session records left the panel.
How the offy phishlet finished Microsoft 365 login for the attacker
BigBear 2.0 was not a static fake form that hoped someone would type a code into the wrong place and walk away. It was an adversary-in-the-middle reverse proxy built on Evilginx2. An adversary-in-the-middle attack sits between the user and the real identity provider, presents what looks like the legitimate login, and relays every step until authentication completes for the victim while the operator keeps a copy of the proof.
The campaign's offy phishlet targeted the OAuth 2.0 authorization flow used by Microsoft 365 and Entra ID. Victims landed on attacker-controlled infrastructure that mirrored the real Microsoft sign-in experience. Credentials went through the proxy to Microsoft. When the IdP demanded a second factor, the same relay carried TOTP codes, push approvals, or SMS codes in real time. From Microsoft's point of view the user had authenticated. From the operator's point of view the session was now theirs to harvest.
CloudSEK reported the platform had been active since at least June 2026. Researchers gained admin-panel access and documented 42 VPS nodes, mostly on Vultr, with counter-forensic cleanup that deleted 26 of those nodes from late July onward. At disclosure one node still looked active. Targeting data touched 461 organizations. Completed compromises reached 258. Unique victim IPs numbered 3,331 across more than 40 countries. Primary sectors in the panel skew were IT services and MSPs, followed by SaaS and tech, oil and gas, pharma, and consulting.
Geo-matched residential proxies sat in front of the relay so the proxied login often looked like traffic from a plausible location rather than a random data-center hop. That detail matters for defenders who still treat impossible-travel alerts as their main AiTM tripwire. Location cosmetics are a product feature on modern phishing kits, not a rare flourish.
| Control in play | What the kit did | Result for the attacker |
|---|---|---|
| Password at Entra ID login | Relayed live through Evilginx2 | Plaintext passwords captured (1,032) |
| TOTP, push, or SMS MFA | Completed in real time for the victim | 474 full MFA-completed sessions |
| Browser WebAuthn / FIDO2 | Disabled via injected JavaScript | User pushed to relayable factors |
| Post-auth session cookie | Stolen by the proxy after MFA | 4,148 cookies for affiliate replay |
Public reporting does not establish a full named victim list or exact per-organization business impact. Public reporting also does not establish proven ransomware or BEC monetization for each compromised tenant. The panel math is still ugly enough without that.
What 4,148 session cookies unlocked after authentication
Once MFA finished for the victim, BigBear 2.0's job shifted from credential relay to token theft. The session cookie is the durable proof that authentication already happened. The proxy stole that cookie. Affiliates did not need another password or another MFA prompt.
According to CloudSEK, attackers replayed captured session cookies to reach the victim's mailbox, Teams, SharePoint, and connected SaaS applications without triggering re-authentication. Panel metrics showed more than 80 percent of password entries resulted in session cookie capture. Automated replay APIs and live Telegram exfiltration bots pushed loot to at least five affiliate operators in near real time. That is how a single completed login becomes multi-app access across a Microsoft 365 estate.
SSO and federation amplify the blast radius. One good cloud session is a skeleton key for every app that trusts the same Entra ID sign-in. Mail for business email compromise staging, Teams for internal reconnaissance, SharePoint for document theft, and whatever third-party SaaS is wired to the same identity fabric all open without a fresh ceremony. Zero-trust slogans about never trust and always verify collide with classic SSO auto-login the moment a replayable federation cookie leaves the browser through a proxy.
This phase is not a second MFA puzzle. Authentication already succeeded. No login factor undoes a cookie that is already in someone else's hands. Containment from here is revoke, short session lifetimes as hygiene, continuous access evaluation, and hunting for anomalous client use of those tokens. Shortening lifetime does not prevent the original harvest. It only forces the thief to reuse or restole sooner. If the operator registers their own authenticator while the window is open, lifetime limits stop mattering for that identity.
CloudSEK's executive framing put the same point bluntly: modern AiTM attacks can hijack authenticated sessions even after MFA. The numbers behind that line on this panel were 474 complete MFA-completed authentications (about 9.2 percent of the recorded set), 1,032 plaintext passwords, and 4,148 session cookies inside 5,137 total credential or session records.
How injected JavaScript pushed users off FIDO2 in the browser
BigBear 2.0 did not politely respect phishing-resistant hardware keys when the browser offered them. According to CloudSEK, custom JavaScript injections disabled FIDO2 and WebAuthn MFA support in the browser and residential proxy pools helped bypass anti-bot checks. The attacker manipulated the authentication flow so the victim ended up using an alternative method that was weaker or not phishing-resistant.
That is a downgrade attack on the client ceremony, not a cryptographic break of a hardware authenticator. Users who would have seen a WebAuthn prompt on a clean origin were steered toward OTP, push, or SMS because those factors can ride the reverse proxy. The kit's business model depends on transferable secrets. Origin-bound signatures that never leave a device are bad for that business model, so the phishlet tried to make sure those signatures never got a clean chance.
Defenders who deployed passkeys or FIDO2 only as an optional browser method, with soft factors still allowed as fallback, walked straight into that design. The proxy does not need to steal a private key if it can convince the UI to ask for something stealable instead. Public reporting does not establish that hardware-bound keys with no phishable fallback were widely enforced at the hit organizations. The kit's JS behavior is evidence the operators expected browser WebAuthn to be present often enough to bother breaking it.
Related workforce identity failures in the same broad social-engineering class keep showing the same pattern: if a live coach or a live proxy can complete a transferable factor, the session that follows is attacker-owned. The Spring Ring Microsoft Teams helpdesk vishing wave coerced endpoint access without harvesting login codes at a form. BigBear 2.0 harvested the form and the MFA completion and the cookie. Different front door, same industrial appetite for proof that can move.
Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem. Fooling a user into a proxied Microsoft 365 ceremony is easy at PhaaS scale. Planting malware on every target endpoint is not. On this campaign the prevention claim sits at the relayed login, where passwords and MFA completions were still in play and browser FIDO2 was actively neutered. Cookie replay after that success is residual token abuse. Revoke remains hygiene once a session already exists on an attacker laptop.
If you want to skip the attack details and go straight to what can stop this class of Evilginx2 AiTM relay on workforce Entra ID login, read the related article on mfa2point0.com: where device-bound phishing-proof MFA blocks BigBear-style AiTM harvest.
FAQ
How did BigBear 2.0 get into Microsoft 365 tenants?
BigBear 2.0 got into Microsoft 365 tenants by proxying real Entra ID logins with an Evilginx2 adversary-in-the-middle phishlet named offy, capturing passwords and MFA completions in real time, then stealing the post-auth session cookie. According to CloudSEK, affiliates replayed those cookies into mail, Teams, SharePoint, and connected SaaS without another MFA prompt. The kit also injected JavaScript that disabled browser WebAuthn and FIDO2 so victims were more likely to complete a relayable factor.
Did MFA protect the organizations hit by BigBear 2.0?
MFA of the TOTP, push, and SMS variety did not protect the organizations hit by BigBear 2.0 because those factors completed successfully for the victim while the Evilginx2 proxy recorded them and the resulting session. CloudSEK documented 474 complete MFA-completed authentications and more than 80 percent of password captures yielding session cookies. Browser FIDO2 was not a reliable save either when the phishlet disabled WebAuthn in the page. The failure was at the phishable login path, not the absence of any second factor.
What could defenders still do after a BigBear 2.0 cookie was stolen?
After a BigBear 2.0 cookie was stolen, defenders still needed session revoke, refresh-token kill, continuous access evaluation, and hunting for odd client use of Microsoft 365 tokens. No login MFA step undoes a cookie that already left through the proxy. Public reporting does not establish full campaign cessation at the 7 September 2026 disclosure, so assumed exposure windows stayed open for tenants that matched the panel's targeting set until identity teams rotated sessions and reviewed risky sign-ins.
Was BigBear 2.0 aimed at consumer apps or workforce Microsoft 365?
BigBear 2.0 was aimed at workforce Microsoft 365 and Entra ID login flows, not consumer loyalty or retail customer apps. CloudSEK's panel analysis centered on OAuth 2.0 / Microsoft 365 authorization, corporate mailbox and Teams access after cookie replay, and sectors such as IT services, MSPs, SaaS, oil and gas, pharma, and consulting. The identity at risk was employee and contractor cloud access.
How large was the BigBear 2.0 operation when CloudSEK published?
When CloudSEK published on 7 September 2026, BigBear 2.0 showed 5,137 credential or session records, 258 organizations with at least one completed compromise, 461 organizations in targeting data, 3,331 unique victim IPs across more than 40 countries, 1,032 captured passwords, 4,148 session cookies, 42 VPS nodes with heavy cleanup already underway, and at least five affiliate operators on Telegram exfil bots. The operation was still partially active at disclosure.
