HITL CDP Browser Bridge Exposure

How the attack works

An agent host or its browser-control bridge exposes Chrome's DevTools Protocol on a network address rather than restricting it to localhost. Before any real control session starts, a client sends an HTTP request to a known discovery path (like /json/version or /json/list) to get connection details, including a WebSocket URL used to attach and issue commands such as navigating pages or running JavaScript. The rule spots this discovery request landing on a non-loopback address, and looks for signs the surface is being used beyond a single check - such as multiple attached clients, multiple targets, sustained traffic, or a bridge reachable from the public internet. It cannot see the actual WebSocket command traffic, so it does not confirm that anyone actually took control - it only confirms the exposure and usage pattern.

Netzilo detection

Why it matters

An exposed CDP bridge can let anyone who reaches it read, navigate, or script an agent's browser session, potentially exposing credentials, cookies, or letting them redirect the agent's actions. Because the underlying control channel isn't directly observed here, an organization can't tell from this alone whether the exposure was actually exploited - only that the risky condition existed and was contacted.

What you can do

• →Bind CDP-based bridges (including human-in-the-loop browser review tools) to loopback (127.0.0.1) only, and use a separate authenticated proxy or tunnel for legitimate remote access.
• →Audit any browser automation or human-review tooling for network-exposed debugging ports, including container setups using host.docker.internal.
• →If remote access to a CDP bridge is required, restrict it with network-level allowlists or a VPN, and require authentication in front of the discovery endpoints.
• →Treat any finding of multiple concurrent clients or public reachability on a CDP bridge as a signal to manually check the browser session for unauthorized activity.

Known benign look-alikes

• Remote or containerised browser farms (browserless, Selenium Grid, chrome-in-docker, host.docker.internal) that are legitimately driven over a network interface. These match by design; the 30-minute per-endpoint cooldown keeps them to one finding per endpoint per window and the action is report, so no automation is interrupted.
• A genuine human-in-the-loop session where the operator's viewer and the agent are both attached to the same bridge - this satisfies the "concurrent bridge clients" corroborator and is exactly the state the rule is meant to surface for review.
• CI or provisioning jobs that poll /json/version on a remote container until the browser is ready, producing high request counts (sustained-traffic corroborator).
• An engineer running Chrome with --remote-debugging-address on a LAN address and attaching DevTools from another machine.
• Local-only Puppeteer/Playwright/Selenium automation is out of scope by construction (loopback endpoints carry no exposure), so the most common benign CDP pattern does not fire at all.

References

• https://chromedevtools.github.io/devtools-protocol/
• https://attack.mitre.org/techniques/T1185/
• https://attack.mitre.org/techniques/T1046/