Summary

  • APNIC’s ADBHoney recorded 1,841 source IPs connecting during 21–27 September 2026. The most common script, run by 89 IPs, checked for two existing mining apps before the bot uploaded and launched its own binaries in sessions APNIC followed.
  • A separate dropper pre-granted its app every permission, faked a boot event, and removed seven competing bot apps by name. The record shows a contest over application control on an exposed Android debugging interface.

The first command was a roll call. Before installing anything, a script asked whether another miner already occupied the Android device.

That sequence appears in Adli Wahid’s account of APNIC’s rebuilt honeynet. Wahid is APNIC’s Senior Internet Security Specialist; his report describes ADBHoney, a decoy that imitates an Android phone or TV box and exposes Android Debug Bridge on port 5555. During the 21–27 September observation week, 1,841 source IPs connected. The table records 23,000 ADBHoney events.

The most common script, executed by 89 IPs, ran three checks: pm path com.ufo.miner, ps | grep com.ufo.miner, and ps | grep trinity. The first asks Android where an app is installed; the process searches look for running miners. In the sessions APNIC followed, the bot then uploaded and launched its own mining binaries.

That order matters. The command sequence spends its opening move learning what is already on the device. The later action, in followed sessions, is to place another miner. APNIC’s account describes a second, separate dropper with a more aggressive installation routine: it grants its app every permission, simulates a device boot so the app starts immediately, and removes seven competing bot applications by name. APNIC does not publish those app names in this report.

These are two observations, not one continuous script. Together they show why a debugging endpoint can become contested territory. A miner already on the device is another process drawing on the same Android box; a dropper that removes competitors clears the way for its own app. The prize is a device that can run code and reach the network, not merely an entry in a scan log.

ADB is a developer’s control interface. Android’s own documentation describes a TCP/IP debugging setup that explicitly puts the device in listening mode on port 5555. APNIC’s decoy shows what happens when a comparable interface answers from the public Internet: a remote process can inspect packages and processes, issue commands, transfer files, and try to alter the app state. ADBHoney presents a controlled imitation, so its log records the attempts against the decoy rather than successful changes to real phones or TV boxes.

APNIC reports 109 issued commands and 28 file transfers, but does not define whether those figures count unique IPs, sessions, commands, or files. That missing unit controls whether readers can compare them with the 1,841 connections. The published evidence supports the command sequence and the followed uploads; it does not supply a real-device count or an attributed operator.

The practical signal is not simply “port 5555 was contacted.” It is the order of actions after contact: package lookup, process inspection, file transfer, app installation, permission grant, boot trigger, and removal of rival apps. That sequence gives defenders a sharper question than a raw connection total: who can reach the debug interface, and what did the device let them do?

Sources