Fake AI Ads Phishing Uses Browser-in-the-Browser and Human Operators to Capture Credentials and MFA Codes

1. Basic Information

• Article Title: Behind the Connect Button: The Fake AI Ads Campaign
• Publisher: Island
• Publication Date: October 6, 2026
• Report Update Reason: Technical review: Clarified input storage fields and submission limits, distinguished collection capabilities from actual data acquisition and successful authentication, explained what submission counts represent, identified inferred follow-on indicators, and clarified phishing-resistant authentication methods.
• Original: Island
• Related Sources: BleepingComputer, NIST SP 800-63B-4: Phishing Resistance
• Related Malware: None specified
• Related Threat Groups: Unattributed
• Related CVEs: None
• Related Products and Services: Google, Meta, TikTok, Okta authentication, Google Ads/Meta Ads accounts, portals impersonating ChatGPT, Gemini, Claude, Perplexity, Manus, and Muse
• Severity: High

2. Quick Summary

The phishing pages masquerade as AI advertising management products and draw fake browser windows to collect credentials and MFA codes. Human operators control screen transitions through Socket.IO, prompting victims to re-enter passwords, submit SMS or authenticator app codes, or approve Google or Okta push notifications.

3. Attack Flow

The same infrastructure is reused for advertising, refund, and recruitment lures. The following flow describes the AI advertising lures analyzed by Island:

1. Attackers lure victims to ad optimization, spending audit, or account connection pages impersonating ChatGPT, Gemini, Claude, Perplexity, Manus, and Muse.
2. When the victim clicks "Connect," the phishing page draws a fake browser window whose address bar displays a Google or Okta URL. The actual page's origin remains the phishing domain.
3. The client creates a record via /api/create/user and fingerprints IP, location, screen, and WebGL, sending the data to /api/send/ip.
4. The exposed state object contains identity and three password storage fields, allowing operators to use Socket.IO commands to select the next screen—such as re-entry, SMS codes, authenticator app codes, Google prompts, or Okta pushes. The number of storage fields does not determine the maximum input limit across all implementations.
5. Attackers may use the collected information to log in to legitimate services. Island observed hundreds of victim submissions, but has not published the number of successful authentications or unauthorized expenditures on individual accounts.

4. Attacker Position and Execution Location

• Attackers are remote operators managing the phishing domain and the Next.js/Socket.IO backend.
• The fake browser is rendered within the victim's browser, and credentials are sent to the attacker backend rather than AI providers or IdPs.
• Numerous frontends have been observed on Vercel, and backends on Railway or Render. This does not imply that the hosting providers themselves are the threat actors.

5. Perspective of Victims and Administrators

• Victims: The page appears as an invitation or account connection for AI advertising management features. The fake window displays a lock icon and accounts.google.com, but the outer address bar shows the phishing domain.
• Administrators: Connections to AI-related lookalike domains, api.ipify.org / ipapi.co, or Socket.IO traffic to unrelated Railway/Render hosts may appear in close succession from the same device.
• Inference: Investigate subsequent compromises if an advertising account shows unknown managers or partners added, lowered privileges for the original owner, or unapproved campaigns and spending. The number of times these were executed in this campaign has not been published.

6. Success and Failure Conditions

Success Conditions

• The victim reaches the lure and enters credentials via "Connect" without checking the outer real origin.
• The operator keeps the victim on the waiting screen and selects the appropriate MFA challenge while reviewing the input values and legitimate login results.
• Account takeover of legitimate services additionally requires that the obtained credentials and MFA materials are valid and satisfy the authentication and device requirements of the legitimate service. Submitting credentials alone does not determine a successful takeover.

Failure Conditions

• Confirming the existence of betas, advertising products, or connectors from the vendor's official site and avoiding direct connections from invitation links.
• Enforcing phishing-resistant authentication bound cryptographically to the legitimate service domain, such as WebAuthn/FIDO2 passkeys or security keys. Hardware types alone do not satisfy this property if relying solely on manually entered OTP methods.
• Blocking and detecting lookalike domains, IOCs, the combination of /api/create/user or /api/send/ip, and external Socket.IO backends.

7. What Happens Upon Success

• Google, Meta, TikTok, and Okta credentials and MFA codes are passed to the attacker.
• If an ad manager account is compromised, the impact may spread to billing profiles, linked users, and campaigns across multiple clients.
• In recruitment lures, work identities are entered, potentially leading to intrusions into email, files, and SaaS applications.
• Public information does not confirm the number of individual account takeovers, unauthorized expenditures, or subsequent compromises.

8. Observable Logs

• Email: Check for AI advertising product/beta invitations, links prompting account connection, and mismatches between displayed brands and link domains.
• Proxy / SWG / DNS: Check for close-succession traffic to IOC domains, api.ipify.org, ipapi.co, Railway/Render backends, /api/create/user, and /api/send/ip.
• Endpoint / EDR: Focus on communication within the browser process. Preserve browser history, cache, and network telemetry without assuming downloads or child processes.
• Identity / IdP: Check for logins from new devices/IPs immediately after viewing the phishing page, MFA method changes, session issuance, and Google/Okta prompts.
• SaaS / Cloud: Check for the addition of ad account managers/partners, role changes, recovery information changes, campaign creation, and increased spending.
• Network: Check for long-lived Socket.IO connections and combinations of AI brand domains with unrelated backend hosts.

9. Attack Success Determination

Confirmed in Public Information

• User Action Confirmed: Island observed hundreds of victim submissions during tracking. While this is evidence that inputs were sent to the attacker platform, it does not uniformly indicate successful logins to legitimate accounts.
• The published implementation features capabilities to send passwords, MFA codes, and device fingerprints to the attacker backend. From the hundreds of submissions, the exact number of valid credentials acquired, unique victims, or sessions obtained for legitimate accounts cannot be determined.

Determination Criteria for Your Organization

• Information Theft or Session Compromise Confirmed: Determine information acquisition based on evidence that credentials were actually sent to the attacker side. Confirm successful authentication or session compromise to legitimate accounts using separate evidence such as IdP logs. Implementation collection features alone do not confirm individual acquisition success.
• Correlate IdP successful logins, session issuance, and ad account privilege changes with phishing domain visits by timeline to distinguish between credential submissions and account takeovers.

10. Investigation Playbook

• Investigation Origin: IOC domain visits, reports of AI ad connections, /api/create/user, external Socket.IO, and unknown ad account administrators.
• Initial Verification: Verify the visited URL, referrer, outer origin, entered identity, MFA prompt, timestamp, and device.
• Endpoint and Server Investigation: Preserve browser history, cache, DNS, proxies, and network connections, and additionally check whether any downloads were executed.
• Authentication and Cloud Investigation: Check IdP sign-ins, sessions, MFA changes, OAuth grants, and ad platform role/billing/campaign changes.
• Subsequent Activity Tracking: Track new admins, owner downgrades, unapproved campaigns, spending, and mailbox/file access.
• Containment: Revoke sessions and tokens, change credentials, remove unauthorized administrators, integrations, and campaigns, and block IOCs.
• Determination Categories: Separate lure exposure, credential submission, legitimate authentication success, session compromise, ad account changes, and subsequent SaaS compromise.

11. Defense and Detection Ideas

• Single Event: Prioritize browser access to known IOCs or newly registered lookalike domains.
• Timeline Correlation: Correlate AI ad lure visits -> external Socket.IO -> new IP login -> ad account changes.
• Threat Hunting: Search for web content or traffic containing google_uid, multiple password fields, operator-command, telegram-command, or Google/Okta state names.
• Log Limitations: When relying only on encrypted traffic captured by network sensors, URL paths and Socket.IO event names cannot be inspected without decryption. General-purpose hosting domains alone can produce many false positives.
• Priority Countermeasures: Prioritize phishing-resistant authentication, integration verification from official sites, and monitoring of ad account administrators and spending.

12. Facts / Inference / Hypothesis

Facts

• Island identified a human-operated phishing platform and reported that the same Next.js/Socket.IO infrastructure is used across AI advertising, refund, and recruitment lures.
• The fake browser window displays a legitimate provider's URL in its imitation address bar, while the actual page's origin remains the phishing domain.
• The platform switches between password re-entry, SMS/authenticator app codes, and Google/Okta prompts via operator commands, and hundreds of victim submissions were observed.
• backend-production-6d75.up.railway.app was confirmed across 73 archived scans and 25 page domains between May 27 and June 20.

Inference

• Combining identity logs and ad platform audit logs enables distinguishing between post-submission account takeovers and business impact.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "14. Open Questions and Further Investigation".

13. MITRE ATT&CK Mapping

14. Open Questions and Further Investigation

• Out of hundreds of submissions, the number that led to successful logins, session acquisition, or ad spending on legitimate accounts.
• Threat actor attribution, victim regions and industries, and the distribution scale of each lure.
• Current operational status of public IOCs and the scope of unpublicized domains and backends.

15. Impact on SOCs and Organizations

New features and ad integrations in AI products are difficult to verify for authenticity. If accounts belonging to advertising agencies or managers overseeing multiple brands are compromised, the impact can spread to multiple clients within their scope of authority. SOCs should not permit connections based solely on an "AI-related site" classification, but must instead monitor outer origins, IdP sign-ins, and ad platform permission and spending changes in a unified manner.

16. Summary by Role

• For SOCs: Correlate lookalike domains, external Socket.IO, IdP sign-ins, and ad account changes by timeline.
• For Administrators: Enforce phishing-resistant authentication using WebAuthn/FIDO2 passkeys or security keys, and audit ad account manager, partner, billing, and campaign modifications.
• For Users: Verify the outermost browser origin rather than the address bar inside fake windows, and initiate AI integrations exclusively from official sites.