Attackers use Android Debug Bridge (ADB) to run commands, install apps, copy data and interact with an Android device over a debug connection. If debugging is left enabled or a device is paired to an untrusted host, ADB can be used for unauthorised access and persistence. Defenders should restrict debugging, control trusted hosts and watch for unexpected ADB connections.
How attackers turn ADB from a developer tool into a device-control path
ADB becomes abusive when a debug bridge is still reachable on a device that should no longer trust the host side. At that point, an attacker can issue shell commands, move files, install packages and use the connection as a durable foothold, especially if the device has been left in a debug-friendly state or paired to an untrusted computer.
The practical security issue is not ADB itself, but the trust it inherits from prior pairing and local device settings. On Android devices, debugging is often enabled for legitimate testing, so the security boundary depends on whether those settings are disabled, whether the host is authorised and whether the device still honours an old pairing relationship.
Attackers look for ADB because it can collapse several security layers at once: application isolation, user interaction and some device management assumptions. Once a host is trusted, the connection can be used to observe the file system, stage payloads or maintain access across sessions if the debug state is preserved. For mobile teams, this is why Mobile App Security Testing Guide is relevant to Android review work, because runtime testing has to include the device debug surface as well as the app itself.
What conditions make ADB abuse succeed
ADB abuse usually depends on one or more simple control failures rather than a sophisticated exploit chain. The most common enabling condition is debugging left on outside a test environment, followed by a device that still accepts commands from a host that should no longer be trusted. In practice, that means the attacker does not need to defeat the operating system first if the bridge is already open.
It also matters whether the device owner can see that a debug session exists. If ADB connections are unexpected, intermittent or invisible to the user, the bridge can be used for low-noise access and later persistence. The relevant defensive question is whether you can prove when debugging is enabled, which host is authorised and whether that relationship is still valid after device reuse, repair or handoff.
Because ADB is often treated as a development convenience, it is easy for organisations to miss it in standard hardening reviews. That is why CISA cyber threat advisories remain useful as a companion source for operational awareness, since attacker tradecraft often exploits exposed management paths before organisations notice them.
What defenders should verify on Android fleets
Start by confirming which devices can accept ADB at all, then verify whether that state is intentional. On managed fleets, the stronger position is to keep debugging disabled by default, allow it only for approved test workflows and treat any permanent debug posture as an exception that needs ownership. Device policy should also define how trusted hosts are enrolled, reviewed and removed.
Monitor for signs that a device has entered an unexpected debug relationship. That includes new host pairings, debug access appearing on devices that are not in a test pool and sudden command execution patterns that do not match normal administration. If the device is high value, consider it exposed the moment an untrusted host is paired, not only after obvious misuse is observed.
For detection and hunt planning, MITRE ATT&CK Enterprise Matrix helps map this behaviour to post-exploitation activity such as command execution, persistence and data collection, while OWASP Non-Human Identity Top 10 is useful when the same device-management habits extend into service tooling and long-lived access material.
Risk and Threat Considerations
ADB abuse matters because it can convert an otherwise local or physical access issue into reliable remote command execution on the device. Once the bridge is trusted, the attacker may not need a malware payload at all, only continued access to the debug channel and the ability to reuse that trust.
Failure mechanism: Debugging remains enabled, or an old trusted-host relationship is still accepted, so the device continues to expose a management path that should have been revoked.
Impact: The attacker can run commands, copy data, install or stage apps and preserve access across sessions, which increases the chance of data exposure, persistence and further device compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Authentication with Multi-Factor Authentication | ADB abuse hinges on controlling who can establish trusted access paths to devices. |
| Recommendation — Require strong authentication before any debug or device-management access is allowed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | ADB trust depends on the lifecycle and revocation of device-host credentials and pairing material. |
| AC-6 — Least Privilege | ADB sessions can grant broad device control, so privilege must be tightly bounded. | |
| Recommendation — Manage, rotate and revoke debug credentials and pairing tokens promptly. Limit debug access to the minimum commands, devices and hosts required. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | ADB abuse is an access-control failure on managed Android devices. |
| Recommendation — Restrict device access paths and remove unauthorized debug trust relationships. | ||
| OWASP ASVS | V6 — Authentication | The attack relies on weak or stale trust for a management connection. |
| Recommendation — Verify that privileged device connections cannot be established without current trust. | ||
Practitioner Guidance
What to verify: Confirm that production and user-held devices cannot accept ADB unless there is an approved, time-bounded reason. The important test is not whether ADB exists, but whether the current trust state is still justified.
Decision rule: If a device can still pair with a host that is outside your managed build or test workflow, treat that as an access-control issue first and an endpoint-hardening issue second. Revoke the trust relationship before assuming the device is clean.
Practitioner takeaway: ADB is dangerous when teams confuse a development convenience with a standing management entitlement, because the real security failure is usually unrevoked trust, not the command bridge itself.