Is a browser-in-the-browser attack the same as ghost phishing?

No. Both hide malicious intent inside a rendered page, but ghost phishing keeps its payload encrypted until it decrypts in the browser to evade scanners, while BitB fakes a popup window to imitate a real login prompt.

Can antivirus or a secure email gateway block BitB?

Not reliably. The page is standard HTML served from the attacker's site, so there is no malicious file to detect. Gateways can catch the lure email or the malicious link, but not the rendered fake window.

Do passkeys really stop it?

Yes, when they are the login method. Passkeys and FIDO2 keys are cryptographically tied to the legitimate domain, so they refuse to sign in on the attacker's origin even if the user is fully fooled by the visual.

Does checking for HTTPS help?

No. The padlock and https:// in the fake window are drawn by the attacker. Only the browser's own address bar — outside the fake popup — reflects the real connection.

What is a browser-in-the-browser attack?

A browser-in-the-browser (BitB) attack is a phishing technique that draws a fake browser popup window — complete with a forged address bar showing a legitimate URL — entirely inside a web page using HTML and CSS. It imitates the single sign-on prompts you see when you click "Sign in with Google" or "Sign in with Microsoft," so the victim types real credentials into a window that is just part of the attacker's page. Because the address bar is a picture, not a real one, the usual advice to "check the URL" does not help.

At a glance

Quick Takeaways

A BitB attack renders a counterfeit login popup inside the page; the address bar and padlock are fake HTML, not a real browser window.
It targets single sign-on (SSO) and OAuth flows, where users expect a small popup asking for Google, Microsoft, or Apple credentials.
The technique was popularized by a security researcher known as mr.d0x, who published a working proof of concept in 2022.
Checking the URL does not defend against it because the URL shown is drawn by the attacker.
Password managers, passkeys, and dragging the popup outside the window are reliable tells because they react to the real origin, not the fake one.
DMARC cannot see a BitB page — it stops the lure email from being spoofed from your domain, but the attack happens after the click.

How does a browser-in-the-browser attack work?

The attack recreates the look of an operating-system browser popup using ordinary web code. When a site offers SSO, clicking the button normally opens a genuine small window pointing at accounts.google.com or login.microsoftonline.com. A BitB page skips the real popup and instead draws a

styled to look exactly like that window — title bar, close button, and an address bar with a convincing URL and a padlock icon.

Inside that fake frame sits a real login form controlled by the attacker. The victim, seeing what appears to be a trusted Google or Microsoft prompt with the correct address in the bar, enters their username and password. Those values go straight to the attacker's server. Many kits also relay the credentials in real time to capture the multi-factor prompt and the resulting session, defeating one-time-code MFA.

The whole illusion depends on the victim reaching the attacker's page first — usually through a phishing email, a malicious ad, or a lookalike domain. The page itself is legitimate HTML from the attacker's server, so there is no malware to scan and nothing for a mail filter to catch once the link is clicked.

Why is a BitB attack so convincing?

Most phishing training tells people to hover over links and read the address bar. BitB defeats that habit directly. The address bar the victim inspects is part of the phishing page, so it can display https://accounts.google.com with a padlock while the actual page is on the attacker's domain.

Three details make it land:

Familiar context. SSO popups are routine, so a small window asking for Google or Microsoft credentials does not feel unusual.
Pixel-accurate chrome. The fake window copies the real browser's fonts, buttons, and shadow, and can even animate as if it were opening.
A trusted-looking URL. The forged address bar removes the one signal users are trained to check.

This is the same blind spot behind why so many phishing emails pass SPF and DKIM checks: the technical envelope can look clean while the human-facing content is entirely fake.

How do you spot a browser-in-the-browser attack?

The fake window betrays itself the moment you test it against something the attacker cannot fake:

Try to drag the popup outside the main window. A real browser popup is its own OS window and moves independently past the edge of the parent tab. A BitB window is trapped inside the page and cannot leave it.
Watch your password manager. A manager keyed to the real origin will not autofill on the attacker's domain. If your saved Google login does not offer to fill the "Google" prompt, the prompt is not Google.
Maximize or resize the browser. The fake window often clips, misaligns, or fails to reflow because it is a page element, not a true window.
Look for the real address bar. The genuine browser address bar — the one at the top of the actual window — still shows the attacker's domain. Only the inner, fake bar is spoofed.

How do you stop browser-in-the-browser attacks?

Because BitB happens after the click, defense combines identity controls that cannot be phished with the email controls that keep your domain out of the lure.

Deploy phishing-resistant MFA. FIDO2 security keys and passkeys are bound to the real web origin. A passkey registered for google.com simply will not authenticate against the attacker's domain, so a stolen password gets the attacker nothing. This is the single strongest control — see the MFA types worth deploying.
Train on the drag-and-autofill tests rather than "check the URL." Give users two physical actions that expose the fake window instead of a rule the attack defeats.
Enforce DMARC so attackers cannot send the initial lure from your own domain. Move from p=none to p=quarantine or p=reject once your legitimate senders are aligned; check where you stand with the DMARC checker.
Monitor for lookalike domains that host these pages, and scan suspicious links before clicking with a phishing link checker.
Harden the credential path overall — see how IT teams prevent credential theft for the broader program.

For MSPs and IT teams, Palisade automates the email-authentication layer — getting client domains to DMARC enforcement and keeping them there — so your own domains cannot be used to deliver the phishing email that starts a BitB attack. A free Email Security Score shows which client domains are still spoofable today.

Questions readers ask