Fin octobre 2026, Google a déclaré avoir perturbé l’infrastructure de commande du botnet Android x.cpe, qui comptait plus de 1,3 million d’appareils, surtout des boîtiers TV. Le Google Threat Intelligence Group décrit une action juridique visant cette infrastructure. La porte dérobée x.cpe était intégrée au firmware des appareils et pouvait s’y réinstaller après un redémarrage.
Une opération contre l’infrastructure de commande
Google estime avec un haut degré de confiance que Videostrong Technology Co. a développé, déployé et exploité la porte dérobée et le botnet à des fins financières. Google a également interdit à Videostrong et à ses futures filiales ou sociétés affiliées de fabriquer ou vendre des appareils Android certifiés, ou de fournir des logiciels aux fournisseurs certifiés. L’entreprise a aussi annoncé des changements aux contrôles d’intégrité du firmware et à ses processus d’examen.
Plus d’un million d’appareils, principalement des boîtiers TV
Google a évalué le réseau à plus de 1,3 million d’appareils Android. Dans un décompte distinct, TrendAI a recensé 1 472 554 appareils sur 206 modèles, pendant la période allant du 3 juin au 1er octobre. Les deux chiffres ont des périmètres rapportés différents.
La majorité des appareils étaient des boîtiers Android TV. Les appareils de télésanté, les machines de karaoké et les panneaux d’affichage numérique figuraient également parmi les catégories concernées.
Comment la porte dérobée communiquait
Le composant, également appelé com.oemservice dans certaines versions, se trouvait dans le firmware et fonctionnait avec des privilèges système. Il pouvait notamment installer des applications sans intervention de l’utilisateur, exécuter des commandes, capturer des écrans et collecter des informations sur les comptes et les appareils, ainsi que des journaux système. Les usages rapportés incluaient aussi le trafic de proxy résidentiel, la fraude publicitaire et le chargement d’autres logiciels malveillants.
Une analyse technique de NetmanageIT décrit une première requête de configuration HTTP transportant un objet JSON chiffré par AES, un standard de chiffrement, avec des données de télémétrie. Elle était suivie d’une connexion MQTT persistante, utilisée pour les échanges de commande. Dans les interactions décrites par NetmanageIT, l’installation, la suppression et la configuration de modules étaient les opérations les plus fréquentes.
Ce que la perturbation change pour les appareils
La coupure de l’infrastructure de commande ne réécrit pas le firmware déjà installé. Comme x.cpe pouvait se réinstaller depuis la partition /oem/ après redémarrage, la simple désinstallation d’une application ne supprimait pas durablement le composant. TrendAI a cité l’intervention du fabricant, la protection de la plateforme ou le remplacement de l’appareil parmi les pistes de remédiation.
Synthient a diffusé une liste de 182 noms de modèles : une correspondance de modèle peut orienter l’identification, mais ne permet pas à elle seule de diagnostiquer un appareil précis. Synthient a aussi repéré x.cpe préinstallé sur un MECOOL KM9PRO Max acheté pour son analyse.
