ADB Agent Bridge Remote Android Device Control
This rule watches for an AI agent using the adb-agent-bridge tool to take over Android phones or emulators over a network connection instead of a physical USB cable. Network-based ADB control is much easier for an attacker or an unsupervised agent to reach at scale, and it can be combined with commands that change device state or pull data off the device.
How the attack works
An AI agent (or a script acting on its behalf) installs or runs adb-agent-bridge, a package that lets an agent drive an Android device semantically through uiautomator instead of raw taps and swipes. The detection triggers when this is paired with a network device target (an IP:port instead of a USB serial), when the package is fetched from a non-default package index, or when a raw adb command line targets a network device and also issues a state-changing or data-collecting shell action, such as reading data or altering settings. Bare installs or unarmed launches of the package do not trigger anything, only the combination of the package plus a network target or an actual UI/impact action does.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7f3c1d84-2b6a-4e59-9c0d-5a41b8e7c6f2
- Severity
- Medium
Why it matters
An agent with this capability can remotely operate Android devices it has network access to, potentially exfiltrating data, changing device settings, or performing actions on behalf of an attacker without physical access to the device.
What you can do
- →Restrict which hosts and agents are allowed to run adb against network-attached devices; keep ADB TCP debugging disabled unless explicitly required.
- →Review process lineage for adb-agent-bridge or adb connect activity: was it launched by a human operator, a CI job, or an unattended agent process.
- →Maintain an allowlist of approved device-farm or lab IP ranges, and flag any network ADB target outside that range.
- →Restrict package installation to trusted indexes and alert on adb-agent-bridge or similar tools being installed from unapproved sources.
Known benign look-alikes
- Mobile QA or device-farm engineering - 'adb connect <ip>:5555' followed by 'input tap/swipe/text' against a networked emulator or a STF/Appium device farm is exactly this pattern. Triage on process lineage - was the command issued by a human shell or by an agent - and on whether the device target is an approved lab address.
- CI pipelines that boot an emulator listening on TCP and drive it through uiautomator/uiautomator2 for UI regression tests.
- A developer legitimately evaluating adb-agent-bridge against their own handset after enabling wireless debugging - the package token plus '--serial <ip>:<port>' will match branch one.
- Internal mirror or air-gapped installs - 'pip install adb-agent-bridge --index-url https://<internal-mirror>/simple' matches the supply-chain branch by design, because the rule cannot and must not distinguish a corporate mirror from a typosquat index without an allowlist.
- Screenshot or screen-recording capture during manual debugging of a wirelessly attached device.
- Security research and red-team tooling exercising ADB on purpose.