TL;DR:

  • Browser-in-the-Browser (BitB) attacks render a fake browser window inside a real browser window, creating login popups that look legitimate but steal your credentials.
  • The attack is particularly effective against “Sign in with Google/Microsoft” popups, which users are conditioned to trust.
  • Passkeys (FIDO2) are the only credential type that is fully immune to BitB — they verify the actual domain before authenticating.

Phishing has evolved considerably beyond badly-spelled emails claiming you’ve won a prize. One of the most technically convincing variants in active use is the Browser-in-the-Browser (BitB) attack — a technique where attackers create a fake browser window rendered entirely inside a real browser tab, complete with a convincing URL bar showing the legitimate login domain.

For small businesses where staff use “Sign in with Google” or “Sign in with Microsoft” for multiple apps, this attack is directly relevant and underappreciated.

How Browser-in-the-Browser Works

When you click “Sign in with Google” on a website, your browser typically opens a small popup window showing accounts.google.com. The URL bar is real, controlled by your browser, and the certificate is Google’s. This is legitimate.

A BitB attack replaces this real popup with a convincing fake. The attacker’s website renders a div element — essentially a rectangle of HTML and CSS — styled to look exactly like a browser window popup. This fake window contains:

  • A realistic-looking title bar with browser chrome (close/minimise/maximise buttons)
  • A URL bar displaying accounts.google.com (or login.microsoftonline.com, or any target)
  • A padlock icon suggesting HTTPS
  • A convincing login form inside the fake window

The user types their credentials into this fake login form. The credentials go directly to the attacker’s server. The entire interaction looks legitimate because everything outside the innermost browser window is real — the original website, the real browser, the HTTPS connection to the attacker’s server.

What the user sees:
┌─────────────────────────────────────────────────────┐
│ [Real browser chrome — legitimate website]           │
│                                                     │
│   ┌────────────────────────────────────────────┐   │
│   │ 🔒 https://accounts.google.com      [× □ −] │  ← FAKE (HTML div)
│   │────────────────────────────────────────────│   │
│   │         Sign in with Google                 │   │
│   │  Email: [your@email.com              ]     │   │
│   │  Password: [●●●●●●●●●●●●           ]      │   │
│   │  [         Next         ]                  │   │
│   └────────────────────────────────────────────┘   │
│                                                     │
└─────────────────────────────────────────────────────┘

The key insight: you cannot drag this fake popup outside the bounds of the original browser window. Real browser popups can be dragged anywhere on your screen. If a login popup is constrained to move only within the original tab, it’s fake.

Why It Bypasses Standard Defences

Password managers fail here. This is particularly concerning. Password managers auto-fill credentials based on the actual domain in the real browser URL bar. When you’re on an attacker’s website (evil-conference-site.com) and a fake Google popup appears, your password manager sees the real URL — evil-conference-site.com — and won’t auto-fill accounts.google.com credentials. But a user who notices the password manager didn’t auto-fill might simply type their credentials manually into the (fake) form.

SMS and authenticator app MFA are insufficient. Once a user submits credentials to a BitB fake login, the attacker in real-time can relay those credentials to the real Google login. Google then sends an MFA code to the user’s phone. The attacker’s fake popup asks for the code. The user enters it. The attacker completes the real login before the MFA code expires.

Security training helps, but imperfectly. The “check the URL bar” advice — standard security training — doesn’t apply here because the URL bar in the popup is fake. Security-aware users who know to check URLs can still fall for this because they’re looking at a convincingly rendered fake URL.

Who’s Using This Attack

BitB techniques were first documented by security researcher mr.d0x in 2022 and have since appeared in attack toolkits targeting both consumer and business accounts. The attack has been observed in:

  • Credential harvesting campaigns targeting Microsoft 365 accounts
  • Gaming platform credential theft (Steam was an early target because of its widespread OAuth use)
  • Business email compromise precursor attacks — compromising one employee’s Google Workspace account to then access their email for BEC fraud

For small businesses specifically, the risk scenario is: an employee receives a phishing email linking to an attacker-controlled site (perhaps posing as a document share or event registration) that presents a BitB Google Workspace login popup. The employee’s Workspace credentials are captured, giving the attacker access to email, Google Drive, and any SaaS apps connected via Google SSO.

The Only Complete Defence: Passkeys

Passkeys (FIDO2/WebAuthn credentials) are the one authentication method that is structurally immune to BitB attacks. Here’s why:

When you authenticate with a passkey, your device cryptographically signs a challenge that includes the actual origin (domain) the browser is talking to. This domain verification is performed by the browser itself, at the OS level — not by any HTML/CSS rendered on the page. A fake BitB popup rendered in HTML has no way to intercept or spoof this process.

If you try to authenticate with a passkey on evil-conference-site.com using credentials registered for accounts.google.com, authentication fails automatically. No code the attacker controls can change this.

Implementing passkeys for your business:

  • Google Workspace: Admins can require passkeys in the Admin console under Security → Authentication → Passwordless sign-in. Users set up passkeys under their Google Account security settings.
  • Microsoft 365: Managed through Azure AD (Entra ID) under Authentication methods. Enable passkey (FIDO2) as an authentication method in the policy.
  • 1Password and Bitwarden: Both support storing and auto-filling passkeys for sites that support them.

Immediate Actions That Reduce Risk

While passkey rollout is the right long-term direction, a few practical steps reduce BitB risk now:

Train staff on the drag test. A fake BitB popup cannot be dragged outside the main browser window. If they’re suspicious about a login popup, try dragging it to a second monitor or off the edge of the screen. If it stays confined, it’s fake.

Make password manager auto-fill mandatory practice. If your password manager doesn’t auto-fill a login form, treat it as a red flag and don’t fill manually. This doesn’t stop BitB completely (the user might override) but raises the cognitive barrier.

Enforce phishing-resistant MFA on critical accounts. For Google Workspace and Microsoft 365 admin accounts, require hardware security keys (YubiKey, Google Titan) rather than authenticator apps. Hardware keys perform the same origin verification as passkeys and are immune to relay attacks.

Audit SSO connections. List every SaaS application that staff access via “Sign in with Google” or “Sign in with Microsoft.” If a Google Workspace admin account is compromised, every connected app is at risk. Remove SSO connections to apps no longer in use.

Browser isolation. Enterprise browser isolation solutions (Cloudflare Browser Isolation, Menlo, Zscaler Browser Isolation) render web pages in a remote container, making CSS/HTML-based BitB attacks ineffective. This is a higher-cost control appropriate for organisations with elevated risk profiles.

Reporting a Suspected Attack

If an employee suspects they entered credentials into a BitB fake login, treat it as an incident:

  1. Change the affected account password immediately
  2. Revoke all active sessions (Google: myaccount.google.com → Security → Your devices; Microsoft: portal.azure.com → Active sessions)
  3. Review recent account activity for unauthorised access or email rule changes
  4. Report to Action Fraud (UK) at actionfraud.police.uk or your country’s relevant authority

The response window matters — attackers typically use compromised accounts within minutes.