What this bundle covers
Browser-in-the-Middle (BitM) is not AiTM. AiTM proxies a cloned login page through a reverse proxy and lifts the credentials and session cookie as they flow through. BitM does something different: the attacker stands up a real browser inside a container, points it at the genuine login page, and streams that browser to the victim over noVNC. The victim sees and interacts with what looks exactly like the real Google sign-in. Because it is the real Google sign-in. The HTML is genuine, the certificate is Google's, the login form is rendered by Google's own JavaScript. The only thing the attacker controls is the wrapper URL the victim landed on and the noVNC pixel stream between the victim's browser and the attacker's browser.
This breaks every defense built around "is this page actually Google?" because the page actually is Google. It breaks FIDO2 and passkeys because the FIDO2 prompt fires inside the attacker's browser, against Google's real origin, and the credential satisfies Google. The attacker is the one whose browser ends up authenticated. The victim never had a session.
To study this attack class in detail, we set up a BitM research environment in our lab and observed it end-to-end against a controlled test account (our own Gmail) on 2026-05-02. We then built BitM Shield — a Chrome extension that detects the attack in real time — and verified it blocks the BitM capture chain before any credentials are typed. Both the lab analysis and the defense came out of the same two-week research cycle.
The bundle has four parts:
- Threat model. What BitM is, why it bypasses your existing anti-phishing stack, and the three artifacts that get captured — with the OAuth refresh token as the one most IR playbooks miss.
- Detection. Network-level, browser-level, behavioral, and OAuth-side signals. Plus the Gmail batch-API anomaly and the 29-cookie inventory we documented from a live capture.
- Mitigations. BitM Shield as the headline — built, tested, free, ~30 KB. Plus the broader posture: network controls, IdP-side hardening, and OAuth-grant hygiene.
- Incident response. The four moves in order. Why password rotation alone leaves the attacker reading your mail for as long as the OAuth refresh token lives.
Who this is for
Gmail account holders — personal, business, and Workspace admin. The detection content assumes you have either Workspace audit logs or a SOC with proxy/EDR visibility. The mitigations work for individual users (install the extension, audit your OAuth grants) and for organizations (managed-browser policies, Workspace Conditional Access, mandatory grant audits). The IR runbook walks both paths.
Why we wrote this
We study how attackers actually operate, and that precision is what makes the defensive content useful. When we say password rotation does not kill the OAuth grant, it is because we tested the technique on our own account in a controlled lab and watched the attacker's container keep reading mail with the rotated password sitting in our hands.
This is the fourth bundle in the LexLab Security Research series. The Microsoft 365 AiTM Defense bundle covered classical reverse-proxy phishing. The LinkedIn AiTM Defense bundle covered the same primitive against a different identity provider. The M365 OAuth Consent Defense bundle covered consent-grant abuse. This one covers the technique that defeats the controls those bundles recommend — BitM stays one step ahead of FIDO2, of session-cookie binding, and of most of what defenders have rolled out in the last two years.
Status
Live. Threat model, detection bundle, mitigations (including BitM Shield), and IR runbook are published. BitM Shield extension source is on GitHub at github.com/lexlabtools/bitm-shield; Chrome Web Store listing is pending review.