MFA 2.0 stops BigBear AiTM at Entra ID login

Eighty percent of password captures on BigBear 2.0 turned into live Microsoft 365 session cookies. According to CloudSEK on 7 September 2026, the Evilginx2 phishing-as-a-service platform under the General Boss brand proxied real Entra ID workforce logins, completed TOTP, push, and SMS for the victim, disabled browser WebAuthn with injected JavaScript, and handed affiliates 4,148 replayable cookies across 258 organizations. Device-bound phishing-proof authentication stops that path at the login ceremony: there is no transferable secret to relay and no origin the reverse proxy can satisfy. Cookie replay after a completed login is residual token abuse. Revoke remains hygiene, not the prevention claim.

Why relayable Entra ID factors finished BigBear’s Evilginx2 path

CloudSEK gained admin-panel access to BigBear 2.0, an Evilginx2-based phishing-as-a-service stack aimed at workforce Microsoft 365 and Entra ID. An adversary-in-the-middle attack places attacker infrastructure between the user and the real identity provider, presents a convincing login, and forwards every step until authentication completes for the victim while the operator keeps a copy of the proof. The offy phishlet sat on the OAuth 2.0 authorization flow, mirrored the real sign-in experience, and relayed credentials and second factors until Microsoft treated the victim as authenticated. The proxy then stole the post-auth session cookie.

Documented panel figures include 5,137 credential or session records, 1,032 plaintext passwords, 474 complete MFA-completed authentications, 4,148 session cookies, 461 organizations in targeting data, and 3,331 unique victim IPs across more than 40 countries. Primary sectors skewed to IT services and MSPs, then SaaS and tech, oil and gas, pharma, and consulting. Geo-matched residential proxies dressed the relay so location checks often saw a plausible client rather than a bare VPS hop. Affiliates received near-real-time Telegram exfils and used automated cookie replay APIs against mail, Teams, SharePoint, and connected SaaS.

Public reporting does not establish a full named victim list, exact per-organization business impact, or proven ransomware or BEC monetization for each tenant. The operation was still partially active at disclosure.

At initial access the stolen material was still a credential path: password plus a live MFA completion. TOTP codes, push approvals, and SMS codes are transferable. The victim typed or approved them on what looked like Microsoft. The proxy forwarded them in real time. Microsoft issued a session because the ceremony looked legitimate. That is why CloudSEK could count 474 full MFA-completed authentications and why more than 80 percent of password entries yielded cookies. The second factor worked for the user and still failed the organization.

Browser WebAuthn and FIDO2 did not reliably save the day either. According to CloudSEK, custom JavaScript injections disabled FIDO2 and WebAuthn support in the browser so the flow pushed victims onto weaker, relayable methods. That is a client-ceremony downgrade, not a break of hardware cryptography. If soft factors remain allowed as fallback, the kit’s business model stays intact: steal something that can ride a reverse proxy.

After MFA completed, the stolen material changed character. The session cookie is proof that authentication already happened. Affiliates replayed it into the Microsoft 365 estate without another challenge. No login factor undoes a cookie that already left through the proxy. SSO and federation widen the blast radius: one good Entra ID session opens mail, chat, files, and whatever SaaS trusts the same sign-in. Classic SSO auto-login collides with zero-trust “never trust, always verify” the moment a replayable federation cookie is copied off a proxied browser.

Shortening session lifetime does not prevent the harvest. It only forces reuse or re-theft sooner. If an operator registers their own authenticator during the access window, lifetime limits stop mattering for that identity. Containment after cookie theft is revoke, refresh-token kill, continuous access evaluation, and hunting odd clients. That work is necessary and harder than stopping the relayed login.

If you want the full attack-chain narrative, read the related post on legacymfa.sucks: how BigBear 2.0's Evilginx2 PhaaS stole Microsoft 365 cookies after MFA.

What phishing-proof device-bound login changes on AiTM relay

The prevention claim for BigBear-style Evilginx2 sits at initial access, not at cookie forensics. A phishing-proof, device-bound design issues origin-bound public-key signatures from hardware the user already controls. There is no OTP to type, no push to approve, no SMS to forward, and no recovery secret a reverse proxy can capture. The private key never crosses the network. A fake or proxied origin cannot complete a signature that the real enterprise IdP will accept for that relying party.

Against this kit that means the live relay fails before Microsoft ever mints the session the panel wanted. Custom JavaScript that tries to hide WebAuthn is irrelevant when the IdP simply does not offer a phishable alternative to fall back to. Geo-matched residential proxies cannot launder a ceremony that never produces a transferable factor. Closing the phishable login stops this path. Fooling a user into a proxied Microsoft 365 ceremony is easy at PhaaS scale. Planting malware on every target endpoint is not.

Once a legitimate session already exists on a machine, malware or an infostealer can still lift cookies from that endpoint. No login control erases tokens stolen after authentication. On BigBear 2.0 the documented industrial path was the reverse-proxy harvest, not a mass endpoint compromise campaign. Prevention, not detection is the right framing for the AiTM phase: keep the attacker from ever holding the session. Revoke stays hygiene for the harder residual case.

SSO depth needs an architectural answer, not another detector bolted onto a shared cookie. Secure Explicit Sign-On keeps the one-tap user experience while authenticating each application with its own fresh, device-bound signature. No shared, reusable federation cookie exists to replay from mail into Teams into SharePoint. That shrinks the skeleton-key problem CloudSEK described when affiliates reused one cookie across connected SaaS.

Compared with optional browser passkeys that still allow OTP or push fallback, full-lifecycle phishing-proof coverage refuses the downgrade the offy phishlet depended on. The device-bound architecture binds proof to hardware and origin across the ceremony the kit tried to proxy.

Key Takeaways for Defenders

• Enforce phishing-proof, device-bound authentication for workforce Entra ID and Microsoft 365 with no OTP, push, or SMS fallback the proxy can complete.
• Treat optional browser WebAuthn with soft-factor fallback as downgrade-prone against JS-injecting AiTM kits.
• Prefer per-app device-bound sign-on over classic SSO session cookies that unlock mail, Teams, SharePoint, and SaaS from one theft.
• Keep session revoke, refresh-token invalidation, and continuous access evaluation as containment when a cookie may already be gone.
• Do not rely on geo or impossible-travel alone; residential proxy pools are a product feature on modern PhaaS.

Passkeys harden login; proof closes the full lifecycle

Passkeys and FIDO2 put a key pair on the authenticator so the private key stays in hardware and the IdP verifies an origin-bound signature. Industry language correctly calls that phishing-resistant at the login act: a lookalike site on the wrong host should not receive a usable assertion. Illustrate it on a generic enterprise IdP that demands hardware-bound signatures only. The user approves a local gesture; the server sees a public-key proof tied to that exact origin. BigBear 2.0’s answer was not to steal those private keys. It disabled browser WebAuthn in the page and steered people to factors the proxy could relay. Resistance at login helps only when the deployment refuses the soft-factor escape hatch the kit forced open.

Public reporting does not show BigBear 2.0 abusing helpdesk TAP issuance or recovery re-enrollment as the primary path. The gap that mattered was still lifecycle policy at the login surface: phishing-resistant FIDO2 in the browser as an option, with phishable OTP, push, or SMS still accepted when the page could not complete WebAuthn. Passkeys harden one stage. They do not, by themselves, forbid every phishable factor at registration, device onboarding, authentication, and decommissioning. Phishing-proof coverage means no transferable secret appears at any of those stages, so a reverse proxy cannot shop for a weaker method mid-flow. That ladder difference is why resistant login and proof across the identity lifecycle are not synonyms on an Evilginx2 campaign that actively neuters browser WebAuthn.

Related workforce failures keep splitting the same industrial appetite for movable proof. Spring Ring’s Teams helpdesk vishing coerced endpoint control without finishing a login form. BigBear 2.0 finished the form, the MFA completion, and the cookie. Different front door. Same lesson at the identity layer: remove transferable factors before the session is born.

FAQ

Would phishing-proof MFA have stopped BigBear 2.0’s Evilginx2 relay?

Phishing-proof, device-bound MFA would have stopped BigBear 2.0’s Evilginx2 relay at the Entra ID login because the proxy would have had no password, OTP, push, or SMS secret to complete and no origin-bound private key it could exercise remotely. According to CloudSEK, the kit needed those relayable completions and a post-auth cookie. Preventing the login harvest means the panel never receives that cookie from the proxied ceremony. Replaying a cookie stolen later by malware on an already-logged-in PC is a separate, harder problem.

Why didn’t browser FIDO2 save tenants hit by BigBear 2.0?

Browser FIDO2 did not reliably save tenants hit by BigBear 2.0 because the phishlet injected JavaScript that disabled WebAuthn and FIDO2 support and pushed users onto TOTP, push, or SMS. CloudSEK described that manipulation explicitly. Optional phishing-resistant passkeys with soft-factor fallback match the kit’s downgrade model. A deployment that refuses phishable alternatives closes the escape hatch the operators automated.

Does device-bound MFA stop replay of Microsoft 365 cookies after theft?

Device-bound MFA does not stop replay of Microsoft 365 session cookies after they are already stolen, because that phase is post-authentication token abuse. On BigBear 2.0, CloudSEK documented affiliates replaying cookies into mailbox, Teams, SharePoint, and connected SaaS without another MFA prompt. The prevention win is stopping the AiTM login so the cookie is never minted for the attacker. Revoke, continuous access evaluation, and tighter session binding remain the containment tools once a token exists outside the org.

Why avoid classic SSO if Secure Explicit Sign-On is available?

Classic SSO should be avoided for this class of breach because one stolen Entra ID session cookie became a skeleton key across Microsoft 365 apps and connected SaaS in BigBear 2.0’s replay model. Secure Explicit Sign-On keeps one-tap UX while each application gets its own fresh device-bound signature, so there is no shared replayable federation cookie to carry from mail into every integrated system. That design aligns better with always-verify access boundaries than auto-login from a single proof.

How is phishing-proof MFA different from phishing-resistant passkeys here?

Phishing-proof MFA covers the full identity lifecycle, while typical FIDO2 or passkey deployments are phishing-resistant at the login act only. BigBear 2.0 showed why the distinction matters: the kit completed phishable factors and disabled browser WebAuthn mid-flow. Full-lifecycle coverage means registration, device onboarding, authentication, and decommissioning never introduce a transferable secret a reverse proxy can harvest or force.