# Supply Chain awbrowse Remote Browser Client Acquisition

- **Severity:** Medium
- **Signature ID:** `7f3c2b9e-4d1a-4c86-9b52-0a6e8d3f21c7`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise)
- **OWASP:** LLM03 (Supply Chain)

## Summary

This rule flags when an AI agent or automated process installs the awbrowse Python package, which lets software remotely control a web browser hosted on someone else's infrastructure. It's a visibility check, not proof of an attack: the concern is that this gives an agent scraping and form-filling powers that bypass normal network monitoring on the local machine.

## How the attack works

An agent or automated process runs a pip/uv install command naming the awbrowse package, or fetches the package file or index page directly over HTTP. Once installed, awbrowse connects out to a hosted browser-rendering service and can navigate pages, scrape content, and interact with forms or login fields. Because the actual page-loading happens on the vendor's servers rather than the local device, none of that browsing activity shows up in local HTTP traffic inspection. The rule only checks for the install command or the package download - it does not track what happens after installation.

## Why it matters

An organization loses visibility into web browsing and data-scraping activity performed by its agents, since that traffic never touches the local network. This matters even for legitimate use, because it creates a blind spot for anyone monitoring egress traffic for sensitive data movement or credential use.

## What you can do

- Review any detected awbrowse installs to confirm they were approved for browser automation or testing, not introduced unexpectedly by an agent.
- Maintain an allowlist of approved packages for AI agents and flag installs outside that list for review.
- If awbrowse is approved for use, ensure its outbound connections to the hosted rendering service are logged or monitored at the vendor/service level, since host-level network inspection won't see that traffic.
- Check CI/CD pipelines and dependency lockfiles to distinguish routine build-time installs from a new, unplanned acquisition of this capability.

## Known benign look-alikes

- Developer or QA engineer intentionally installing awbrowse for approved browser automation or end-to-end testing work.
- CI/CD or container build step resolving a requirements.txt / pyproject.toml / uv.lock that already pins awbrowse - the install command line is identical to a first-time acquisition and cannot be distinguished from a single event.
- Internal PyPI mirror, proxy or artifact cache warming itself by fetching the awbrowse sdist/wheel on behalf of another consumer.
- A differently-named fork or extras distribution (awbrowse-core, awbrowse-cli, my-awbrowse) whose name shares the awbrowse token.
- Security researcher or reviewer downloading the distribution to inspect it before approval.

## References

- https://attack.mitre.org/techniques/T1195/002/
- https://attack.mitre.org/techniques/T1059/006/

---
Source: https://www.netzilo.com/threats/awbrowse-remote-browser-client