A single Connect click opened a browser drawn inside the real browser, complete with a fake address bar reading accounts.google.com or an Okta tenant. The real origin never left the phishing domain. According to Island Security Research on 6 October 2026 (Oleg Zaytsev and Ofek Ronen), a human-operated phishing platform posing as AI advertising tools for ChatGPT, Gemini, Claude, Perplexity, Manus, and a fake Muse Ads product stole passwords plus live SMS, TOTP, Google prompt, and Okta push responses from agency staff, media buyers, and ad-account admins, then took over Google, Meta, TikTok, and Okta-linked ad accounts for fraudulent spend or resale. 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.
The Connect button and the fake login window
The lure pages looked like product marketing for AI-assisted advertising. Muse Ads is the clearest timing tell. Meta launched Muse on 8 September 2026. The museads.ai fake appeared about eight days later. Other pages borrowed the brand gravity of ChatGPT, Gemini, Claude, Perplexity, and Manus. The call to action was simple: Connect your ad account.
Clicking Connect did not send the victim to a real identity provider. It opened a Browser-in-the-Browser window, a nested UI painted to look like a separate browser chrome with a trusted origin in the address bar. Island's description is blunt: the fake address bar displayed trusted origins such as accounts.google.com or an Okta tenant, while the real browser remained on the phishing domain. That is the whole trick. Users read the spoofed bar. The browser security model still treated the page as the phishing site.
A live operator sat behind the platform. Human operators could hold a victim on a waiting screen, reject a password, choose the next MFA prompt, and redirect the victim when the flow was complete. Password capture was not a one-shot form dump. Operators retained up to three attempts and could refuse entries that looked wrong, mistyped, or incomplete. Device fingerprints piled up in parallel: IP and location signals, screen data, WebGL, and related browser attributes that help an attacker look less like a random takeover later.
The same Next.js and Socket.IO stack powered adjacent lanes, not a separate named breach. Island tied AI ad pages to refund and billing claims and to fake job sites using brands such as Tesla, Louis Vuitton, Nike, and Adecco. Shared backend endpoints and operator commands showed one control model. Earlier source code had leaked through a misconfigured GitHub repository. Between 27 May and 20 June 2026, Island counted the shared Railway backend (backend-production-6d75.up.railway.app) in 73 archived scans across 25 lure domains. Spoofed Tesla recruitment builds on that stack were already visible in July 2025. The AI-ads wave was the sharpest workforce identity cut of a longer platform.
How live MFA interception finished the login for the attacker
This was a credential-phase harvest, not theft of an already-issued session cookie after a clean login. Real authentication had not completed for the attacker when the secrets were collected. The operator relayed or selected phishable second factors in real time so the attacker could complete login to the real Google, Meta, TikTok, or Okta-linked ad workflows with material the victim had just typed or approved.
Socket.IO commands drove the MFA stage. Island documented operator choices that mapped to challenge types, including paths equivalent to generic 2FA, authenticator-app codes, Google prompts, and Okta approve-style push. The operator could reject codes the same way they rejected passwords. SMS one-time codes, TOTP authenticator codes, Google prompts, and Okta push all share the same failure mode here: each produces a transferable proof a human on the other end of a Socket.IO channel can copy, approve, or re-enter on the real service.
That is why “we had MFA” did not save these ad managers. The BitB UI plus a coach turned the second factor into another field on a hostile page. Push fatigue was unnecessary when a live operator could simply wait for the legitimate prompt the victim expected. SIM swap was unnecessary when the SMS code was typed into the fake window. Seed database theft was unnecessary when the victim handed over the current code. Helpdesk re-enrollment was not the path Island described. The path was coached fake login at the credential ceremony.
SSO and federation made the prize larger once those credentials and live MFA responses worked. A workforce Google or Okta identity tied into ad tooling is not a single-app password. One completed login unlocks manager-level control across the integrated advertising stack the victim actually uses day to day. Public reporting does not establish primary post-authentication cookie theft or OAuth token lifting from memory as the initial access method. Access came from replaying harvested passwords and MFA responses so the attacker’s session was issued the ordinary way, only under the wrong person’s control.
| Control in play | What Island observed | Why it failed |
|---|---|---|
| Password on spoofed Google/Okta UI | Up to three attempts, operator reject | Typed into BitB, not a real origin |
| SMS / TOTP codes | Operator-selected challenge, code relay | Transferable secret on fake page |
| Google prompt / Okta push | Live approve path coached in-session | Approval is not origin-bound |
| Address-bar trust | Fake bar showed accounts.google.com or Okta | Real origin stayed on phishing domain |
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 platform is built to collect. A fix exists for this class of social engineering of identity. The companion analysis covers how device-bound, origin-bound authentication collapses the relay without asking staff to spot a nested browser chrome under pressure.
What attackers did with the ad accounts
The business goal was account takeover for spend abuse or resale, not a classic ransomware note. Aged ad accounts with clean spend history sell on Telegram for two to four times the price of new accounts. Mimecast figures cited by Island put Google Ads high-risk vertical accounts roughly in the $200 to $270 range. That secondary market explains why a polished BitB kit with a human on the wire is worth operating against media buyers and agency admins rather than random consumer mailboxes.
Once inside, attackers can add administrators, change billing paths, and keep campaigns serving while the rightful managers fight recovery. Island notes that manager-account recovery can take weeks or months. Public reporting does not quantify those timelines for this campaign, and it does not publish a named victim list. The operational mess is still obvious: advertising identity is production infrastructure. Fraudulent spend, poisoned brand inventory, and locked-out teams hit revenue and client trust long before any SOC ticket about “suspicious MFA” looks decisive.
Island’s write-up does not describe endpoint infostealers as the opening move. It describes a Connect button, a painted browser, and an operator selecting /2fa-class challenges until the real IdP accepted the attacker. Revoking sessions and rotating passwords after the fact is hygiene once the account is already burning money. It is not what failed at the moment of Connect.
Workforce ad identity sits in an awkward middle ground many security programs under-protect. It is not a consumer loyalty app. It is not always gated like a privileged admin console. Agency contractors and media buyers still authenticate to Google, Meta, TikTok, and corporate Okta tenants that federate into spend. One successful BitB session against that population is a skeleton key into budget, creative, and audience data the business treats as crown jewels in every other conversation.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: how origin-bound MFA stops BitB operator relay on ad logins.
FAQ
How did the Fake AI Ads BitB campaign actually steal ad manager access?
The Fake AI Ads BitB campaign stole ad manager access by opening a Browser-in-the-Browser window after victims clicked Connect on fake AI advertising tool pages, then having a live operator capture passwords and relay SMS, TOTP, Google prompt, or Okta push responses in real time. According to Island on 6 October 2026, the spoofed address bar showed origins such as accounts.google.com or Okta tenants while the real browser stayed on the phishing domain, so authentication completed for the attacker with harvested secrets rather than with a pre-stolen session cookie.
Did MFA protect the Google and Okta ad logins in this campaign?
MFA of the phishable kinds did not protect the Google and Okta ad logins in the Fake AI Ads BitB campaign because operators selected and relayed SMS codes, authenticator codes, Google prompts, and Okta push approvals through the fake window. Those factors are transferable proofs a human can copy. Island explicitly notes that origin-bound passkeys and hardware-backed authentication remove the reusable password and one-time-code material the platform collects.
Was this the same operation as the Tesla and luxury-brand job lures?
Public reporting from Island treats the Tesla, Louis Vuitton, Nike, Adecco, and refund-style lures as adjacent lanes on the same Next.js and Socket.IO phishing platform, not as a separately named breach with a different control plane. Shared backends, endpoints, and operator commands tie the AI-ads Connect flow to those earlier recruitment and billing themes, including the Railway backend seen in 73 archived scans across 25 domains between 27 May and 20 June 2026.
How large was the Fake AI Ads BitB campaign?
Public reporting does not establish an exact victim count or name victim organizations for the Fake AI Ads BitB campaign. Island reported hundreds of victim submissions to the platform and said activity was still ongoing at the 6 October 2026 disclosure. The commercial motive is clearer than the headcount: aged ad accounts with clean history sell on Telegram for two to four times new accounts, with cited Google Ads high-risk pricing around $200 to $270.
Why is recovering a taken-over ad manager account so painful after BitB phishing?
Recovering a taken-over ad manager account after BitB phishing is painful because attackers who finish a live password-plus-MFA relay can add their own administrators and keep serving ads while the rightful team works through provider recovery. Island notes recovery can take weeks or months. Public reporting does not quantify those timelines for this wave. Prevention still sits upstream: stop the Connect-time harvest so there is no attacker-controlled manager session to unwind.
