Build1 publisher3 min readPublished
BigBear 2.0 breaks WebAuthn in the browser to force a relayable MFA fallback
CloudSEK says the kit's JavaScript disrupts FIDO2 on a cloned Microsoft 365 login and steers the victim to TOTP, SMS or push, so the tenant's authentication strength policy decides whether the relay works.
The Engineer · Build desk
What happened
- CloudSEK published a report dated 7 September 2026 tracking BigBear 2.0, an Evilginx2-based Adversary-in-the-Middle phishing service that clones the Microsoft 365 login screen, rated High severity.
- JavaScript on the fake page disrupts the WebAuthn and FIDO2 APIs and, where the policy permits alternatives, redirects the victim to relayable methods such as TOTP, SMS or push notifications.
- The proxy forwards the password and the MFA response to Microsoft in real time, then captures session cookies including ESTSAUTH and AppSessionId and uses Keep Me Signed In to extend their lifetime.
- Those cookies and the associated refresh tokens are then replayed through residential proxies to reach the victim's Microsoft 365 account, mail and files.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- contradiction BleepingComputer's headline has the service bypassing MFA, while CloudSEK's own chain requires that the tenant permitted a relayable method; which framing you accept decides whether you are waiting on Microsoft or editing a Conditional Access policy this week.
- decision Strictly requiring phishing-resistant strength is the control that stops this, and it also removes the fallback a user reaches for when a key is lost or a laptop is reimaged, so someone has to own the lockouts that follow.
- cost The proof that a downgrade happened sits with whoever holds browser history and web proxy records, outside the identity team, so an identity incident now bills detection work to teams that were never in the loop.
- exposure Inbox rules, OAuth consent grants, internal phishing and file exfiltration all become reachable using a session the tenant already accepted as MFA-complete, which means the audit trail shows an authorised user acting normally.
CloudSEK's report sorts the methods in play into two buckets: TOTP, SMS and push are relayable, FIDO2/WebAuthn is phishing-resistant [3][11]. Three of the four methods named in the chain sit on the relayable side [18]. A proxy can forward anything the user types or approves. An assertion produced by a security key is bound to the origin that asked for it, so it cannot be forwarded. That leaves one cheap route past a registered hardware key: make the browser behave as though the key is unavailable, which is what the page's JavaScript does [3]. What the user experiences is a Microsoft-shaped login that will not do FIDO2 and asks for something else instead [9].
The tenant's policy decides whether that works [7]. Having keys registered and having strength enforced are different lines in the policy, and only the second one is a control. The summary points at Microsoft's authentication strengths documentation rather than naming a setting [16], and it gives no affected-tenant count and no description of how the WebAuthn API is actually disrupted [17]. So "enforce phishing-resistant MFA" is real policy work for the identity team here, more involved than a config diff you could copy.
The chain has three stated preconditions: the user reaches the fake URL and enters credentials, the resource policy permits relayable MFA and the user completes it, and Conditional Access does not block reuse of the stolen cookies or refresh tokens [10]. The mitigation list reaches the second and third, through authentication strength and through device compliance, attestation and risk in Conditional Access, plus revocation of sessions and refresh tokens during response [11]. It does not reach the first [19]. Delivery is assumed.
Only one half of the response actually ends the access. CloudSEK treats revoking sessions and refresh tokens as additional to resetting the password [11], because the thing carrying the attacker is a cookie captured after MFA succeeded, extended by Keep Me Signed In [5].
Detection is where the bill lands. Entra sign-in logs give you the authentication method, the IP, the device and the Conditional Access outcome [8]. They may miss the in-browser WebAuthn disruption, or the fact that a cookie was reused [8]. Endpoint tooling will be quiet, because no malware has to run for this to work [13]. CloudSEK also cautions against treating residential proxy traffic as malicious on its own [14], which is a polite way of saying the network layer will not make the call for you. That pushes the burden onto browser history and user statements, and it sets a specific evidentiary bar: reaching the lure URL does not establish that anyone typed a credential into it [20].
What to watch
- Any report of the campaign succeeding against a tenant that strictly enforced phishing-resistant authentication strength, which would break CloudSEK's central caveat.
- Publication of the specific JavaScript technique used to disrupt the WebAuthn API, which decides whether a browser or platform fix is even possible.
- Evidence that Conditional Access device compliance and attestation actually stop the residential-proxy cookie replay, rather than appearing only in a mitigation list.