La botnet XCPE met les opérateurs à l’épreuve : CGNAT, NetFlow et proxys résidentiels

J. Actualclo

X (Twitter) Facebook Pinterest LinkedIn Email

Google et six partenaires, dont l’opérateur Lumen, ont démantelé XCPE, une botnet de plus de 1,3 million de décodeurs Android que, selon le Google Threat Intelligence Group (GTIG), son propre fabricant, Videostrong Technology Co., a transformée en un commerce de fraude publicitaire et de proxys résidentiels. Le rapport, publié le 2 novembre 2026, décrit un problème que les opérateurs connaissent bien : des équipements domestiques que le client ne peut pas nettoyer et dont le trafic sort sur internet avec l’IP du fournisseur d’accès lui-même.

Les points clés de la botnet XCPE pour les opérateurs en 30 secondes

Plus de 1,3 million de box TV Android embarquaient d’usine une porte dérobée attribuée à Videostrong.
L’accès était vendu à des tiers, qui installaient jusqu’à trois SDK de proxy résidentiel sur un même appareil.
L’Agence nationale de police du Japon, Lumen, HUMAN Security, Plume, Synthient et TrendAI ont participé à l’opération.
Google calcule que le retrait des domaines des affiliés coupe l’accès à 10 millions d’autres appareils.
Derrière un CGNAT, un seul appareil infecté peut compromettre la réputation d’une IP partagée.

Selon le GTIG, la porte dérobée était préchargée dans la partition système des décodeurs, avec des privilèges système, et se réinstallait toute seule après chaque redémarrage depuis la partition /oem/. Google soutient, avec un niveau de confiance élevé, que Videostrong, un OEM (Original Equipment Manufacturer, fabricant d’équipement d’origine) et ODM (Original Design Manufacturer) d’appareils Android, a développé et exploité la botnet de façon intentionnelle. L’analyse technique complète de la persistance, de l’architecture en trois phases et des indicateurs publiés se trouve dans l’article d’OpenSecurity sur la botnet XCPE.

La réponse de Google combine des voies juridiques et des leviers de plateforme. L’entreprise a engagé des actions pour retirer les domaines et les serveurs avec lesquels Videostrong contrôlait la botnet, ainsi que les domaines de C2 (command and control, commande et contrôle) de plus d’une douzaine de familles de logiciels malveillants chargées comme modules. Elle a en outre rompu ses relations avec le fabricant, lui a interdit de construire des appareils Android certifiés ou de fournir des logiciels à d’autres fabricants certifiés, et a annoncé des changements dans la vérification de l’intégrité du firmware des Android TV certifiés. Videostrong avait recouru à l’obfuscation pour exploiter une faille dans les tests de certification et charger le code après le premier démarrage.

Un nœud de sortie dans le salon du client

Le modèle économique explique pourquoi ce cas touche l’infrastructure au-delà de l’appareil lui-même. Selon le rapport, Videostrong vendait l’accès à des affiliés criminels et chargeait leurs modules sur les appareils : fraude publicitaire, inscription silencieuse à des réseaux de proxys résidentiels et installation de logiciels malveillants supplémentaires. Google a identifié une dizaine de SDK de proxy résidentiel et de partage de bande passante, et des cas où jusqu’à trois cohabitaient sur un même appareil. Le GTIG ajoute que l’inscription silencieuse, sans le consentement de l’utilisateur, reste la voie la plus courante pour transformer des appareils en nœuds de sortie.

Pour un fournisseur cloud, une plateforme de commerce électronique ou un service avec authentification, ce trafic n’arrive pas depuis des plages de centres de données faciles à filtrer, mais depuis des adresses d’opérateurs domestiques partagées avec des clients légitimes. Le rapport de Google parle de fraude publicitaire, d’exfiltration de données et d’acheminement de trafic malveillant via les appareils. C’est pourquoi les entreprises qui bloquent ou notent le trafic provenant de proxys résidentiels font face à un équilibre délicat : durcir le filtre sur une IP résidentielle peut exclure de vrais utilisateurs qui n’ont rien à voir avec l’abus. RevistaCloud avait déjà analysé cette pression dans son rapport sur la maison connectée comme munition de botnets et de proxys contre le cloud.

Le chiffre de 10 millions mérite une lecture précise. Il ne s’agit pas d’appareils XCPE, mais d’appareils compromis par les affiliés via d’autres canaux de distribution que cette porte dérobée. Google estime qu’en retirant les domaines de C2 de ces affiliés, ils perdent l’accès à au moins ce nombre supplémentaire d’appareils.

CGNAT, réputation des IP et détection dans le réseau

Alejandro D’Egidio, responsable des projets spéciaux de la CABASE (Chambre argentine d’internet), a exposé dans une publication sur LinkedIn la lecture du côté de l’opérateur. Selon D’Egidio, derrière un CGNAT (Carrier-Grade NAT, la traduction d’adresses à l’échelle de l’opérateur qui permet à de nombreux abonnés de partager une même IP publique), un seul appareil infecté peut faire finir cette adresse sur des listes de blocage et affecter des centaines de clients. Il rappelle aussi que l’utilisateur ne peut pas nettoyer ce qui vit dans le firmware, si bien que lui demander de régler le problème seul ne fonctionne pas.

Sa proposition pour les FAI (fournisseurs d’accès à internet, ISP) consiste à examiner les flux vers l’infrastructure de C2 rendue publique. Les exports de flux NetFlow ou IPFIX (IP Flow Information Export, le standard de l’IETF dérivé de NetFlow) permettent de croiser les connexions des abonnés avec les indicateurs publiés par Google. Parmi eux figurent le broker MQTT mqtt.szbboys[.]com sur les ports 3885 à 3887, les adresses 219[.]134[.]163[.]210 et 219[.]134[.]163[.]211 qui l’hébergeaient, et les serveurs 23[.]94[.]49[.]57 et 38[.]145[.]197[.]135, utilisés pour héberger des fichiers et comme C2. Les domaines, comme les sous-domaines de anyevonline[.]com, demandent de croiser aussi les journaux DNS, car un flux n’affiche que des adresses IP.

Cette liste a une date de péremption. Le rapport lui-même avertit que, lorsqu’une pièce est démantelée, les opérateurs de ces réseaux changent rapidement de chargeur ou de SDK de monétisation, et documente que depuis août 2026 la botnet remplaçait déjà son chargeur par de nouveaux installateurs. Les indicateurs servent à repérer dès maintenant les appareils touchés, mais ne remplacent pas une surveillance continue du trafic anormal vers l’extérieur.

Prévenir le client et partager le renseignement entre opérateurs

La seconde idée de D’Egidio est procédurale : notifier le client plutôt que de se contenter de bloquer, et partager le renseignement entre opérateurs. Un blocage sans préavis laisse l’abonné avec un service dégradé et sans explication, alors que la notification lui permet de débrancher l’appareil et de le remplacer, ce qui est la seule vraie issue quand le code est dans le firmware. Google, de son côté, encourage dans son rapport les plateformes mobiles, les FAI et les places de marché en ligne à continuer de partager le renseignement et à appliquer de bonnes pratiques pour identifier les portes dérobées et les réseaux de proxys illicites.

L’opération elle-même est un exemple de cette coopération. Aux côtés de Google ont participé l’Agence nationale de police du Japon, l’opérateur Lumen, HUMAN Security, Plume, Synthient et TrendAI. Google demande en outre aux distributeurs et aux détaillants d’exiger des audits de sécurité indépendants auprès des ODM et de retirer du catalogue les fabricants impliqués, et à l’industrie des proxys d’étayer toute affirmation d’origine éthique du trafic par des preuves de consentement transparentes et auditables.

Le cas ne sort pas de nulle part. Le 5 juin 2025, le FBI a mis en garde, via l’IC3 (Internet Crime Complaint Center), contre BADBOX 2.0, une botnet d’appareils IoT infectés avant l’achat ou pendant leur configuration et utilisée pour des services de proxy résidentiel. Le 17 juillet 2025, Google a assigné ses responsables à New York et chiffré le réseau à plus de 10 millions d’appareils non certifiés basés sur AOSP (Android Open Source Project). Le GTIG ne présente pas XCPE comme une partie de BADBOX, tout en relevant que deux des modules qu’elle chargeait, Moyu et Bird, avaient déjà été observés dans cette nébuleuse.

Questions fréquentes

Pourquoi XCPE concerne-t-elle les opérateurs de télécommunications ?

Parce que les décodeurs infectés fonctionnaient comme des proxys résidentiels et que leur trafic sortait avec les adresses IP des opérateurs domestiques. Derrière un CGNAT, cette IP est partagée par de nombreux clients.

Comment un FAI peut-il détecter les appareils infectés par XCPE ?

En croisant les journaux de flux NetFlow ou IPFIX et ceux du DNS avec l’infrastructure de commande et contrôle publiée par Google, comme le broker MQTT sur les ports 3885 à 3887 et ses adresses IP associées.

Qui est derrière la botnet XCPE ?

Google attribue avec un niveau de confiance élevé la porte dérobée et la botnet à Videostrong Technology Co., un fabricant d’appareils Android, et soutient qu’il a agi de façon intentionnelle pour en tirer un profit économique.

Suffit-il de bloquer l’IP concernée ?

Cela ne règle pas l’origine, car le logiciel malveillant vit dans le firmware et se réinstalle. Alejandro D’Egidio (CABASE) propose de prévenir le client pour qu’il retire l’appareil plutôt que de se limiter à bloquer.

Sources :