The phishing page was the real page

You get a message about a shared document, a flagged sign-in, an invoice. You click. A Microsoft login page opens, and it is the real one: the right fonts, the right logo, the little animation when you tab between fields, the genuine multi-factor prompt that buzzes your phone. You approve it. You are in. Nothing felt wrong, because almost nothing was wrong. The page you typed into was Microsoft's login page. You were not the one talking to it.

In late June, Netcraft's Harry Everett documented a phishing kit called Bluekit making this jump, and BleepingComputer covered it the same week. Bluekit sells as a service: a hosted phishing kit with templates for Outlook, Gmail, iCloud, GitHub, and a crypto wallet or two, plus a built-in assistant for writing the lure email. Its new trick carries a name that has circled since a researcher known as mr.d0x described it in 2022: browser-in-the-middle.

The real page, streamed to you.

Old-school phishing builds a counterfeit. Someone clones the login page, hosts it on a look-alike domain, and hopes you skip the address bar. The defense grew up around that: spot the fake, catch the typo in the URL.

A reverse-proxy kit like Evilginx came next. It does not clone the page. It sits in the middle of the connection, an "adversary in the middle," and passes your traffic through to the real site, scraping the session cookie as it flows past. (That cookie is the small token a site hands your browser after login, so it stops asking for your password on every click.) Stealing it defeats most multi-factor login, because the attacker takes the proof of a completed login rather than the password.

Browser-in-the-middle is stranger, and in a way simpler. The attacker runs an actual browser on their own server and points it at the genuine login page. An open-source library called rrweb, built for replaying user sessions, serializes that live page and streams it to you over a WebSocket, a persistent two-way channel between your browser and theirs. Your browser renders the real page's structure as if you had loaded it yourself. You are not watching a screenshot or a video. You are remote-controlling a browser that sits in the genuine shop, and your keystrokes, your mouse, and your multi-factor approval relay back to it. When the login completes, it completes in their browser, and their server mints the session token. They owned your session from the first second.

Why go to the trouble? Because it convinces in a way a clone never does. There is no fake page to get wrong. And because the attacker uses one consistent browser to talk to the real site, the login does not trip the fingerprint-mismatch alarms (the small inconsistencies between your device and a proxy's) that sometimes give a reverse-proxy kit away. Netcraft counted roughly seventy fresh Bluekit hostnames in a single week. That is the output of a product.

What does not stop it.

Start with the bad news, because there is a lot of it.

Multi-factor authentication, in its common forms, does not stop this. A one-time code and a push approval prove the same thing, that a login is happening right now, and the attack needs that login to happen, because the attacker is the one signing in. You do the proving. They keep the session.

Newer session-hardening helps less than you would hope. Netcraft notes that Device Bound Session Credentials, a scheme that ties a session cookie to the device it was issued on, "cannot protect against Browser-in-the-Middle, while they do provide some protection against Adversary-in-the-Middle." The session starts life on the attacker's device, so binding it to that device protects the attacker, not you. Anything bolted on after login arrives too late, because by then the attacker holds the session by right.

Isolation does not stop it either, and that is worth saying plainly. A browser that runs every tab in a throwaway virtual machine, the way ours does, contains what a page can do to your computer. Browser-in-the-middle does nothing to your computer. It borrows your hands for one login and keeps the result on a server you will never see. You can throw your own session away the moment you close the tab. The copy that matters was never on your side to throw away. Disposability defends against a long list of attacks, and browser-in-the-middle is not on the list.

What does stop it.

No better fake-page detector helps here, because there is no fake page. The fix is a credential the attacker cannot copy down.

Passwords and one-time codes share one fatal property: they are strings. You type a string into a streamed page, the wire carries it, and the browser on the other end replays it. That is the entire business model.

A passkey is a private key that lives on your device and never leaves it. Signing in means your Mac signs a one-time challenge after you approve it with Touch ID, and the signature it hands back is bound to the exact website you made the passkey for. Two consequences follow, and both break browser-in-the-middle.

First, there is nothing to type, so there is nothing to relay. The secret never appears in the page, never crosses the WebSocket, and never sits in a form field for rrweb to stream back. The attacker's browser can ask all it likes; the signing happens on a chip in your Mac that the attacker's server cannot reach.

Second, the passkey for your real bank is registered to your real bank's domain. When the attacker's host serves the page in front of you, your Mac looks for a passkey that does not exist there and offers nothing. The sign-in that should take one tap does not happen. That silence, the autofill that never fires and the passkey that is not on the list, is the warning the fake address bar used to give you and no longer can.

Two ways to lend your Mac's credentials.

The browser's design matters here, because a passkey only defends you if it reaches the place where you log in.

Bromure runs each browsing session inside a disposable Linux virtual machine on your Mac, a separate little computer that it wipes when you close the window. That contains hostile pages well, but it raises an obvious question: if the browser lives in a throwaway machine, where do your saved logins come from? Bromure makes you choose, per profile, and splits the choice into two switches on purpose.

Splitting them is the point. Sharing your entire Keychain into a session is the convenient default; sharing only passkeys is the option immune to the attack in this article. Passkey-only gets its own switch, so the phishing-resistant choice costs you one toggle instead of a security project. You can run a profile with exactly one way to authenticate, the way that cannot be streamed off your screen.

What this does not solve.

A toggle is not a force field, and the limits matter.

The big one bears repeating. If you log in with a password through a browser-in-the-middle page, even with a one-time code or a push behind it, the attacker gets a working session, and nothing about a disposable VM or a clever browser claws it back. Passkey-only sharing protects the logins where you use a passkey, and no others. Plenty of sites still do not offer them, and for those the old advice is the only advice: do not follow login links from messages, open the site yourself.

Detection helps, and Bromure uses it: filtered DNS that blocks known malicious domains, and an AI phishing check that scores a page's URL and form structure before you act. Both narrow the odds. Neither is a guarantee, and browser-in-the-middle is designed to make detection harder. Seventy fresh hostnames a week outruns most blocklists, and a content scanner finds no fake page to flag. Detection catches the careless attacker. Phishing-resistant credentials catch the careful one.

And the most ordinary limit of all: a person can be talked into a lot. If a convincing message walks you to a passkey-less site and you type a password you reused somewhere else, no browser setting was ever in that loop. Passkey-only sharing does not make you invincible. For the logins that matter most, your mail, your code host, your identity provider, it removes the string the attacker came for and leaves a key they cannot reach.

The fake address bar is retiring.

The advice we repeated for two decades (check the URL, look for the padlock, doubt the page) assumed the attacker had to forge something. Browser-in-the-middle forges nothing. It hands you the genuine article and stands behind it with the bag open.

The honest takeaway: a security-first browser does not make you immune to this, and we would rather say so than pretend. The answer moved from your eyes to your credentials. Against a page you cannot tell from the real one, the durable defense is to sign in with something you cannot copy down: a passkey, signed on your Mac, bound to the real domain, never on offer to the attacker's. Bromure's part is small and specific. It makes that the easy default by letting a profile share passkeys and nothing else. Install it, turn on passkeys-only for the accounts you cannot afford to lose, and let the next perfect-looking login page ask you for a secret you no longer have to give it.