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://…