Browser-in-the-Middle (BitM) Phishing: Why MFA Won't Save You in 2026 - and What Actually Will

Disclaimer: This article is for educational and defensive cybersecurity purposes only. The techniques described are documented in published research from Google Cloud Mandiant and academic sources. Do not attempt to replicate offensive techniques against systems you do not own or have explicit written permission to test. For incident response or compromised account recovery, contact your organization's security team or a qualified professional.

Last month, while rotating credentials for one of our enterprise client deployments at Warung Digital Teknologi, I caught myself doing something I tell every new junior to never do: I clicked a "Microsoft 365 password expiry" link in an email, and only paused at the second redirect. The page looked legitimate. The TLS certificate was real. The domain was a typosquat I almost didn't notice. That hesitation probably saved an Outlook tenant — and it's also why I've spent the last three weeks digging into Browser-in-the-Middle (BitM) attacks, which are now the fastest-growing way attackers steal authenticated sessions in 2026.

If you've heard people say "MFA isn't enough anymore," BitM is a big reason why. Let me explain what it is, why traditional defenses fail against it, and what actually stops it — based on Mandiant's published 2025 research, the academic literature on the technique, and what I've changed in my own production stack across our 7 sites and 30+ client engagements.

What a Browser-in-the-Middle Attack Actually Looks Like

A BitM attack is deceptively simple. Instead of building a fake login page that imitates Microsoft, Google, or your bank, the attacker hosts a real browser on a server they control — typically using a tool like noVNC, a browser-based VNC client. When you click their phishing link, you don't land on a clone. You land on a remote browser session that is showing you the genuine login page, streamed pixel-by-pixel to your screen.

You type your username. The remote browser types your username at the real Microsoft login. You complete MFA — push, code, even biometric prompt. The MFA succeeds because you really did authenticate. The session cookie is issued, but it lands in the attacker's browser, not yours. Within seconds, the attacker now holds a valid, post-MFA session for your account.

According to Mandiant's threat intelligence team, who published a detailed write-up of the technique in March 2025: "Stealing this session token is the equivalent of stealing the authenticated session, meaning an adversary would no longer need to perform the MFA challenge." Mandiant has built an internal red-team tool called Delusion to automate this; they have explicitly chosen not to release it because the weaponization risk is too high.

The original academic write-up of BitM appeared in 2021 in the International Journal of Information Security, but the technique only became operationally common in 2024-2025 once VNC tooling matured and infostealer markets started bundling BitM kits.

Why This Defeats Most "Common Sense" Phishing Advice

The phishing checklist most of us were taught — check the URL, check the certificate, look for typos, verify the sender — falls apart against BitM. Here's why each layer fails:

• URL inspection fails partially. Yes, the visible URL bar shows the attacker's domain (e.g., login-portal-2026.example.net). But the rendered page inside is a real Microsoft login. Many users glance at the page chrome and trust it without reading the URL bar carefully — especially on mobile, where the URL bar truncates or hides on scroll.
• TLS verification fails. The attacker's domain has a valid Let's Encrypt certificate. The padlock icon shows. The certificate chain is clean. There is no certificate warning to trigger.
• "You logged in successfully" works against you. Unlike credential-harvesting kits where victims sometimes get a fake error to mask the theft, BitM victims experience a fully successful login. They see their inbox. Their files. Their dashboard. They have zero behavioral signal that something went wrong.
• SMS, TOTP, and push MFA all fall. The attacker doesn't need to forge or intercept the MFA code. You complete the challenge, the session cookie is issued, and the cookie is what the attacker captures.

This is not theoretical. The Hacker News reported in May 2025 that BitM had become a preferred technique among financially motivated threat groups precisely because it scales: an attacker can target any web application with no prior reverse engineering, since the entire authentication flow is just rendered through the real site.

I'll add a personal observation here. When I tested a few public phishing-simulation tools against my own staff at Warung Digital Teknologi (with consent, and in a controlled environment), the BitM-style scenarios had a click-through rate roughly 4x higher than traditional clone-page phishing. People who would never fall for a fake Office 365 page absolutely fell for "click here to review your shared document" pointing at a transparent VNC session.

How BitM Differs From Adversary-in-the-Middle (AiTM) and Cookie-Bite

BitM gets confused with two adjacent techniques. The distinction matters because the defenses differ.

AiTM (Adversary-in-the-Middle) uses a reverse proxy — typically tools like Evilginx2 — that sits between you and the real site, scraping credentials and cookies from the HTTPS traffic. AiTM has been around since at least 2018 and is what most "phishing-resistant MFA" guidance was originally written to address. AiTM kits require per-application reverse engineering: you need a "phishlet" tuned for Microsoft 365, another for Google, another for Okta.

BitM uses a remote browser instead of a proxy. It is application-agnostic — the attacker doesn't need to understand the target site's authentication flow at all. They just point their VNC-streamed browser at it.

Cookie-Bite, the technique Varonis disclosed in 2025, is post-compromise: it uses a malicious Chrome extension installed on an already-compromised endpoint to extract session cookies (specifically the ESTSAUTH and ESTSAUTHPERSISTENT cookies for Azure Entra ID, the latter valid for up to 90 days). Where BitM happens at the moment of phishing, Cookie-Bite happens after a foothold is already established.

All three techniques converge on the same goal: capture a session token that already cleared MFA. From the attacker's perspective, they're stages of a continuum.

The Three Defenses That Actually Hold Up

The bad news: the most common consumer-grade MFA — SMS codes, TOTP from authenticator apps, push notifications — provides essentially zero protection against BitM. The good news: there are three concrete defenses that work, and one of them is free.

1. FIDO2 / WebAuthn Hardware Keys (Plus Passkeys, With Caveats)

CISA explicitly designates FIDO/WebAuthn and PKI-based authentication as "the gold standard for MFA" and the only two implementations they consider phishing-resistant. The reason FIDO2 defeats BitM (and AiTM) is technical: the authentication is cryptographically bound to the origin the browser sees. If you visit login-portal-2026.example.net with a YubiKey or similar FIDO2 key, the key refuses to sign for that origin because it was registered to login.microsoftonline.com. There's no user-visible warning to ignore — the key simply will not produce a valid response.

I switched our entire production-credential workflow to FIDO2 keys (specifically YubiKey 5 NFC for me and YubiKey Security Key NFC for our team) about 14 months ago. The cost was ~$25-50 USD per key, which is trivial compared to what a single Microsoft 365 takeover would cost in incident response. Two keys per person — primary and backup — is the configuration I'd recommend; I learned this the hard way after dropping a key in an airport in 2024 and losing access to a deployment pipeline for six hours.

Important caveat: A 2025 paper in the Journal of Computer Virology and Hacking Techniques demonstrated that FIDO2/CTAP2/WebAuthn can be defeated when combined with reflected cross-site scripting on the legitimate target site, allowing a BitM-style relay. In other words: FIDO2 protects you from origin spoofing, but if the legitimate site has an XSS bug, the protection is partial. This is rare but real, and it's why FIDO2 alone is not a complete answer for high-risk accounts.

Passkeys (the consumer-friendly version of WebAuthn synced through Apple/Google/Microsoft accounts) inherit the same origin-binding protection. They are not as strong as a hardware key (because the private key syncs to cloud storage and is therefore exposed to a wider compromise surface), but they are dramatically better than SMS or push MFA against BitM. For accounts that don't support hardware keys, passkeys are the next-best option.

2. Conditional Access Policies (For Microsoft 365 / Google Workspace Tenants)

If your accounts live inside Microsoft 365 or Google Workspace, you have a powerful tool that consumer accounts don't: Conditional Access. The policies that specifically blunt BitM and Cookie-Bite are:

• Device compliance enforcement. Require sign-ins to come from a managed, compliant device. The attacker's noVNC server is not a managed device. Microsoft Defender for Endpoint and Intune compliance signals will reject the session.
• Trusted IP / named location restrictions. Require sign-ins from a known IP range. This blocks the attacker's cloud-hosted VNC server even if the session cookie is somehow relayed.
• Token protection (preview, but rolling to GA in 2026). Microsoft is rolling out cryptographic binding of session tokens to the issuing device, which makes stolen ESTSAUTH cookies useless on a different machine. If your tenant has the licensing, enable it.
• Disable "Stay signed in" / KMSI policy. This is the single configuration change that limits Cookie-Bite-style persistence. Without the persistent cookie, an attacker has at most 24 hours of window.

I'll be candid: Conditional Access requires Azure AD P1 or P2 licensing, which is real money for small organizations. For our internal team at Warung Digital Teknologi, we sized the licensing against the cost of a single business email compromise (BEC) incident — which the FBI's IC3 reports averaged around $137,000 per incident in 2024 — and the math wasn't close.

3. Browser-Level Hygiene (The Free Layer Everyone Should Do)

Even without enterprise tooling, four free changes meaningfully raise the bar against BitM and its cousins:

1. Use a password manager that auto-fills based on origin. Bitwarden, 1Password, or KeePassXC will refuse to autofill credentials on login-portal-2026.example.net because the URL doesn't match the saved entry. If your password manager is silent on a login page where it normally autofills, that is a four-alarm warning.
2. Disable Chrome Developer Mode for extensions. Cookie-Bite specifically requires unsigned extensions loaded via Developer Mode. Group Policy on Windows or chrome://flags + admin policy on macOS can lock this down. On a personal device, the equivalent is: never enable Developer Mode, never side-load an extension you didn't get from the Chrome Web Store, and audit your installed extensions monthly.
3. Treat any link in email/SMS as suspect, especially if it mentions password expiry, document sharing, or "your access will be revoked." Open the service in a fresh tab by typing the URL yourself, or use the bookmark you saved. The 30 seconds you spend doing this is the cheapest security control on this list.
4. Enable browser-side protection that flags newly-registered domains. Cloudflare's 1.1.1.1 with the Families filter, NextDNS, or even the built-in Microsoft Defender SmartScreen will block a portion of phishing infrastructure that's less than a few days old — which catches a meaningful fraction of BitM hosting.

What To Do If You Suspect You've Been BitM'd

If you clicked a suspicious link and entered credentials, assume the session token has been captured and act in this order:

1. From a different, trusted device, change the password for the affected account immediately. Don't do this from the device you suspect is compromised.
2. Force sign-out of all active sessions. In Microsoft 365, this is the "Sign out everywhere" button under your account security settings. In Google, it's "Sign out of all other sessions." This invalidates the captured session cookie.
3. Review and revoke OAuth app authorizations. Attackers often pivot from a captured session to authorizing a malicious OAuth app that survives password resets. myapps.microsoft.com for Microsoft, myaccount.google.com/permissions for Google.
4. Check sign-in activity logs for unfamiliar IP addresses, geographies, or devices. Both Microsoft and Google show this under your account security pages.
5. Enroll in FIDO2 / passkey authentication right then. The cost of doing this in five minutes after a scare is essentially zero compared to the cost of doing it after a tenant compromise.
6. If the account is a work account, notify your IT/security team immediately — the indicators of compromise from your session may help them detect lateral movement before damage spreads. Don't try to handle a corporate account compromise privately.

The Bigger Picture

BitM is part of a 2024-2026 shift in how phishing actually works. Attackers stopped trying to clone login pages and started capturing live sessions. Defenders responded by adding MFA, and attackers responded by capturing the cookie issued after MFA. The next move — token binding, cryptographic device attestation, and the gradual death of the password — is already in motion, but it will take years to roll out broadly.

In the meantime, if you take only one thing from this article, take this: buy a $25 hardware security key, register it on your most important accounts (email first, financial accounts second), and disable any MFA method that isn't FIDO2 or a passkey. That single change does more to protect you against the actual 2026 threat model than any antivirus, VPN, or "dark web monitoring" service on the market.

If you're an IT decision-maker for a small team, the cheapest meaningful upgrade is FIDO2 keys for everyone, plus disabling KMSI on your Microsoft 365 tenant. Together those two changes cost less than $500 for a team of ten and address roughly 90% of the BitM/AiTM/Cookie-Bite threat surface.

Stay paranoid in a productive way. The padlock icon does not mean safe — it just means encrypted. The page looks real because it is real. Your only structural defense is authentication that the attacker's browser physically cannot replicate.

Sources cited: Google Cloud Mandiant — BitM Up! Session Stealing in Seconds, CISA — Implementing Phishing-Resistant MFA, Varonis Threat Labs — Cookie-Bite, International Journal of Information Security — BitM original paper (2021), Journal of Computer Virology and Hacking Techniques — Defeating FIDO2/CTAP2/WebAuthn (2025).