DEF CON 34 · BiTM · Research use only

Browser in the Middle.
Trust, inverted.

EvilRBI weaponizes Remote Browser Isolation mechanics against the user they were meant to protect — a pixel-faithful IdP mirror, relayed clicks and keys, and MFA ceremonies completed in the middle browser. No Chrome 0-days. No CRX install.

Get the source Manifesto · write-up · slides DEF CON talk

AiTM vs BiTM

⇄

AiTM

Reverse proxy on the HTTP stream. Captures and injects session tokens as they flow. Auth UI still runs in the victim browser.

☠

BiTM — EvilRBI

Attacker’s real Chrome holds the session. Victim sees an MHTML/DOM mirror; every click, key, credential, and MFA ceremony is relayed upstream.

One path from lure to session

①

Internet lure

Public HTTPS face (TunnelTug or any ingress) serves the portal. One-click stream targets via portal routing.

②

Mirror viewport

chromedp captures MHTML from a managed upstream Chrome tab. Client hydrates into a Shadow DOM stage over WebSocket.

③

Input + MFA relay

Keys, clicks, WebAuthn, and Okta FastPass complete in the middle browser — not the victim’s.

④

Trust abuse

Built-in Google Endpoint Verification and chromewebdata footholds — intended surfaces, confused-deputy privilege.

Built for the whole chain

🖥

DOM mirror streaming

MHTML capture + client hydration for SPAs and stable auth flows — Google, Okta, Microsoft, AWS.

🔑

WebAuthn / passkey relay

Upstream ceremony proxy with victim-side signing at the RP origin; CDP virtual authenticator fallback.

⚡

Okta FastPass shim

Relays Verify challenges without binding the victim’s loopback FastPass port.

🦕

Trusted-loop foothold

chrome://dino / chromewebdata confused deputy — extension-bridge and apex SW privileges without CRX install.

🧩

Built-in EV RPC

Pairs with Google’s Endpoint Verification component already inside Chrome — magic RPC, host wildcard.

🛡

No 0-days

Stock Chrome. No memory corruption, sandbox escape, or unpatched CVE. Trust boundaries disregarded, not broken.

How it works

Visitors hit a public edge. EvilRBI streams a faithful mirror of the real IdP from a chromedp-managed middle browser. Input and MFA flow the other way. The victim never holds the authoritative session.

Victim Chrome Mirror + input terminal
→
EvilRBI proxy WS viewport · CDP · relay
→
Middle Chrome Real IdP session
# Research lab — never expose --dev to untrusted networks
go build -o proxy .
./proxy --dev --headed --no-tui
# Open http://127.0.0.1:8879/?url=https://example.com

Publications

Released when the DEF CON 34 talk starts (Fri Aug 7, 2026 10:30 PDT). Server-gated until then.

📜

Offensive Architecture

Manifesto: Dante’s Inferno of Deflected Responsibility, LGCO, Four Constants of Emergent Vulnerabilities. Security Considerations and Non-Goals under composition.

PDF HTML

📄

White paper

Reflections on Disregarding Trust write-up: BiTM architecture, multi-rail control, no 0-days thesis.

PDF HTML

🎞

Main Stage slides

DEF CON 34 deck for Reflections on Disregarding Trust (Main Stage 4).

PDF slides

DEF CON 34

Main Stage 4

Reflections on Disregarding Trust

Fri, Aug 7 · 10:30–11:30 PDT · What happens when RBI isolation, component extensions, and service-worker scope are weaponized against the user they were meant to protect.

Schedule entry Talk materials

Research & ethics

Authorized assessment only

EvilRBI is designed for controlled research, red-team exercises with explicit authorization, and defender education. Improper use creates significant legal and compliance risk. Never run open-relay modes on networks reachable by untrusted users. Treat captured cookies, snapshots, and debug endpoints as sensitive material.

MIT licensed · Repository: github.com/EvilRBI/phisheries

Start in two steps

1. Clone & build

Go 1.26+, Chrome/Chromium for the upstream session.

git clone https://github.com/EvilRBI/phisheries.git
cd phisheries
go build -o proxy .

2. Lab mode

Headed Chrome recommended for OAuth / CAPTCHA flows.

./proxy --dev --headed --no-tui
# → http://127.0.0.1:8879/?url=https://…