The lure is a free month of Claude Max, offered with no card form and no download, only a single "Sign in with Google" button. The sign-in window that opens is not Google's: it is a drawing rendered by the phishing page inside the visitor's own tab, address bar and padlock included, and every credential typed into it goes straight to the operator.

Malwarebytes documented the page in September 2026. The technique underneath it, browser-in-the-browser phishing, is four years old; mr.d0x published the method in March 2022. What has changed is the packaging: on this page the forged window arrives as a reusable component.

A sign-in window that is part of the page

How browser-in-the-browser works

Single sign-on trained users to expect a small pop-up when they click "Sign in with Google" or "Sign in with Microsoft". A browser-in-the-browser page reproduces that pop-up with ordinary HTML and CSS, including a fake address bar showing the real provider's domain, and displays it on click (mr.d0x). The real address bar, the browser's own, still shows the phishing domain, while the window drawn over it shows Google's, and most users only ever look at the second one.

Why the target is the Google account

The giveaway is the bait; the Google account is the catch. A compromised Google login gives an operator the victim's email and documents, the password-reset messages for every service tied to that address, and a direct way into Claude itself, which makes it worth far more than the card number a conventional scam page would have asked for.

Every path leads to one forged window

The page borrows legitimacy it does not have to build, from Claude's logo and invented reviews to a claim that Anthropic has passed 100 million users, and stages its scarcity in code.

A reusable widget, not a one-off build

The forged window was not written for this campaign. It loads through one line of code that pulls in an outside service, presented as a reusable sign-in widget and shipped with installation instructions for whoever builds the next lure page. Whatever else the operator built, this part arrived ready-made.

Its source carries Russian-language comments that call the target "the victim", and one records a fix for dark-themed fake windows that flashed white while loading. A fix like that suggests a component that is maintained for repeated use, which is the researcher's conclusion as well.

Why standard controls miss it

Nothing on the page is technically unusual. The forged window is ordinary markup served from the operator's own page, so at the moment of sign-in there is no second domain to check, no redirect to follow and no credential form on a known-bad host. This is a structural gap in "check the URL" guidance, not an evasion trick.

The human verification step adds a second layer aimed at automated analysis, since a scanner that loads the page may never reach the stage that asks for a password. A separate browser-in-the-browser campaign against Microsoft 365 users went further, routing suspected bots to a genuine Microsoft help page (Help Net Security).

How Aegis protects against it

The delivery channel for this page has not been reported. Where a lure like it arrives by email, the defense starts before the click.

AegisAI's agents evaluate the message and the destination it points to together, and pull a malicious message out of mailboxes before users see or click it. More on how that works: inbound email security.

Related: the new world of AI spearphishing and account takeover protection.

What the reporting does not tell us

Delivery. The research does not establish how victims reach the page: search ads, social posts, email or another channel.

Scale. No victim count, hosting domain or time online has been published, so the reach of this campaign is unknown.

Reuse. The widget's installation instructions imply distribution beyond this page, but no other campaign has been publicly tied to the same code.

MITRE ATT&CK mapping

Recommendations for defenders

FAQ

References