The technique is called browser-in-the-browser, and what makes it worth understanding is which piece of security advice it breaks. For years, the standard guidance for single sign-on has been: when the popup appears asking you to sign in with Google, Microsoft, Apple, or Steam, check the URL bar of the popup before typing anything. Browser-in-the-browser forges the URL bar itself. The check you were taught to perform is performed against content the attacker wrote.
The Habit the Attack Exploits
OAuth-style single sign-on trained everyone on a specific visual sequence. You click "Sign in with Google" on some third-party site, a small window opens on top of the page, the small window shows the identity provider's domain in its URL bar, you enter your credentials there, the window closes, and you are signed in. Millions of people run this sequence weekly, and its security rests on one fact: the popup is a real browser window, and a real browser window's URL bar cannot lie.
A browser-in-the-browser page keeps every visual element of that sequence and removes the one load-bearing fact. The victim arrives on an attacker-controlled page, usually via a phishing link. The page offers a "Sign in with Google" button. Clicking it makes a popup appear, exactly where and how a real one would. But the popup is a styled <div> inside the same page, wearing window chrome copied from the victim's operating system. The URL bar is text. The padlock is an icon. The login form posts to the attacker.
The fake can be remarkably complete. Page scripts can detect the visitor's OS and browser and render matching chrome, light or dark. The templates published in 2022 included working drag behavior inside the page, hover effects on the fake window buttons, and the correct fonts. On a phone, the job is even easier, since mobile browsers show less window chrome to forge.
Where It Has Been Used
This is not a lab curiosity. In the same month the templates were published, Google's Threat Analysis Group reported that Ghostwriter, an actor it attributes to Belarus, was already using browser-in-the-browser pages against targets in Ukraine during the opening weeks of the war. Later that year, researchers at Group-IB documented a campaign that stole Steam accounts from professional and aspiring esports players using a full browser-in-the-browser recreation of Steam's login popup, complete with a forged prompt for the victim's two-factor code.
The Steam campaign is a useful detail for a second reason: it shows that a one-time code from an authenticator app does not save you here. The fake window simply asks for the code, and the attacker relays it to the real service within the seconds it remains valid. This is the same relay logic as adversary-in-the-middle phishing, wearing a different costume.
How to Catch One by Hand
A drawn window is confined to the page that drew it, and that constraint is testable:
- Drag the popup past the edge of the browser window. A real popup is an independent window and will happily leave. A fake one clips at the parent window's boundary, because it is inside the parent page.
- Check your taskbar or window switcher. A real popup appears as a separate window in Alt-Tab and the taskbar. A fake one does not exist as far as your operating system is concerned.
- Try resizing your browser window. The fake popup moves and scales with the page content, because it is page content.
Before typing credentials into any sign-in popup, drag it outside the browser window that spawned it. A window that cannot leave its parent is not a window.
These tests work every time, and almost nobody runs them every time. That is the general problem with vigilance as a defense: it has to fire on the ten-thousandth login as reliably as the first, at the end of a long day, on a small screen. The attacks are cheap to mount and only need you to skip the ritual once.
The Defenses That Do Not Depend on Your Eyes
Two defenses beat browser-in-the-browser structurally, because they check the origin of the page programmatically rather than visually.
Your password manager's autofill. A password manager matches saved credentials against the real origin of the page, which for a fake popup is the attacker's domain, not accounts.google.com. So the autofill prompt will not appear. Treat that silence as a signal: if your password manager declines to offer credentials on a login form where it normally would, stop and figure out why before typing them manually. Manually typing a password into a form your manager refused to fill defeats the one origin check happening on your behalf.
Passkeys and hardware security keys. WebAuthn credentials are cryptographically bound to the origin they were registered on. A passkey for google.com cannot be exercised by evil-site.example no matter how convincing the pixels are, and there is no code or password for the victim to relay. Against the entire family of attacks that forge what you see, from homograph domains to fake popups, origin-bound credentials are the defense that holds while you are tired.
| Defense | Stops browser-in-the-browser? | Why |
|---|---|---|
| Checking the popup's URL bar | No | The URL bar is attacker-drawn content |
| TOTP / authenticator codes | No | The code can be phished and relayed in real time |
| The drag test | Yes, when performed | A fake window cannot leave its parent page |
| Password manager autofill | Yes | Autofill matches the real origin, which is the attacker's |
| Passkeys / WebAuthn | Yes | Credentials are origin-bound; nothing exists to relay |
What This Says About Login UX
Browser-in-the-browser works because the popup login flow asks users to make a security decision based on rendered pixels, and rendered pixels are exactly what a web page controls. Any authentication ceremony whose integrity depends on the user visually distinguishing browser chrome from page content was going to be forged eventually; the 2022 templates just did it neatly and published the result.
The durable fix is already rolling out across the industry: move the origin check from the human to the protocol. Sign-in flows that redirect in the full browser tab give the real URL bar a chance to matter, and passkeys remove the phishable secret entirely. Until the services you use get there, the drag test costs two seconds, and your password manager's silence is worth listening to.