Attackers use Browser in the Middle (BiTM) to sit between a user’s browser and the real service, relaying traffic while stealing sessions or altering content. It is commonly used to bypass multi-factor authentication by capturing live authentication state. Defenders should prefer phishing-resistant authentication, watch for impossible travel and session anomalies, and bind sessions to stronger device or token signals.
How BiTM works during a live session
Browser in the Middle works by inserting a proxy-like layer between the victim’s browser and the legitimate site, then forwarding requests and responses so the session still feels normal. The attacker is not trying to break the website’s cryptography directly; they are trying to inherit the authenticated browser state, then use that state before it expires or is invalidated.
That makes BiTM especially effective against flows that trust a successful login event too much. Once the browser has completed authentication, the attacker can often ride the same session cookies, tokens, or page content that the real service would accept from the user’s browser.
Why BiTM bypasses MFA so effectively
BiTM is dangerous because many MFA methods only protect the initial login step, not the ongoing session. If the attacker can capture or relay the live browser session after the user completes MFA, the second factor has already done its job for the real login and may not stop the attacker from reusing the authenticated state.
This is why phishing-resistant authentication matters. Stronger methods bind the login ceremony to a device, a key, or a cryptographic challenge that is harder to relay in real time. AiTM Phishing Guide is a useful reference when you need to distinguish classic credential theft from session-stealing reverse-proxy phishing.
What defenders should watch for and harden first
The key defensive problem is not just stolen credentials, it is stolen authenticated state. A BiTM campaign often leaves behind unusual session behaviour, impossible travel patterns, repeated reauthentication prompts, token reuse from new locations, or requests that do not match the user’s normal browser and device signals.
Hardening should focus on reducing replay value and narrowing the life of any stolen session. Session binding, tighter token lifetime controls, conditional access, and device-aware checks all make a relayed browser session less useful to an attacker. For deeper context on how session theft and adversary-in-the-middle kits fit into broader breach patterns, see The State of NHI & AI Agent Breach Report 2026.
Risk and Threat Considerations
BiTM is attractive because it turns the user’s own successful login into the attacker’s access path. The attacker can harvest live session material, alter page content in transit, and keep access until the session is revoked or expires, which means the compromise can persist even when the password is unchanged.
Failure mechanism: The attacker relays authentication in real time, captures the authenticated browser state, and then reuses that state before the service detects the mismatch.
Impact: The result can be account takeover, silent transaction tampering, lateral movement into connected services, and a delayed detection window because the login itself may appear legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | BiTM directly targets phishing-resistant authentication and session assurance. |
| Recommendation — Use phishing-resistant authenticators and binding signals that reduce relayable sessions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | BiTM abuses user authentication to obtain a live authenticated session. |
| AC-10 — Concurrent Session Control | BiTM often relies on session reuse and parallel access from a different endpoint. | |
| Recommendation — Require stronger authentication that resists real-time relaying. Limit and monitor concurrent authenticated sessions to shrink replay opportunities. | ||
| OWASP ASVS | V7 — Session Management | BiTM is fundamentally a session hijack and relay problem. |
| Recommendation — Harden session handling so stolen browser state is harder to reuse. | ||
| MITRE ATT&CK | T1185 — Browser Session Hijacking | BiTM matches the adversary technique of intercepting browser sessions to gain access. |
| Recommendation — Map detections to browser-session hijacking and hunt for relayed interactive logins. | ||
| NIST CSF 2.0 | PR.AA-05 — Protective Authentication | BiTM is defeated by stronger authentication and session-binding controls. |
| Recommendation — Deploy phishing-resistant authentication and binding checks for interactive access. | ||
Practitioner Guidance
What to prioritise: Treat BiTM as a session integrity problem, not only a login problem. Prioritise phishing-resistant authentication, session anomaly detection, and controls that tie access to device or token signals that are difficult to relay.
What to verify: Confirm that your authentication and access stack can detect abnormal session reuse, revoke sessions quickly, and distinguish a normal browser journey from a relayed one. If your control only protects the password challenge, it is not enough against BiTM.
Practitioner takeaway: The practical goal is to make stolen authenticated state short-lived, device-bound, and observable, because BiTM succeeds when a valid session is easier to replay than to protect.