Résumé

  • Du 21 au 27 septembre 2026, ADBHoney, le leurre d’APNIC, a reçu 1 841 adresses IP sources. Le script le plus fréquent, lancé par 89 IP, cherchait deux outils de minage déjà présents avant que le bot ne charge et démarre ses propres binaires dans les sessions suivies par APNIC.
  • Un autre dropper accordait toutes les permissions à son application, simulait le démarrage de l’appareil et supprimait sept applications concurrentes par leur nom. Les traces décrivent une lutte pour le contrôle des applications sur une interface de débogage Android exposée.

La première commande faisait l’inventaire. Avant d’installer quoi que ce soit, le script cherchait à savoir si un autre mineur occupait déjà l’appareil Android.

Cette séquence figure dans le compte rendu d’Adli Wahid sur le honeynet reconstruit d’APNIC. Wahid est Senior Internet Security Specialist chez APNIC. Son article décrit ADBHoney, un leurre qui imite un téléphone ou un boîtier TV Android et expose Android Debug Bridge sur le port 5555. Pendant la semaine observée, du 21 au 27 septembre, 1 841 adresses IP sources se sont connectées. Le tableau attribue 23 000 événements à ADBHoney.

Le script le plus courant, exécuté par 89 IP, lançait trois vérifications : pm path com.ufo.miner, ps | grep com.ufo.miner et ps | grep trinity. La première recherche l’emplacement de l’application ; les deux autres cherchent des processus actifs. Dans les sessions qu’APNIC a suivies, le bot a ensuite téléversé et démarré ses propres binaires de minage.

L’ordre des opérations compte. Le script commence par repérer ce qui tourne déjà sur l’appareil. Dans les sessions suivies, l’étape suivante consiste à y placer un autre mineur. APNIC décrit aussi un second dropper, distinct, dont l’installation est plus brutale : il accorde toutes les permissions à son application, simule un démarrage pour la lancer immédiatement, puis supprime sept applications de botnet concurrentes en les identifiant par leur nom. L’article ne publie pas ces noms.

Il s’agit de deux observations distinctes, pas d’un seul script continu. Ensemble, elles montrent pourquoi une interface de débogage peut devenir un territoire disputé. Un mineur déjà installé est un processus qui utilise les ressources du même boîtier Android ; un dropper qui élimine des concurrents libère la place pour sa propre application. L’enjeu est un appareil capable d’exécuter du code et de joindre le réseau, pas seulement une ligne dans un journal de scans.

ADB est une interface de contrôle destinée aux développeurs. La documentation Android décrit une configuration TCP/IP qui place explicitement l’appareil en écoute sur le port 5555. Le leurre d’APNIC montre ce qui se passe lorsqu’une interface comparable répond sur Internet : un processus distant peut examiner les paquets et les processus, envoyer des commandes, transférer des fichiers et tenter de modifier l’état des applications. ADBHoney est une imitation contrôlée ; ses journaux enregistrent donc les tentatives contre le leurre, pas des changements réussis sur de vrais téléphones ou boîtiers TV.

APNIC rapporte 109 commandes et 28 transferts de fichiers sans préciser si ces nombres comptent des IP uniques, des sessions, des commandes ou des fichiers. Cette unité manquante détermine si ces chiffres peuvent être comparés aux 1 841 connexions. Les traces publiées documentent la séquence de commandes et les téléversements observés dans les sessions suivies ; elles ne donnent ni le nombre d’appareils réels concernés ni l’identité d’un opérateur.

Le signal utile ne se limite donc pas à « le port 5555 a reçu une connexion ». Il tient à l’ordre des actions : recherche d’un paquet, inspection des processus, transfert, installation, attribution de permissions, déclenchement au démarrage, puis suppression d’applications concurrentes. Cette séquence pose une question plus précise qu’un total de connexions : qui peut atteindre l’interface de débogage, et que laisse faire l’appareil ?

Sources