Chrome Devtools Browser Agent Skill

chrome-devtools-browser

Headless browser.sh cannot solve a human login. This skill brings up a visible chromium on the

Kali desktop (:0) the operator can click and type into, with its DevTools port tunnelled back so the

chrome-devtools MCP drives and watches it. Two roles at once: the human authenticates; the agent

observes + acts. The VM holds the VPN/egress path, so it reaches both internet and in-scope targets.

1. Bring it up (one command)

bash scripts/browser-visible.sh <login-url> --profile bbtest-<eng>
# e.g. bash scripts/browser-visible.sh https://target.example/ib --profile bbtest-<eng>

It resolves the VM's seat session, unlocks/wakes :0, frees the CDP port, launches chromium **as the

seat user on :0** in a named tmux session (a dedicated per-engagement profile, so the operator's own

profile/cookies stay clean), then reuses scripts/browser.sh to forward CDP to http://127.0.0.1:9222.

It prints VISIBLE on :0 when a real on-screen window exists (not merely a listening port). If it prints

a no (:N) desktop session message, the VM has no desktop - fall back to scripts/browser.sh (headless).

2. Attach + hand off for login

• The chrome-devtools MCP attaches to http://127.0.0.1:9222. Confirm with list_pages; navigate_page

to the login URL if needed.

• Stay off the browser while the operator enters credentials. Take a take_screenshot so they can

confirm the page, then wait for their "logged in" before you drive again. The operator owns credential

entry and the phone approval; the agent never types a personal code / PIN.

3. Drive + observe (chrome-devtools MCP capability map)

| Need | MCP tool |

|------|----------|

| List/select tabs | list_pages (select the target tab; ignore the operator's other tabs) |

| Go to a page / back / reload | navigate_page |

| Rendered DOM (elements + uids) | take_snapshot |

| Visual PoC / confirm state | take_screenshot -> a web evidence image (hand to Skill(screenshot)/Skill(evidence)) |

| The real API calls the app makes | list_network_requests (add includePreservedRequests:true to span the login redirects); this is the authenticated API map a curl crawl never sees |

| One request's headers/body/cookies | get_network_request <reqid> |

| Console / JS errors | list_console_messages |

| Read client config / globals, confirm DOM-XSS | evaluate_script (e.g. __NEXT_DATA__, window.*, fire a payload in the real DOM) |

Once authenticated, the captured /… API calls feed the hunt skills: Skill(hunt-idor) / Skill(hunt-api)

(BOLA on id-keyed endpoints), Skill(hunt-xss) (DOM-XSS via evaluate_script), business-logic on the

authed flows. Load-bearing requests still go to Burp Repeater when reachable (Skill(hunt-burp)).

4. Field notes

• A 200 {"message":"Unable to login"} with NO Set-Cookie = the server rejected at an account/state

check and issued no session -> nothing to pivot (not a bug). A Set-Cookie/JWT issued *before* such a

check is a real authz-bypass lead - test the gated endpoints with that cookie.

• dbus/GPU errors in the tmux pane are non-fatal VM noise; judge success by VISIBLE on + list_pages.
• Data minimisation on the authed surface: prove IDOR/BOLA with your own account + stop at the first

adjacent-id differential; never pull another customer's real PII.

Safety

• The CDP port is unauthenticated = total control of the browser (read any tab, lift session cookies).

It stays loopback-only + ssh -L; never bind 0.0.0.0 / expose it to the LAN.

• Named tmux session only (cdpbrowser); never tmux kill-server (the VPN/other work may live in tmux).
• Dedicated --profile per engagement; the port-free step warns it drops any tabs on that port.

Teardown

bash scripts/browser.sh stop                                   # drop the CDP tunnel
bash /root/vm.sh 'tmux kill-session -t cdpbrowser'             # close the VM browser

Setup / recipe rationale + the dead-ends that shaped this: scripts/browser.sh, scripts/shot.py

(seat-session resolution), and the engagement failures.md note.