Phishing-proof MFA stops BitB ad login relay

Aged Google Ads accounts with clean spend history sell on Telegram for two to four times the price of new accounts, with high-risk verticals cited around $200 to $270. That secondary market is why a Browser-in-the-Browser phishing platform with a live operator is worth running against agency staff, media buyers, and ad-account admins. According to Island Security Research on 6 October 2026 (Oleg Zaytsev and Ofek Ronen), fake AI advertising tool pages stole passwords plus live SMS, TOTP, Google prompt, and Okta push responses so attackers could take over Google, Meta, TikTok, and Okta-linked ad accounts. Origin-bound, device-bound authentication stops that Connect-time harvest because there is no reusable password or one-time code for the operator to relay.

The lure pages marketed AI-assisted advertising under brands such as ChatGPT, Gemini, Claude, Perplexity, Manus, and a fake Muse Ads product. Meta launched Muse on 8 September 2026. The museads.ai fake appeared about eight days later. Victims clicked Connect to link an ad account. That click did not open a real identity provider. It painted a nested browser chrome with a spoofed address bar reading origins such as accounts.google.com or an Okta tenant, while the real browser origin stayed on the phishing domain. A human operator sat on Socket.IO commands, held victims on waiting screens, rejected passwords (up to three attempts), selected the next MFA challenge type, rejected codes, and redirected when the flow looked complete. Device fingerprints piled up in parallel. Public reporting does not name victim organizations or establish an exact victim count. Island observed hundreds of victim submissions, with activity still ongoing at disclosure.

Access was credential-phase work. Real authentication had not completed for the attacker when the secrets were collected. Attackers replayed harvested passwords and live MFA responses so the real service issued a normal session under the wrong control. Public reporting does not establish primary theft of already-issued session cookies or OAuth tokens from memory as the opening move. Adjacent refund and recruitment lures on the same Next.js and Socket.IO stack, including Tesla, Louis Vuitton, Nike, and Adecco themes, shared backends and operator commands. Between 27 May and 20 June 2026, Island counted the shared Railway backend in 73 archived scans across 25 lure domains. Those are lanes of one platform, not a separately named breach.

If you want the full attack narrative, read the related post on legacymfa.sucks: how BitB AI-ads phishing stole live MFA from managers.

Why phishable MFA still finished the operator’s login

At initial access, what was stolen was a credential set: the password plus a transferable second factor. Authentication for the attacker was still ahead. SMS codes, TOTP authenticator codes, Google prompts, and Okta push approvals all produce proofs a human can copy, approve, or re-enter on the real service while the victim stares at a painted window. Island documented operator commands that selected challenge types equivalent to generic 2FA, authenticator-app codes, Google prompts, and Okta approve-style push. The operator could reject bad codes the same way they rejected bad passwords.

That is not a mysterious MFA mystery. It is coached fake login at the credential ceremony. The BitB UI keeps the victim’s trust on a spoofed address bar. The browser security model still treats the page as the phishing origin. Every phishable factor the victim types or taps becomes operator fuel. Push fatigue is unnecessary when a live coach simply waits for the prompt the victim already expects. SIM swap is unnecessary when the SMS code is typed into the hostile window. Seed-database theft is unnecessary when the current code is handed over in real time.

Once those responses worked, SSO and federation widened the prize. A workforce Google or Okta identity tied into advertising tooling is not a single lonely password. One completed login unlocks manager-level control across the integrated stack the victim uses day to day. Classic SSO auto-signs many apps from one proof, which collides with zero-trust “never trust, always verify” at each boundary. Public reporting does not frame this campaign as consent phishing or broken API authorization. The identity failure was the login the operator finished with stolen material.

After that login exists, fraudulent spend, added administrators, and locked-out recovery are post-authentication impact. No login control undoes a session the real IdP already issued to the attacker. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem. Island’s disclosure describes a Connect button, a painted browser, and live MFA selection, not an infostealer as the opening move.

How phishing-proof device-bound MFA stops BitB relay

Prevention sits at the ceremony the operator tried to finish. Device-bound credentials built on public-key cryptography keep the private key inside hardware. The server holds only public keys. There is no central password database to steal and no one-time code channel for Socket.IO to mirror. A signature is origin-bound: it answers the real relying party, not a nested chrome drawn on a hostile domain. The BitB window cannot complete a true origin-bound ceremony, so the harvest-and-replay path breaks before the attacker receives a usable ad-manager session.

That is prevention, not detection. The goal is not to spot a suspicious approve after the fact. The goal is to remove the transferable factors the platform is built to collect. Island’s own recommendation line matches the mechanics: origin-bound passkeys and hardware-backed authentication remove the reusable password and one-time-code material this kit needs.

Passkeys and FIDO2 are phishing-resistant at the login act. A key pair lives on the enrolled device. The private key never leaves hardware. The authenticator signs a challenge bound to the real origin an enterprise IdP presents, not to whatever string a BitB bar displays. On a phishing-proof IdP that only accepts hardware-bound signatures, a generic enterprise login flow demands that fresh signature from the already-enrolled device. The operator watching Socket.IO never receives a password field worth three retries or an OTP string worth pasting into the real service. That is why origin-bound cryptography collapses this exact relay class.

MFA 2.0 is phishing-proof across the full identity lifecycle, not only at authentication. Registration, device onboarding, authorization, authentication, and decommissioning never reintroduce a phishable secret a coach can read out or relay. This campaign’s documented path was coached fake login, not helpdesk re-enrollment. Public reporting does not show TAP issuance or recovery-desk social engineering as the access method. The ladder still matters for ad identity programs that harden login and leave enrollment soft. If email OTP, SMS, or push can still register a new device, an attacker who later controls that channel can enroll hardware that then signs requests that look legitimate. Full-lifecycle coverage is what keeps a future recovery story from reopening the same transferable-secret hole the BitB operator exploited at Connect. The device-bound architecture enforces that boundary without asking staff to spot nested browser chrome under deadline pressure.

When cloud IdP sessions and multi-app advertising stacks are in play, blast radius matters as much as the first factor. Classic SSO issues one shared proof many apps trust. Bolting more detection onto that design is the wrong answer. Secure Explicit Sign-On keeps one-tap user experience while each application receives its own fresh, device-bound signature. No shared, reusable federation cookie exists to replay across mail, files, CRM, and ad consoles after a single bad moment.

If a session was already issued through a completed phishable login, revoke access and refresh tokens, shorten what you can, and hunt for attacker-added administrators. Token lifetime limits do not prevent BitB relay. They only force the attacker to re-steal sooner, and they stop mattering if the attacker registers their own authenticator during the window. Fooling a user into a proxied login is easy. Planting malware on an already-logged-in PC is not. For this campaign, the prevention claim is the Connect-time login, not endpoint forensics after the money is already moving.

Key Takeaways for Defenders

• Require origin-bound, device-bound authenticators on workforce Google, Okta, and ad-platform admin paths used by agencies and media buyers; retire SMS, TOTP, and approve-push as sufficient second factors on those routes.
• Treat advertising manager identities as production infrastructure with the same authentication bar as other privileged cloud consoles, including contractors.
• Prefer per-app, device-bound proof over a single shared SSO cookie that unlocks the entire ad and productivity stack after one coached ceremony.
• After any suspected Connect-time compromise, revoke sessions, remove unknown admins, and rotate linked billing paths immediately; that is containment, not the primary control.
• Hunt for lookalike AI-ads, refund, and recruitment domains as one platform pattern, not isolated brand incidents.

Workforce ad login is where brand budget, creative, and audience data actually live. Closing the phishable ceremony is how you keep the operator’s waiting screen from ever becoming a manager session.

FAQ

Would passkeys have stopped the Fake AI Ads BitB operator relay?

Yes. Passkeys would have stopped the Fake AI Ads BitB operator relay on the login path Island described because origin-bound signatures do not yield a reusable password or one-time code a human can copy from a painted window. According to Island on 6 October 2026, the platform collected passwords plus SMS, TOTP, Google prompt, and Okta push material while the real browser origin stayed on the phishing domain. A true passkey ceremony bound to the real enterprise IdP origin cannot complete inside that nested chrome, so the attacker never finishes authentication with relayed secrets.

Why call MFA 2.0 phishing-proof instead of phishing-resistant for this campaign?

MFA 2.0 is phishing-proof for the Fake AI Ads BitB campaign class because it eliminates phishable factors across the full identity lifecycle, not only at the login act. FIDO2 and passkeys are correctly called phishing-resistant when they harden authentication with origin-bound keys. Enrollment or recovery that still uses email OTP, SMS, or push can reintroduce a transferable secret. Phishing-proof coverage closes registration, device onboarding, authorization, authentication, and decommissioning so a coach has nothing to relay at Connect time or later when someone asks to add a device.

Does MFA 2.0 rely on classic SSO for Google and Okta ad stacks?

No. MFA 2.0 does not rely on classic SSO for Google and Okta-linked ad stacks because one stolen or mis-issued shared session becomes a skeleton key across every integrated app. Secure Explicit Sign-On keeps the familiar one-tap experience while each application receives its own fresh, device-bound signature. In the Fake AI Ads BitB pattern, that design shrinks blast radius after any residual post-auth problem and refuses the “one proof unlocks the advertising estate” failure mode federation creates when a coached login succeeds.

If cookies were already stolen, can phishing-proof MFA undo the takeover?

No. Phishing-proof MFA cannot undo a Fake AI Ads BitB takeover after the real IdP has already issued a session to the attacker. Public reporting frames this campaign as credential-phase harvest and replay, not primary cookie theft from memory. Closing the phishable login stops the kit from ever receiving that session. Once a manager session exists, defenders still need explicit revoke, admin cleanup, and spend controls. Malware on a machine that already holds a legitimate session is a harder, separate problem from Connect-time BitB relay.

What should security teams change first on ad-manager identity?

Security teams should first remove phishable passwords, SMS, TOTP, and push as sufficient controls on workforce ad-manager paths into Google, Meta, TikTok, and corporate Okta tenants, and require device-bound, origin-bound authenticators instead. The Fake AI Ads BitB campaign succeeded because those transferable factors were exactly what the live operator collected. Pair that login hardening with per-app proof rather than a single long-lived SSO cookie, and treat agency and contractor ad admins with the same authentication bar as other privileged cloud operators.