Phishing

Researchers at Island have published details of a phishing platform dressed up as advertising products for AI assistants: Google Gemini, Anthropic Claude, OpenAI ChatGPT, Perplexity, Meta Muse and Manus. The sites promise campaign optimisation, spend audits and business account connections, and every one of them leads to the same Connect button. Behind it is a fake Google, Meta, TikTok or Okta sign-in window and a person who uses what you type, including multi-factor authentication (MFA) codes, while you are still on the page.

The targets are people who control ad budgets: agency staff, media buyers and administrators of manager accounts, which give access to many client ad accounts at once. Island also found the same backend running fake refund claims for Google Ads payments and fake job sites for Tesla, Louis Vuitton, Nike and Adecco, which ask applicants to sign in with work Google or Okta accounts. If your marketing team runs paid media, or your staff sign in to anything through Okta, this campaign is aimed at you.

How it works

Browser-in-the-browser (BitB) is a technique first shown publicly in March 2022. A real sign-in pop-up opens a separate browser window with its own address bar. A BitB page draws a picture of that window with HTML and CSS inside the phishing page, complete with a fake address bar that reads accounts.google.com or an Okta tenant URL. The browser's real address bar, at the top of the screen, still shows the phishing domain. Island says the kit matches its fake window to the visitor's desktop or phone, down to Safari's address pill, Chrome custom tabs and dark mode.

Before any login screen appears, the page fingerprints the device: IP address, location from services such as api.ipify.org and ipapi.co, screen size and WebGL graphics details. These go to the backend at /api/send/ip. Island notes that the visible platform rebuilds the provider's interface locally and collects credentials through its own APIs, rather than proxying the real login page the way adversary-in-the-middle kits such as Evilginx do. The first thing Google or Okta sees is the operator's own sign-in from the operator's IP address, which is why the checks below look for MFA from unfamiliar locations.

The backend is a state machine controlled by a person. Pages are built with Next.js and hosted on Vercel, backends run on Railway or Render, and victim data and commands travel over Socket.IO, a library for live two-way messaging between browser and server. When a victim submits a password, the operator tries it at the real provider and then chooses what the victim sees next through events such as operator-command and telegram-command. The kit stores up to three password attempts and has screens to request an SMS code, an authenticator app code, a Google sign-in prompt, an Okta Verify push, or a QR code to scan. Other screens reject a code as wrong, show a waiting screen while the operator works, or end the session.

Because a human picks each screen to match what the real provider is asking for, ordinary MFA does not stop it. A one-time code is relayed while it is still valid, and a push approved by the victim signs the attacker in.

What attackers are doing

The Muse lure shows how fast the operators move. Meta launched its Muse AI agent on September 8, 2026, and museads.ai, presented as an AI ads manager for paid media, appeared on September 16, eight days later. Island tied the AI ads pages, refund sites and job sites to one stack, with dozens of domains. One Railway backend, backend-production-6d75.up.railway.app, appeared behind 25 page domains in archived scans. Misconfigured public GitHub repositories exposed older source code, which showed Telegram wired in as the control channel.

Island says hundreds of victim submissions reached that Telegram channel. Submissions are form entries, not confirmed takeovers, and Island has not named the group behind the platform. Victims reached the pages through invitation emails, such as fake beta invites for AI ad products, documented separately by IRONSCALES and Intezer.

Once inside an ad account, the usual playbook is to add the attacker as an administrator, downgrade the real owner, then run fraudulent campaigns on the victim's billing or sell the account. A manager account multiplies that across every client it manages. The recruitment lures go further: a work Google or Okta login opens email, files and every single sign-on app behind it.

What to do

1. Move ad and identity accounts to phishing-resistant sign-in

Passkeys and FIDO2 security keys are bound to the real site's origin, so a sign-in started on museads.ai cannot produce a credential for accounts.google.com, and there is no code or push to relay. Enrol them for everyone with access to Google Ads, Meta Business and TikTok Ads, starting with manager account admins. In Okta, set the authentication policy rule for those apps and for the Admin Console to require a possession factor with the "Phishing resistant" constraint, which accepts FastPass or a FIDO2 authenticator and rejects SMS, voice and plain Okta Verify push.

2. If you cannot change sign-in today

Block the domains in Island's indicator list at your DNS filter and secure web gateway, including museads.ai and backend-production-6d75.up.railway.app. The domains will rotate, so also hunt for the pattern: proxy or DNS logs showing a lookup of api.ipify.org or ipapi.co followed by Socket.IO traffic (requests to /socket.io/?EIO=) to an up.railway.app or onrender.com host your business does not use.

Tell marketing and HR staff one specific check. Before typing a password into a pop-up, try to drag it outside the browser window. A real pop-up moves freely; a BitB window stops at the page edge. Then read the address bar at the very top of the browser, which the page cannot fake.

3. Check whether you were already hit

• In Google Ads, open Admin, then Access and security. Review the Users tab for people you did not invite and the Managers tab for linked manager accounts you do not recognise. In Change history, filter the last 30 days for new campaigns, budget increases and billing changes.
• In Meta Business settings, review People and Partners for new admins, and check the Security Centre for changes to two-factor settings.
• Okta's System Log is where relayed MFA shows up. Search eventType eq "user.authentication.auth_via_mfa" and eventType eq "system.push.send_factor_verify_push" for successful MFA from IP addresses or countries a user has never signed in from, and eventType eq "user.mfa.factor.activate" for new factors added afterwards.
• For Google Workspace accounts, open Reporting, then Audit and investigation, then User log events in the Admin console, and look for successful logins from new locations and changes to recovery email or phone.

4. If an account was taken

Reset the password, revoke all sessions (Clear User Sessions in Okta; Sign out on the user's Security page in the Google Admin console), and remove any factor the user did not enrol. In the ad platforms, remove added users and partners, restore the owner's admin role, unlink unknown manager accounts, check recovery details and payment methods, and pause campaigns nobody on your team created. Report unauthorised spend to Google or Meta support.

The wider lesson

Ad and marketing accounts usually sit outside the identity programme: shared logins, SMS codes and admins nobody reviews. They hold company money and, at agencies, client accounts. Treat a manager account like a privileged IT account, with phishing-resistant sign-in and a quarterly access review.

Our safeguarding and hardening work moves ad, social and identity accounts to passkeys and sets Okta and Google policies to enforce them, and our security operations team builds the detections above into your monitoring. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Island research, The Hacker News, BleepingComputer, Google Ads Help: manage account access, Google Ads Help: secure your account.