How do attackers use Browser in the Middle (BiTM)?

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.

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.

Related resources from NHI Mgmt Group

• What challenges do browser extensions pose to enterprise security?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?