Proxynvader : enquête sur le botnet de boîtiers TV qui attaque les sites web depuis le salon de ses victimes

Publié le 22 octobre 2026 · mis à jour le 30 octobre 2026

Cet article est vivant : il sera complété à mesure que l'enquête avance. Le journal des modifications est en bas de page.

Depuis l'été 2026, les sites hébergés par LRob, l'hébergeur français qui a fondé Shieldlist, subissent une attaque qui ne ressemble à rien de ce que nous avions vu en quinze ans d'hébergement : des centaines de milliers d'adresses IP par jour, une requête chacune, venues de foyers ordinaires du monde entier. Derrière chaque adresse, un boîtier TV ou une clé de streaming infectée, dans le salon de quelqu'un qui n'en sait rien. Nous avons appelé ce réseau Proxynvader. Voici ce que nous savons, comment nous l'avons appris, et pourquoi, en France, personne ne veut l'entendre.

Résumé pour les pressés#

• Un réseau de proxys résidentiels tourne sur des appareils grand public infectés : boîtiers Android TV bon marché (X96, X98, Superbox, Vseebox, modules Wi-Fi FN-LINK et Earda), mais aussi, et de plus en plus, des Amazon Fire TV Stick sur lesquels on a installé un app store alternatif : onze des douze appareils retrouvés chez un même opérateur américain en sont. Un opérateur signale, sans pouvoir le confirmer, un électroménager connecté General Electric.
• Ces appareils servent de nœuds de sortie : un relais leur envoie des requêtes HTTP, ils vont chercher la page et la renvoient. Les sites visés voient arriver des millions d'adresses de particuliers.
• Nous avons mesuré près de 1,2 million d'adresses distinctes bloquées sur une seule boutique en ligne entre le 18 août et le 21 octobre 2026, 2,57 millions en 29 heures sur un site associatif, et une vague continue sur notre forge de code.
• Six opérateurs, dont cinq à l'étranger, ont retrouvé les appareils chez leurs abonnés grâce à nos signalements, qui portent l'heure UTC et le port source TCP. Les relais de contrôle qu'ils ont identifiés étaient, jusqu'au 30 octobre, hébergés à une exception près chez un même hébergeur ; la capture réseau d'un opérateur canadien a depuis montré une seconde infrastructure de relais, chez Alibaba, Tencent, BytePlus et Zenlayer, et la première preuve directe de ce à quoi servent les sorties en dehors de la collecte : tester des mots de passe de boîtes mail volés.
• La part française est massive : près de 52 000 adresses d'abonnés Free, Orange, SFR et Bouygues bloquées, dont 37 000 en 29 heures lors de la vague du calendrier. Près de 5 000 signalements envoyés à ces quatre opérateurs. Aucune réponse.
• C'est la continuation de BADBOX 2.0, que le FBI a signalé en 2025 puis à nouveau en mars 2026. Les signatures réseau pour détecter les appareils sont publiées plus bas, et détaillées pas à pas dans le guide Détecter Proxynvader sur votre réseau.

1. Ce que nous avons vu#

Tout commence sur une boutique en ligne de vélos, sous PrestaShop. Les pages de recherche à facettes (« vélos entre 2 000 et 3 000 euros, marque X, 36 par page ») se mettent à recevoir des requêtes par milliers. Chacune construit une page complète, jamais mise en cache, puisque chaque combinaison de filtres est nouvelle. Le serveur sature, pas par le débit, mais par le calcul.

Ce qui a rendu l'attaque si étrange, c'est sa forme :

• Une ou deux requêtes par adresse source, jamais plus. L'adresse ne revient pas dans la vague en cours. Bannir une adresse ne protège donc pas sur l'instant ; cela protège sur la durée, car le même parc sert d'une attaque à l'autre : un tiers des adresses de la vague sur notre forge étaient déjà bannies depuis la vague des boutiques. D'où des bans longs, un an, qui coupent les vagues suivantes avant qu'elles commencent.
• Un rythme constant, jour et nuit, qui monte et descend par paliers, comme un robinet qu'on règle.
• Des adresses de particuliers, au Brésil, aux États-Unis, en Argentine, en Colombie, au Mexique, puis partout : 211 pays, 17 400 réseaux d'origine.
• Un navigateur contrefait. Chaque requête prétend venir d'un Chrome récent, mais aucune ne charge d'image, de feuille de style ni de script, aucune ne porte de Referer, et l'empreinte TLS trahit trois programmes clients en Python et en Go, tous sur la même pile Linux. Les appareils relaient un trafic qui n'est pas le leur.

Pic mesuré : 390 000 adresses distinctes en 24 heures, le 19 août 2026. Un autre hébergeur, qui exploite des boutiques Magento, décrit la même campagne sur AbuseIPDB avec des chiffres qui vont de 2 à plus de 6 millions d'adresses sur l'année.

Puis les vagues se sont succédé sur d'autres cibles :

• 16 et 17 octobre : le calendrier d'un site associatif sous WordPress, 40 000 adresses par heure pendant 29 heures, 2,57 millions d'adresses bloquées, plus environ 600 serveurs loués chez un grand hébergeur français. L'attaque s'est arrêtée net, en treize minutes, au moment où nous avons commencé à signaler les adresses et à refuser les requêtes au lieu de les servir ; nous avons d'abord cru au signalement, la vague suivante nous a appris que c'est le refus qui compte, voir plus bas.
• Depuis le 12 octobre au moins : notre propre forge de code, git.lrob.net, dont les pages d'historique (commits, blame, diff) sont aspirées à raison de 23 000 à 57 000 requêtes par jour. Un tiers des adresses étaient déjà connues de la première vague : c'est le même parc.
• 23 et 24 octobre : les cartes de prévisions d'un site météo régional, chaque combinaison de carte, d'heure et de jour demandée une fois, 8 358 adresses en treize heures. Cette vague nous a appris deux choses. Le parc s'adapte en minutes : refusé par une barrière qui exigeait un Referer, il est revenu dans la minute avec un Referer imitant un clic et un autre User-Agent. Et ce qui l'arrête n'est pas le signalement : sept minutes après que nos pare-feu ont commencé à jeter ses connexions au lieu de répondre, le job s'est coupé, avant qu'aucun des douze opérateurs prévenus ait pu agir. Un refus HTTP lui dit « réessaie autrement » ; une connexion qui tombe lui dit « cible morte », et il passe à autre chose. Ce qu'il n'a jamais fait, sous aucun profil, c'est charger les scripts et les styles de la page : c'est là-dessus qu'on le reconnaît.

2. Pourquoi un hébergeur a fini par écrire son propre système de défense#

Quand l'attaque a commencé, les serveurs de LRob étaient protégés par un système de détection d'intrusion classique. Il a cédé, pas sur la détection, sur le volume. Le rythme était trop fort pour lui : il consommait plus de processeur que l'attaque elle-même, ses bans prenaient du retard, ce qui, sur une attaque répétée, laisse passer la vague suivante, et son interface, non officielle, ne se synchronisait plus. Surtout, il gérait mal des centaines de milliers d'adresses bannies à la fois : chaque redémarrage était une épreuve. Il fallait un outil qui condamne à la première requête, sur sa forme et non sur sa répétition, qui tienne des millions de bans sans ralentir le serveur et les restaure en quelques secondes, et surtout qui signale chaque adresse à son opérateur avec de quoi retrouver l'appareil.

C'est pour cela que LRob a écrit Shieldlist. C'est un pare-feu applicatif libre, un agent sur chaque serveur et un contrôleur central, qui lit les journaux, condamne sur des règles lisibles, partage les bans entre machines, et envoie un signalement au format X-ARF au service abuse du réseau d'origine, avec la ligne de journal, l'heure UTC et le port TCP source. Ce dernier détail est ce qui a tout changé.

3. Remonter à l'appareil : le port source#

Un abonné résidentiel partage souvent son adresse IPv4 avec d'autres, derrière un CGNAT. L'adresse seule ne désigne personne. Mais l'opérateur garde les journaux de ses sessions NAT : avec l'heure exacte et le port source, il retrouve l'abonné, puis sur le réseau de l'abonné, l'adresse MAC de l'appareil.

Six opérateurs ont fait ce travail à partir de nos signalements. Nous ne les nommons pas, leur pays suffit ; ce qui frappe, c'est que ce sont souvent de tout petits FAI, un opérateur rural, un réseau d'immeubles, qui lisent leurs signalements et agissent en quelques heures, là où les grands ne répondent pas. Ce qu'ils ont trouvé, résumé :

• Un FAI chilien : des boîtiers Android TV « piratés » sans marque, de vieux Roku, des téléviseurs Samsung de plus de neuf ans.
• Un autre FAI américain : un appareil à module Wi-Fi Earda Technologies (préfixe MAC 68:B9:C2, un fabricant de Guangzhou de modules et de boîtiers Android TV), hors ligne au moment de la vérification.
• Un petit FAI américain : un boîtier vendu comme « Chromecast », module Wi-Fi d'un fabricant chinois (préfixe MAC 58:E4:EB), dans un foyer inactif ; 100 à 136 nouvelles connexions sortantes toutes les 10 secondes. Bloqué, le trafic s'arrête à la seconde ; débloqué pour un test, il reprend à la seconde.
• Un autre FAI américain, sur trois signalements puis un balayage de tout son réseau : douze appareils dans huit immeubles de quatre États. Onze ont un préfixe MAC Amazon, Android 9, de type Fire TV ; un est une carte Android TV Shenzhen Cultraview. Chaque appareil tient une connexion permanente vers un seul relais, sur un port entre 10 000 et 20 000 qui change de quelques heures à deux semaines. Le client proxy est actif sept minutes après la première apparition de l'appareil sur le réseau. Le 12 octobre, trois appareils ont changé de relais à la même minute : la flotte est pilotée centralement.
• Un FAI rural américain : une Vseebox, boîtier « IPTV gratuite » vendu en ligne, qui parlait à des centres de données en Chine et en Russie.
• Un FAI américain, au niveau du trafic : « ce n'est pas un beacon de commande et contrôle. Le relais ouvre une connexion, soumet une requête HTTP avec un User-Agent de navigateur contrefait, l'appareil va chercher la page et renvoie la réponse. » 72 % des requêtes de l'appareil suivaient de moins de 100 ms une connexion du relais. Puis trois appareils sur son réseau, chacun avec son relais, tous chez le même hébergeur.
• Un FAI ukrainien : « la grande majorité de ces événements viennent de boîtiers Android TV chinois bon marché, X96, X98 et similaires, préinfectés. Ce trafic est purement applicatif, sur les ports standard : impossible de le filtrer au niveau du FAI sans couper l'abonné. Notre seul remède : identifier l'abonné par les journaux CGNAT et exiger le retrait du boîtier. »
• Un fournisseur américain de réseaux invités (hôtels, résidences) : l'appareil d'un invité, préfixe MAC Amazon, bloqué par adresse matérielle. Un camping, plus tôt, n'avait pas retrouvé l'appareil : l'invité était reparti.
• Un FAI américain gérant des immeubles, signalé une seule fois à ce jour : l'adresse d'un appartement vacant, dont le seul appareil connecté était un électroménager connecté General Electric (préfixe MAC FC:B9:7E, GE Appliances). Le FAI n'a pas pu confirmer que c'était lui ; il a coupé tout le trafic de l'appartement. Si cela se confirme, ce sera le premier appareil hors boîtier TV : de l'IoT de cuisine.
• Un opérateur libanais, un jour après la publication de ce rapport : à partir du seul guide de détection, il a bloqué sur tout son pool CGNAT les adresses des relais et des contrôleurs, le TCP 7001 de la signature B et le TCP 25 sortant, journalise les tentatives, et contacte les abonnés concernés pour faire retirer les appareils. Il promet de nous rapporter les nouveaux relais et les modèles trouvés.
• Et la première explication d'un Fire TV infecté : l'abonné avait prêté ses clés à un ami, qui y avait installé un app store alternatif plein de clients Netflix et Hulu « gratuits ». Ces applications crackées embarquent le malware. L'abonné remplace ses clés par des neuves.
• Un FAI brésilien, le premier cas en IPv6 : pour un signalement sur notre forge de code, le préfixe /64 s'est avéré délégué à un seul abonné résidentiel, identifié par les serveurs d'accès de l'opérateur (session ouverte depuis le 14 octobre, couvrant l'événement). L'abonné sera invité à vérifier ses boîtiers Android TV et clés de streaming, « comme décrit dans votre documentation Proxynvader ». Interrogé sur les hôtes IPv6 qui pilotent l'appareil, l'opérateur a relu ses données de flux échantillonnées pour le /64 sur vingt heures : tout le trafic en TCP 443, des destinations uniques dispersées chez des hébergeurs du monde entier, et une poignée de destinations qui reviennent sur plusieurs heures, dont des frontaux de CDN. C'est le trafic relayé lui-même : une sortie proxy parle aux sites que ses clients lui demandent, et un site scrapé pendant des heures revient autant qu'un relais. Rien n'y ressemble à un canal de contrôle, dont la signature IPv4 est une connexion permanente sur un port entre 10 000 et 20 000. L'explication probable : le boîtier reçoit ses ordres en IPv4, à travers le CGNAT, et ne fait que sortir en IPv6 ; le canal de contrôle est à chercher dans les sessions NAT IPv4 de l'abonné, ce que nous avons demandé ensuite. Sur la box de l'abonné, l'opérateur a ensuite trouvé un appareil Android à puce Wi-Fi Shenzhen iComm Semiconductor (préfixe MAC 84:B4:D2), une puce courante dans les boîtiers Android TV bon marché, et l'a retiré du réseau ; marque et modèle ne sont pas encore connus.
• Un FAI colombien, à partir d'un seul signalement sur notre forge de code, avec l'heure UTC et le port source : un abonné résidentiel par les journaux CGNAT, et sur le réseau de cet abonné un appareil « participant à un réseau de proxy résidentiel / partage de bande passante en pair à pair : des dizaines de milliers de connexions simultanées, un maillage UDP sur le port 7649 et des tunnels sur des ports inhabituels ». L'opérateur a bloqué ce trafic sur son routeur de cœur sans couper le service de l'abonné, a prévenu l'abonné, et a ajouté une détection du motif sur tout son réseau. Le maillage UDP est nouveau pour nous : ni signature A ni signature B, vu une fois, sur un appareil ; il figure dans le guide comme motif à confirmer.
• Un FAI britannique, le lendemain d'un signalement de la vague des boutiques : l'appareil est un X88 Mini 14 (Rockchip RK3518), acheté sur Amazon UK où il est vendu comme « Android TV Box 14.0, 4K HDR10, 2 Go/16 Go », puce Wi-Fi Hui Zhou Gaoshengda (préfixe MAC DC:72:23). Vendu comme Android 14, il se présente à la box comme Android 9, comme les boîtiers de type Fire TV. Après AliExpress, le second canal d'achat nommé est la place de marché d'Amazon. Interrogé sur ce qu'il y avait installé, l'abonné a répondu que rien ne l'avait été : les applications standard étaient déjà là. Le boîtier était infecté tel que vendu, ce que l'image disque de la section 4 montrait. Et celui-ci ne promettait rien d'illégal : pas de « sport et films gratuits », juste Prime Video et Netflix dans un salon. Que le boîtier lui-même soit un produit légitime est une autre question, un clone Android TV sans marque l'est rarement ; mais l'abonné l'a acheté et utilisé comme un lecteur ordinaire, et l'idée que seuls ceux qui cherchent un boîtier pirate finissent dans le parc ne tient pas.
• Un FAI pakistanais, le lendemain d'un signalement de la vague des boutiques : l'abonné retrouvé par les journaux de blocs de ports du CGNAT, une box en mode pont avec derrière « très probablement un boîtier Android TV infecté », l'abonné contacté. Et, à partir du seul guide, les préfixes des relais, les serveurs de contrôle et le jeu TCP 7001 bloqués sur tout le réseau, sur ses routeurs d'accès : « en quelques minutes, le blocage rejetait déjà des tentatives de connexion d'autres appareils d'abonnés », que l'opérateur identifie maintenant un par un. La liste de blocage sert aussi de recensement des foyers infectés, ce que nous espérions d'elle.
• Un FAI canadien, le jour même du signalement : la réponse la plus riche à ce jour, une capture de paquets côté WAN de la box de l'abonné, longue de trois minutes et demie. L'appareil est un boîtier Android TV à module Wi-Fi Zhuolian (Shenzhen) Communication (préfixe MAC 68:8F:C9) ; l'opérateur travaille avec l'abonné pour le retrouver et le retirer. En trois minutes et demie : 708 connexions sortantes vers environ 400 adresses et 350 noms de sites différents, boutiques, forums, sites de sport et d'actualité du monde entier ; cinquante-deux connexions IMAP vers un fournisseur de mail canadien, et d'autres vers des boîtes allemandes, françaises, américaines et Microsoft, relayées par le boîtier, ce à quoi ressemble, vu de l'extérieur, le test de mots de passe volés ; chaque nom DNS envoyé en clair à 8.8.8.8, 1.1.1.1 et au résolveur chinois 223.6.6.6 en même temps ; et le boîtier qui vérifie sans cesse sa propre adresse publique par six services « quelle est mon IP ». L'empreinte TCP des connexions est celle que nous avions mesurée depuis nos serveurs un mois plus tôt, une pile Linux à fenêtre 65535, vue cette fois du côté de l'appareil. Le relais envoie au boîtier les poignées de main TLS brutes des sites à aller chercher : le boîtier relaie des octets, le chiffrement est entre le client du proxy et la cible, et c'est pourquoi nous voyons des clients Python et Go sous la pile TCP d'un boîtier TV. Et aucun des relais n'était de ceux que nous avions publiés : ce boîtier parle à des serveurs Alibaba, Tencent, BytePlus, Taobao et Zenlayer, sur un port 14101 de longue durée, sur le port 9000 avec un en-tête de trame de 12 octets, et sur une poignée de ports bas portant des battements de cœur chiffrés. Une seconde infrastructure de relais, détaillée en section 5 et dans le guide. Une chose encore : toutes les trente secondes, le boîtier résout s1.gmslb.net, le domaine de contrôle de Popa, le plugin proxy du botnet Vo1d documenté par Qurium et Brian Krebs en juin 2026, et ce nom résout vers les dix mêmes serveurs que le domaine de contrôle de la porte dérobée d'usine du boîtier que nous avons disséqué en section 4.

4. À l'intérieur d'un boîtier#

Nous avons pu analyser le stockage d'un boîtier infecté : un boîtier Android TV sans marque, processeur Rockchip RK3228, firmware d'un fabricant « HX », applications IPTV préinstallées (Magis TV, Latino TV). On y trouve, empilés :

• une porte dérobée d'usine dans libandroid_runtime.so, au niveau du firmware, qui peut installer silencieusement ;
• des modules de fraude publicitaire ;
• un Android.Pandora, de la famille Mirai, dormant, téléchargé depuis un serveur français ;
• et le nœud de proxy proprement dit, un démon nommé gomediad, qui se connecte sur le port 80 à treize serveurs d'un même hébergeur et maintient un canal WebSocket de « backconnect » par lequel arrivent les requêtes à relayer.

Le tout avec adb ouvert sur le réseau, sans mot de passe, en root. Autrement dit, un appareil intégralement contrôlable à distance, sur le même Wi-Fi que les ordinateurs, téléphones et objets connectés du foyer. Le proxy n'est que l'usage visible.

C'est le profil exact de BADBOX 2.0 décrit par HUMAN Security : des appareils infectés avant la vente, un chargeur au niveau du firmware, plusieurs « schémas » de monétisation empilés, dont le proxy résidentiel. Et il a un nom à l'autre bout du monde : le domaine de contrôle de la porte dérobée, ycxrl.com, résout vers dix serveurs chez Leaseweb et Hurricane Electric, et ces dix mêmes serveurs répondent pour s1.gmslb.net et lb.gmslb.net, le domaine de contrôle de Popa, que Qurium et Brian Krebs ont décrit en juin 2026 comme le plugin proxy du botnet Vo1d, alimentant le fournisseur de proxys résidentiels NetNut, avec un million et demi à deux millions et demi d'adresses par jour. Un opérateur canadien a vu un boîtier infecté de son réseau interroger ce nom précis toutes les trente secondes (section 3). Le chargeur de notre boîtier et le beacon du leur partagent un même backend. Nous l'écrivons pour ce que c'est, un fait DNS vérifié, et laissons l'attribution du trafic proxy lui-même à ceux qui peuvent voir les relais de l'intérieur. Et c'est le profil du Superbox décrit par Brian Krebs en novembre 2025, et des boîtiers que Kimwolf recrute par millions depuis la fin 2025 à travers les réseaux de proxys résidentiels. Tout cela n'est pas une succession d'affaires distinctes. C'est une seule base d'attaque : les mêmes usines, les mêmes chaînes d'approvisionnement, les mêmes vendeurs de proxys, des clients différents qui louent la sortie.

5. Comment ça marche, vu du serveur et vu du foyer#

Un réseau de proxys résidentiels à jobs. Le client du réseau, ici un programme de collecte massive de catalogues de boutiques, envoie ses requêtes à une passerelle. La passerelle les distribue à des milliers d'appareils, chacun en exécute une ou deux, et renvoie la réponse. Pour le site visé, chaque requête vient d'un foyer différent, avec une adresse neuve. Pour le foyer, c'est un boîtier qui « télécharge un peu ». Le boîtier est utilisé comme un simple proxy HTTP : sur le port 80, certaines de ses requêtes nous arrivent dans la forme absolue qu'un client n'envoie qu'à un proxy, GET http://site/page HTTP/1.1, retransmise telle que reçue de la passerelle. Le même foyer relaie à nouveau des semaines plus tard avec une signature de navigateur différente à chaque fois : le User-Agent est celui de la passerelle, choisi par job, pas celui de l'appareil.

Deux signatures réseau, mesurées par les opérateurs, permettent à n'importe quel FAI de retrouver ces appareils sans inspection de contenu :

• Signature A, le canal de jobs : une connexion TCP permanente d'un appareil vers une adresse d'un hébergeur de relais, sur un port entre 10 000 et 20 000, le port tournant de quelques heures à deux semaines, l'adresse fixe pendant des mois. Préfixes vus : 89.187.180.0/22, 152.233.22.0/23, 185.156.47.0/24, 195.181.171.0/24, 95.173.206.0/24, 89.187.182.0/24, 79.127.250.0/24, 143.244.35.0/24.
• Signature B, une seconde composante : des connexions TCP 7001 maintenues en parallèle vers un jeu fixe de 22 serveurs chez Oracle Cloud et DigitalOcean. Cinq appareils sur neuf la portent sans la signature A : c'est un autre composant, sur la même classe d'appareils, dont le rôle n'est pas encore établi.
• Le volume : 3 000 à 20 000 destinations distinctes par jour là où un foyer en a quelques dizaines ; jusqu'à un million de connexions par jour pour un seul boîtier.

Jusqu'au 30 octobre, tous les relais de contrôle rapportés par les opérateurs étaient hébergés chez Datacamp Limited (AS60068, marques CDN77 et DataPacket), dans au moins six sites américains, à l'exception d'un contrôleur chez Hivelocity (AS29802) et de canaux secondaires chez Blazing SEO (AS397630), un vendeur de proxys, et DigitalOcean (AS14061). La capture d'un opérateur canadien a ensuite montré une seconde infrastructure de relais, sans aucune adresse Datacamp : des connexions de longue durée sur le port 14101 vers des serveurs Alibaba (AS45102), Taobao (AS24429) et Zenlayer (AS62610), des tunnels tramés sur le port 9000 chez Zenlayer, et des canaux de type contrôle sur des ports bas (119 à 263) chez Alibaba, BytePlus (AS150436) et Tencent (AS132203). Même classe d'appareil, même forme de canal de jobs, d'autres hébergeurs : soit un second vendeur de proxys chargé sur les mêmes boîtiers, soit l'autre pool du même vendeur. Les deux sont dans le guide. La seconde composante (TCP 7001) tourne sur 22 serveurs chez Oracle Cloud (AS31898) et DigitalOcean. Nous l'écrivons comme un fait de journaux, pas comme une accusation : un hébergeur loue des serveurs, et trois opérateurs lui ont signalé ses relais, le dernier le 26 octobre avec l'adresse et le port du relais. À nos 310 signalements, son abuse desk répond par un accusé automatique : « hébergeur non géré, transmis au client concerné ». Sans suite connue : les relais sont toujours là.

En IPv6, la seule observation à ce jour (les données de flux échantillonnées d'un opérateur brésilien pour un préfixe infecté, section 3) ne montre que des sorties, toutes en TCP 443, et aucun canal de contrôle : l'appareil prend très probablement ses ordres en IPv4, à travers le CGNAT, comme les autres.

À quoi servent les sorties. La collecte de nos sites est ce que nous voyons ; ce n'est pas tout. Dans la capture canadienne, un cinquième des connexions du boîtier en trois minutes et demie étaient des connexions IMAP vers des fournisseurs de mail, cinquante-deux vers un seul fournisseur canadien : quelqu'un testait des mots de passe de boîtes mail à travers un foyer canadien, pour que le fournisseur voie se connecter un abonné canadien. L'appareil américain de la section 3 tentait le TCP 25 douze mille fois par jour. Le vol de comptes et le spam empruntent les mêmes boîtiers que les collecteurs.

6. Quelle taille ?#

Nous ne voyons que ce qui frappe nos serveurs. Ce que nous avons mesuré, adresses distinctes bannies par les règles de ce parc :

Une adresse n'est pas un appareil : une adresse résidentielle change, une adresse partagée en cache plusieurs. Mais plus d'un million d'adresses distinctes en vingt-quatre heures, sur un seul site, c'est l'ordre de grandeur du parc que cet opérateur peut mobiliser d'un coup. Pour comparaison : BADBOX 2.0 comptait plus d'un million d'appareils ; Kimwolf, selon Synthient, deux millions d'appareils et douze millions d'adresses par semaine ; un botnet de proxys sur Windows et macOS décrit par Gridinsoft en juillet 2026 en comptait 400 000. Un autre hébergeur, sur des boutiques Magento, a vu passer plus de six millions d'adresses de la même campagne sur l'année. Le parc derrière Proxynvader se compte en millions d'appareils, et ce que nous en voyons n'en est qu'une partie.

Qui vend ces sorties ? Pour la vague du calendrier, et pour elle seule, nous avons un nom : Kookeey (kookeey.net, société de Hong Kong). Voici comment nous y sommes arrivés, par recoupement de bases OSINT publiques, et avec les pincettes qui s'imposent. Parmi les quelque 600 serveurs OVH qui relayaient l'attaque, nous en avons étudié un : le profil technique relevé par Shodan et par nos propres mesures (tous les ports de 1 à 10 000 ouverts sur un démon muet, un serveur web par défaut, un VPS au nom par défaut) est celui d'une passerelle de proxys, et environ un tiers des 600 serveurs présentent le même profil. La base Spur, qui classe les adresses par leur usage observé, étiquette cette passerelle « KOOKEEY_PROXY, Callback Proxy ». Le profil du fournisseur chez Synthient le décrit comme un revendeur de proxys résidentiels à risque élevé, approvisionné par un SDK de proxyware embarqué dans des applications, avec un pool composé pour 63 % d'adresses brésiliennes et 10 % d'argentines. Or les adresses qui nous attaquaient étaient d'abord brésiliennes et argentines, des box et des téléphones. Trois sources indépendantes qui se recoupent sur une adresse, une géographie et un mode opératoire ; mais une seule passerelle étiquetée, et des profils publics. C'est une corrélation, pas une preuve : seul OVH, ou une investigation sur ces machines, pourrait dire quel client les louait, et nous ne l'écrivons pas pour la vague des boutiques, où rien de tel n'a été observé.

Ce que Kookeey vend, en clair, c'est ce que nous subissons. Le site annonce un « 47 M+ Residential IP Pool » dans 190 pays, dont 6,9 millions d'adresses au Brésil, 2,5 millions aux États-Unis et 1,8 million en Inde, et des proxys « mobiles » au même nombre. On achète du trafic au gigaoctet, autour de dix yuans, soit un peu plus d'un euro, puisé dans un pool d'un pays au choix, un million d'adresses américaines par exemple, avec une adresse nouvelle à chaque requête, en SOCKS5, HTTP, Vmess, Shadowsocks ou WireGuard. L'argumentaire : des « IP propres », la collecte de données, le SEO, la vérification publicitaire, la gestion de comptes sur les réseaux sociaux. Rien sur l'origine des adresses, rien sur le consentement de ceux qui les fournissent. Voilà le marché : des appareils de particuliers, revendus au gigaoctet, à qui veut.

7. Pourquoi « Proxynvader »#

BADBOX 2.0 est le nom que HUMAN Security a donné à l'opération de 2025. Ce que nous voyons en 2026 en est la suite, et la différence qui compte : ce ne sont plus seulement des boîtiers sans marque préinfectés, mais aussi des appareils de grande marque, infectés par ce qu'on y installe. Le nom devait dire l'objet du délit, un proxy, et l'intrusion chez quelqu'un qui n'a rien demandé, foyer, bureau, hôtel ou camping. Proxynvader, le proxy qui envahit. Les vagues gardent leur nom technique : facet flood pour les boutiques, calendar flood pour les calendriers, forge crawl pour les forges de code.

8. La France : des milliers de signalements, aucune réponse#

Chaque adresse française bloquée reçoit un signalement au service abuse de son opérateur : la ligne de journal, l'heure UTC, le port source. Tout ce qu'il faut pour retrouver l'abonné et lui dire qu'un appareil chez lui travaille pour d'autres.

Adresses distinctes bloquées depuis le 18 août, signalements envoyés depuis le 20 septembre, au 21 octobre 2026 ; les signalements sont plafonnés par réseau et par jour, d'où l'écart. La courbe des adresses de ces quatre opérateurs : 2 081 la semaine du 21 septembre, 1 371 la suivante, 40 167 la semaine du 12 octobre, dont 37 273 pour la seule vague du calendrier en 29 heures, puis 8 215 du 19 au 21 octobre, soit en trois jours quatre fois une semaine de fin septembre. 98 % de ces adresses ont été bloquées depuis le 1er octobre. D'autres attaques venant d'adresses résidentielles françaises, injections SQL et sondes, recoupent ce parc pour 10 à 30 % de leurs adresses : une partie en vient, pas l'essentiel. Six opérateurs étrangers ont retrouvé et neutralisé les appareils à partir des mêmes signalements. Les quatre français n'ont pas envoyé un accusé de réception. Pendant ce temps, la part française grossit de semaine en semaine, et des abonnés légitimes découvrent leur adresse bloquée sur des boutiques en ligne, parfois parce qu'un voisin d'adresse IPv4 partagée héberge le boîtier.

Nous avons écrit aux CERT, à l'ANSSI. L'ANSSI a répondu, courtoisement, que cela n'entre pas dans ses attributions, et nous a renvoyés vers une plateforme de signalement de contenus illicites qui n'a pas de case pour « infection de masse d'appareils ». Nous ne leur en voulons pas : leur périmètre est ce qu'il est. Mais nous posons la question publiquement, puisque personne ne la prend en privé : qui, en France, reçoit l'alerte quand des dizaines de milliers de foyers français servent de relais à une attaque mondiale ? Les opérateurs sont des opérateurs d'importance vitale. Leurs abonnés hébergent, sans le savoir, des appareils contrôlés depuis l'étranger. Les éléments sont là, datés, sourcés, et conservés.

Cet article existe aussi pour cela. À partir d'aujourd'hui, personne ne pourra dire qu'il ne savait pas.

Qui répond, qui ne répond pas#

Cette liste sera tenue à jour. Elle ne juge pas la taille d'un réseau ni le nombre d'appareils infectés chez lui, personne n'y peut rien ; elle dit qui lit ses signalements et agit.

9. Ce qu'il faut faire#

Si vous êtes un opérateur#

1. Appliquez les deux signatures ci-dessus à vos journaux NetFlow et à vos sessions NAT ; le guide pour les opérateurs donne la méthode, les adresses des relais et les préfixes MAC, prêts à copier. Un opérateur américain l'a fait sur tout son réseau et a trouvé neuf appareils de plus en une journée.
2. Prévenez chaque abonné concerné, individuellement, et demandez le retrait ou la réinitialisation de l'appareil. Bloquez son adresse MAC sur la box en attendant.
3. Lisez vos abuse reports. Un signalement X-ARF avec heure et port source se traite en minutes.
4. Blackholez les relais connus, et signalez-les à leur hébergeur. La liste est disponible sur demande, et le sera ici.
5. Récupérez des appareils pour analyse, et partagez : chaque modèle identifié aide les autres.

Si vous avez un boîtier TV ou une clé de streaming#

Le FBI a publié en mars 2026 une alerte dédiée, Evading Residential Proxy Networks, qui dit l'essentiel :

• évitez les boîtiers qui promettent « sport, séries et films gratuits » ;
• n'installez pas d'app store alternatif ni d'applications hors des boutiques officielles, surtout sur une clé de streaming ou un boîtier Android TV ;
• un appareil préinfecté le reste après une réinitialisation d'usine ; le seul remède est de le remplacer ;
• une fois retiré, changez le mot de passe de tous les comptes que vous y avez utilisés, Prime Video, Netflix, Google, Amazon, et fermez leurs sessions depuis un autre appareil : le boîtier est rooté et piloté de l'extérieur, et qui le pilote peut lire ce qu'il contient, mots de passe et jetons de session compris ;
• regardez la liste des appareils connectés à votre box : celui qui est actif jour et nuit, télé éteinte, c'est lui.

Et ne croyez pas qu'un boîtier est sûr parce que vous ne l'utilisez que pour Prime Video et Netflix : le X88 Mini 14 trouvé chez un abonné britannique en octobre ne promettait rien d'illégal, n'avait rien d'installé, et est arrivé infecté de l'usine. Ce qui vous protège, ce n'est pas ce que vous regardez, c'est d'où vient le boîtier : une marque inconnue sur une place de marché est un risque en soi, quoi que dise la fiche.

Et si votre adresse se retrouve bloquée sur un site, cherchez l'appareil avant de demander le déblocage : il recommencera ailleurs.

Si vous hébergez des sites#

• Répondez à ces requêtes avant l'application : une page de facettes demandée sans Referer et sans cookie de session peut recevoir un 429 par le serveur web lui-même, sans rien calculer.
• Condamnez à la première requête sur la forme, pas sur la répétition : il n'y a pas de seconde requête.
• Signalez chaque adresse à son opérateur avec l'heure UTC et le port source. C'est long, c'est ingrat, et c'est la seule chose qui, jusqu'ici, a fait retirer des appareils.
• Si vous voulez un outil qui fait tout cela, Shieldlist est libre, et c'est pour cette attaque qu'il a été écrit.

10. Un appel à coordination#

Cette attaque n'a pas de centre que l'on puisse faire tomber d'un coup : des usines, des vendeurs de proxys, des hébergeurs de relais, des millions de foyers. Mais elle a une faiblesse : chaque appareil est chez un abonné d'un opérateur, et chaque opérateur peut le retrouver en quelques minutes avec les signatures publiées ici. Si les FAI se coordonnent, l'attaque s'éteint. S'ils ne se coordonnent pas, chacun peut encore l'éteindre chez lui, un abonné à la fois. Neuf l'ont déjà fait, dont un à partir du seul guide publié ici, le lendemain de sa parution. Les données sont à disposition de tout opérateur, CERT ou chercheur qui les demandera.

Sources et références#

• HUMAN Security, Satori Threat Intelligence Disruption: BADBOX 2.0 (2025)
• FBI / IC3, Home Internet Connected Devices Facilitate Criminal Activity (juin 2025)
• FBI, Evading Residential Proxy Networks: Protecting Your Devices from Becoming a Tool for Criminals (12 mars 2026)
• Brian Krebs, Is Your Android TV Streaming Box Part of a Botnet? (novembre 2025), The Kimwolf Botnet is Stalking Your Local Network (janvier 2026) et 'Popa' Botnet Linked to Publicly-Traded Israeli Firm (juin 2026)
• Qurium, Finding "Popa": When Your Smart TV Stops Being Yours (juin 2026)
• Kaspersky, Malicious TV boxes: how a cheap “SuperBox” turns your home into a proxy node
• SecurityWeek, Kimwolf Android Botnet Grows Through Residential Proxy Networks
• Wikipédia, Ipidea, un des plus grands réseaux de proxys résidentiels
• Shieldlist, le projet et son code

Journal des mises à jour#

• 30 octobre 2026 : un quatorzième opérateur, au Canada, avec une capture de paquets d'un boîtier infecté : une seconde infrastructure de relais hors Datacamp, des connexions IMAP relayées, l'empreinte TCP confirmée côté appareil (sections 3 et 5) ; le domaine de contrôle du boîtier est celui de Popa, et il partage ses serveurs avec la porte dérobée du boîtier que nous avons disséqué (section 4).
• 29 octobre 2026 : un treizième opérateur, au Pakistan, bloque les relais sur tout son réseau à partir du guide et voit d'autres foyers infectés frapper le blocage en quelques minutes (section 3) ; le boîtier utilisé comme simple proxy HTTP, le User-Agent choisi par job (section 5).
• 28 octobre 2026 : un douzième opérateur, au Royaume-Uni, et un modèle nommé acheté sur Amazon (section 3).
• 26 octobre 2026 : un huitième préfixe de relais, rapporté et vérifié par un opérateur avec le guide (section 5 et le guide).
• 25 octobre 2026 : un onzième opérateur, et un troisième motif de trafic à confirmer (un maillage UDP sur le port 7649), en section 3 et dans le guide.
• 24 octobre 2026 : la quatrième vague (cartes météo), ce qui arrête une vague et ce qui ne l'arrête pas ; un dixième opérateur, la première attribution en IPv6 et les premières données de flux IPv6 (sections 3 et 5).
• 23 octobre 2026 : la taille du parc (section 6), le marché des sorties résidentielles, un neuvième opérateur.
• 22 octobre 2026 : première publication.