New phishing method: “Browser-in-the-Browser” (BITB) goes cookie-mode

Attackers now mimic consent banners and SSO pop-ups to steal logins. Here’s how to spot and stop it.

Cookie banners are everywhere. “This website uses cookies…” pops up, you click Accept, then a helpful “Continue with Google/Microsoft/Apple” window appears. It all looks normal - the logo is right, the URL bar looks legit, even the hover links feel real. One problem: the entire “window” is a counterfeit drawn with HTML/CSS/JS inside the page you’re already on.

That’s the essence of a Browser-in-the-Browser (BITB) attack. And the latest twist weaponizes cookie consent overlays and SSO convenience to lower your guard.

Why URL checks fail here

We’re taught to check the address bar. But in a BITB phish, what looks like a browser window (complete with a “URL bar”) is just pixels- not a real browser chrome. You’re still on the attacker’s site; they’re simply rendering a believable mini-window on top.

Modern web tooling can convincingly mimic:

• Native window chrome (close/minimize buttons, draggable title bar)
• Identity provider (IdP) branding and flows
• Hover-tooltips that display fake “https://accounts.google.com/…” previews
• Keyboard focus rings, tab order, and even OS-style shadows

The result: a login prompt that feels indistinguishable from the real SSO dialog.

The cookie-consent piggyback

Attackers now chain two familiar moments:

1. Consent banner: “This website uses cookies… [Accept] [Manage preferences]”
2. SSO nudge: “To save your preferences, sign in with Google/Microsoft/Apple.”

Because you already agreed to the cookie prompt, the follow-up SSO looks like part of a legitimate settings flow. The BITB pop-up appears, you enter credentials… and those go straight to the attacker.

Watch for these red flags:

• Consent banner immediately followed by an SSO prompt on unfamiliar sites
• SSO required just to view content or dismiss a banner
• Inconsistent branding (fonts, spacing, copyright text) in the “window”
• The “window” never escapes the browser’s bounds (more on this test below)

Quick reality checks (30 seconds)

Even a perfect visual spoof can’t copy native window behavior:

1. Drag test
   Try dragging the login window beyond the browser’s edges.

• Real pop-ups can leave the page area.
• Fake BITB windows are trapped inside the current tab.

2. Minimize test
   Minimize your browser.

• Real secondary windows (system pop-ups) can remain visible or appear as a separate app/window.
• Fake ones disappear with the tab.

3. Taskbar/app switcher test
   Look for a separate window in your OS taskbar/Alt-Tab.

• Real auth windows appear as their own entity.
• Fake ones do not.

If any test fails, stop. Close the tab. Do not enter credentials.

How to protect yourself (for everyone)

• Use a password manager. It autofills only on exact domains it trusts; it will not fill inside a fake BITB window.
• Prefer phishing-resistant MFA (FIDO2/WebAuthn keys). Even stolen passwords are useless without your hardware key, and keys check the real origin.
• Type the URL yourself. If an SSO prompt appears on a site you don’t fully trust, open a new tab and go directly to your provider (e.g., accounts.google.com, login.microsoftonline.com), then navigate from there.
• Be skeptical of SSO requests tied to “cookie settings.” You should not need to sign in to decline ad tracking.
• Report suspicious flows to IT/Sec. Fast reporting limits damage to others.

Enterprise playbook (for CISOs, IT & AppSec)

Identity & MFA

• Enforce FIDO2/WebAuthn for privileged and high-risk users.
• Restrict OAuth consent to approved apps; monitor new OAuth grants.
• Block legacy/weak MFA, SMS codes for admins, and unsecured device enrollment.

Browser & endpoint

• Deploy enterprise policies: disable site-controlled pop-ups for high-risk domains; turn on Enhanced Safe Browsing where available.
• Detect UI redressing: EDR rules for suspicious overlay behavior, oversized modals, full-screen iframes, and unusual z-index stacking patterns near login journeys.

Web/app hardening

• Use Content Security Policy and strict frame-ancestors on IdP and app pages to limit clickjacking.
• Implement OAuth PKCE, exact redirect URI allowlists, and branded, consistent login UX.
• Add Login CSAT / abuse telemetry (unexpected focus traps, keyboard nav anomalies) to flag spoof-like UX.

Training & simulation

• Run targeted simulations featuring consent-banner → SSO chains and BITB overlays.
• Teach the three tests (Drag, Minimize, Taskbar) and password-manager cues.

Developer checklist (kill the confusion at the source)

• Always open SSO in a true system/browser window (window.open with appropriate features) and keep UX consistent across products.
• Provide a visible “Open in new window” link to the IdP domain (e.g., “Continue at login.microsoftonline.com”), and log the click event.
• Show your first-party domain near SSO buttons (“You’re signing in to: your-company.com”).
• Instrument and alert on pages that display modal overlays with spoofed address bars or draggable chrome elements.

If you think you were tricked

1. Change the password for the impacted account from a known-good device and browser.
2. Invalidate sessions & tokens (IdP/SSO admin).
3. Review OAuth grants and remove suspicious third-party app access.
4. Rotate secrets (API keys, personal access tokens) if there’s any chance of exposure.
5. File an incident report so SecOps can hunt for lateral movement.

TL;DR

• BITB turns entire login windows into page elements - including fake URL bars.
• The new angle piggybacks on cookie consent flows to feel routine.
• Use a password manager and FIDO2/WebAuthn.
• When in doubt, run the Drag / Minimize / Taskbar tests and don’t log in from that page.

Want a hands-on way to teach this?

revel8 can simulate cookie-banner-to-SSO BITB phish flows that mirror your stack and coach users in real time - without harming systems.

Reach out to us to trigger your personal demo simulation!

‍