Skip to content
← RegistryDossier · 5 steps · 4 edges

Open ADB on the network → device shell

An IoT / dev device left adbd listening on TCP/5555 — anyone on the LAN runs `adb connect` and gets a shell as the shell user, including pulling user data.

Filed by AD Knowledge Base
§ Kill-chainDrag · zoom · scroll

§ Context

Assumed environment: a network-connected Android device (Fire TV, dev tablet, Android Auto unit, kiosk) with adb-over-wifi enabled. Attacker is on the same network.

§ Steps

  1. 01
    adb shell + getprop / pm list packagesDiscovery
    T1087Account Discovery
  2. 02
    Recover tokens / DB / keychainCredential Access
    T1552Unsecured Credentials
  3. 03
    nmap for TCP/5555Discovery
    N-NMAP-INTERNALInternal Nmap Sweep
  4. 04
    adb backup -all → unpack with abeCollection
    MOB-BACKUP-EXTRACTADB Backup Extraction
  5. 05
    adb connect <device>Initial Access
    MOB-ADB-OPENADB Open on Network

§ References

§ Frequently asked

What is the "Open ADB on the network → device shell" attack path?
An IoT / dev device left adbd listening on TCP/5555 — anyone on the LAN runs `adb connect` and gets a shell as the shell user, including pulling user data. It chains 5 steps drawn from real-world offensive-security techniques.
What starting position does this attack require?
The first step is adb shell + getprop / pm list packages (T1087) — a discovery primitive. Assumed environment: a network-connected Android device (Fire TV, dev tablet, Android Auto unit, kiosk) with adb-over-wifi enabled.
What is the final impact of this kill-chain?
The final step lands on adb connect <device> (MOB-ADB-OPEN), which falls under Initial Access. From here, an operator typically pivots into post-exploitation or maintains persistence.
How can defenders detect or prevent this attack?
Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers