Attackers are no longer trying to steal your password. They’re handing you a keyboard — one that belongs to them. BitM attack frameworks are gaining traction against enterprise SSO, and your MFA offers less protection than you think.

There is a category of phishing attack that does not require you to enter your credentials on a fake website. It does not need to intercept your one-time code mid-flight or brute-force your password after the fact. It works because you do everything correctly — you log in to the real website, you approve the real MFA prompt, and you access the real application. The only problem is that the browser you just used belongs to an attacker.

This is Browser-in-the-Middle (BitM). It is not new, but it has matured significantly. What was once a niche research technique has become an available attack vector with off-the-shelf tooling, active criminal campaigns, and a track record of enterprise breaches. The organizations most exposed are those that have deployed SMS or push-based MFA and believe that makes them safe. It does not.

How BitM works

To understand why BitM is effective, it helps to compare it to the phishing model most security teams are still defending against.

Classic phishing replicates a login page and harvests the credentials a user types. The attacker gets a username and password, but still faces the MFA barrier. Adversary-in-the-Middle (AiTM) improved on this by acting as a reverse proxy — the attacker’s server sits between the victim and the real website, relaying traffic in both directions, capturing the session cookie after the user successfully authenticates. This bypasses SMS and TOTP-based MFA because the session token is stolen after authentication completes.

BitM takes a different approach. Rather than proxying HTTP traffic, it gives the victim direct, live access to a browser that the attacker controls remotely — typically using noVNC, a browser-based implementation of the VNC protocol that allows remote desktop control through nothing more than a web link.

The victim clicks a phishing link and is presented with what appears to be a fully functional login page — because it is one. They are remotely controlling the attacker’s browser via their own browser window. The attacker’s server is running a Chromium instance in kiosk mode, displaying only the target application. The victim types their credentials, approves the MFA prompt, and lands on the authenticated dashboard. At that point, the attacker controls a browser with a live, fully authenticated session — credentials captured, MFA tokens intercepted, session cookie in hand.

The attack is particularly difficult to detect from the victim’s perspective because nothing goes wrong from their side. They log in successfully. They reach their inbox or dashboard. There is no error message, no password rejection, no indication that anything unusual occurred.

The SSO problem

BitM becomes significantly more dangerous in enterprise environments that use Single Sign-On. SSO is architecturally sound — centralizing authentication reduces password sprawl and enables consistent policy enforcement. But it also means a single captured session can be the skeleton key to an organization’s entire SaaS stack.

Active campaigns demonstrate the operational reality of this. Research from Datadog Security Labs tracked a campaign active since at least August 2025 targeting organizations using Microsoft 365 and Okta for SSO. The campaign used HR-themed lures — benefits reviews, compensation notifications, ADP-spoofing emails — to deliver phishing links behind URL shorteners to domains like employee-hr-portal[.]com and corporate-hr-portal[.]com.

The attack chain was architected to handle the M365-to-Okta federation flow automatically. First-stage phishing pages closely mirrored Microsoft 365 login portals. For organizations federated with Okta, the infrastructure dynamically detected the victim’s identity provider and forwarded them to a second-stage Okta phishing page, capturing SSO credentials and the established session cookie at both layers.

While this campaign is primarily an AiTM example rather than a pure noVNC BitM case, it illustrates the same defensive failure: attackers are targeting the authenticated session, not just the password. The infrastructure complexity shows the operational maturity involved — federation detection, session capture, and access gating handled automatically.

The same campaign injected JavaScript into the proxied login pages to exfiltrate session cookies in real time — every second, new cookies were posted to a /log_cookie endpoint. It had been actively maintained, with code improvements detected as recently as December 2025, indicating a well-resourced actor with deep familiarity with both Microsoft and Okta authentication flows.

Why MFA doesn’t stop it

The natural question is why MFA — which most enterprise security conversations treat as a near-complete answer to credential phishing — fails here. The answer is a distinction that rarely gets communicated clearly: MFA protects the authentication event. It does not protect the session that follows.

When a victim completes MFA in a BitM scenario, they do so successfully — against the real service, through the attacker’s browser. The authentication event is legitimate. The MFA challenge is satisfied. The session token minted by the identity provider is valid. The attacker, who controls the browser in which that session token now lives, simply continues using it.

The MFA methods most widely deployed in enterprise environments — SMS codes, TOTP authenticator apps, push notification approvals — all share the same architectural weakness when combined with session-based access: they produce a time-limited secret that can be observed and replayed if the attacker is positioned between the user and the service. BitM places the attacker exactly there.

MFA method comparison

Fullscreen BitM and the evolving threat surface

The BitM technique is not static. Researchers at SquareX have documented a more sophisticated variant that exploits the browser Fullscreen API to cover the parent window’s address bar entirely — the one visual indicator a cautious user might notice. In a fullscreen BitM attack, the attacker’s noVNC window expands to fill the entire screen, and the victim has no visible mechanism to check whether the URL they are on belongs to the correct domain. Awareness training that tells users to “check the URL bar” provides no protection against this variant.

At the infrastructure level, campaigns are increasingly using legitimate cloud services — Cloudflare Workers, Google infrastructure, shared CDN endpoints — to host phishing pages. This makes domain-reputation-based blocking less reliable and can defeat DNS-layer filtering entirely, since the pages are served from addresses that are also used by legitimate services.

What actually defends against this

The honest answer is that the only authentication method that is architecturally resistant to BitM is one based on public-key cryptography with domain binding: FIDO2, passkeys, or certificate-based authentication. When a FIDO2 credential performs its cryptographic handshake, it includes the origin of the page that triggered the authentication. A BitM proxy, regardless of how convincing the visual presentation is, cannot produce the correct cryptographic proof that the authentication is occurring at the legitimate service. The handshake fails.

Deploying phishing-resistant MFA is the right direction. But two architectural problems remain in most enterprise rollouts that security teams need to address explicitly.

The first is fallback paths. Most organizations that deploy passkeys or security keys maintain legacy fallback methods — SMS, email OTP, or password reset flows — for edge cases. These fallbacks are the weakest link. An attacker can manipulate the authentication flow to force the system to offer a less secure option, and the organization’s phishing resistance collapses entirely. Every legacy authentication method that remains active is a downgrade path.

The second is session management. FIDO2 protects the authentication event, not the session that follows. If session tokens can be stolen after authentication and replayed from a different IP or device without triggering re-authentication, phishing-resistant MFA provides incomplete protection. Continuous session validation — including device binding, token lifetime limits, and anomaly detection — is where residual exposure lives.

The broader picture

BitM is a specific technique, but it sits inside a broader shift in how credential attacks work in 2026. The attack surface has moved from the password to the session. Phishing toolkits — Evilginx, Modlishka, Muraena on the reverse-proxy side; noVNC-based frameworks on the BitM side — are openly available and actively maintained. Phishing-as-a-Service platforms have lowered the bar for deployment significantly, and campaigns are being run by actors ranging from well-resourced state-aligned groups to criminal operators using commodity kits.

The implication for enterprise defenders is that MFA deployment is no longer a sufficient endpoint for the authentication security conversation. The question is not whether MFA is enabled, but which MFA methods are deployed, whether fallback paths exist, and whether session management is rigorous enough that a stolen cookie has a limited operational window.

Organizations that have not yet moved privileged and high-value accounts to FIDO2 are operating with a known gap that active campaigns are specifically designed to exploit. The migration is not trivial, particularly at scale, but the threat posture makes the timeline urgent. As one set of researchers observed earlier this year, a privileged account protected by SMS-based MFA is not the same control posture it was even three years ago. The attackers understand that. The question is whether defenders do too.

References

1. Mandiant / Google Cloud Threat Intelligence BitM Up! Session Stealing in Seconds Using the Browser-in-the-Middle Technique cloud.google.com ↗
2. Datadog Security Labs Investigating an Adversary-in-the-Middle Phishing Campaign Targeting Microsoft 365 and Okta Users securitylabs.datadoghq.com ↗
3. Okta Threat Intelligence Phishing Campaigns Use ‘Employee Benefits’ Lure to Intercept Microsoft and Okta Logins (O-UNC-037) okta.com ↗
4. SquareX Research Fullscreen BitM Attack: Exploiting Browser Fullscreen APIs to Steal Credentials securityboulevard.com ↗
5. NCSC UK Comparing the Security Properties of Traditional User Credentials and FIDO2 Credentials ncsc.gov.uk ↗