Shieldlist

Détecter Proxynvader sur votre réseau : guide pour les opérateurs

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

Ce guide accompagne le rapport Proxynvader. Il est écrit pour l'équipe abuse ou réseau d'un opérateur, petit ou grand, et il est tenu à jour : les adresses de relais changent, les modèles d'appareils s'ajoutent. Tout ce qui suit a été mesuré par des opérateurs qui ont retrouvé les appareils ; rien n'est théorique. Nos listes d'adresses et de modèles viennent de ce que ces opérateurs nous ont remonté : elles ne sont pas complètes, et chaque échange par mail abuse peut les compléter. Si vous voyez autre chose, dites-le-nous.

TL;DR

Un appareil infecté chez un abonné se reconnaît à trois choses, sans aucune inspection de contenu :

  1. Une connexion TCP permanente vers une adresse de relais (liste ci-dessous), sur un port entre 10 000 et 20 000, le port changeant de quelques heures à deux semaines, l'adresse restant la même pendant des mois.
  2. Un volume anormal : des milliers de destinations distinctes par jour, là où un foyer en a quelques dizaines ; jusqu'à une nouvelle connexion sortante toutes les 100 ms ; de l'activité plate, jour et nuit, télé éteinte.
  3. Le type d'appareil : un boîtier Android TV, une clé de streaming, rarement autre chose. Les préfixes MAC vus sont listés plus bas.

Quand vous avez l'appareil : vous bloquez son adresse MAC sur la box, le trafic cesse à la seconde, et vous prévenez l'abonné. C'est tout. Quatorze opérateurs l'ont fait, le plus souvent en quelques heures.

1. Partir d'un signalement

Chaque signalement que nous envoyons est un mail X-ARF lisible par un humain et par une machine. Il contient :

  • l'adresse IP source, IPv4 ou IPv6 (en IPv6, le /64 de l'abonné) ;
  • l'heure UTC, à la seconde ;
  • le port source TCP de la requête ;
  • la ligne de journal du serveur attaqué, telle quelle ;
  • un identifiant [SL-xxxxxxxx] dans le sujet, à garder dans vos réponses.

Avec une adresse IPv4 partagée (CGNAT), l'heure et le port source désignent une seule session dans vos journaux NAT, donc un seul abonné. Avec une adresse dédiée, l'adresse suffit. Si vos journaux de sessions ne sont pas activés sur un équipement, c'est le moment de le faire : un opérateur a découvert ainsi qu'un de ses routeurs d'immeuble n'envoyait pas ses journaux, et l'a corrigé en une heure.

Une fois l'abonné connu, l'appareil se trouve sur son réseau local par les signatures de la section suivante, ou simplement en regardant la liste des appareils connectés à sa box : celui qui est actif en permanence est le bon.

2. Signature A : le canal de jobs vers le relais

L'appareil garde ouverte une connexion TCP vers un seul relais, par laquelle arrivent les requêtes à exécuter. Dans vos flux NetFlow ou IPFIX, ou dans vos sessions NAT :

  • destination dans l'un des préfixes ci-dessous ;
  • port de destination entre 10 000 et 20 000 (observés : 10 008 à 19 017) ;
  • connexion de longue durée, ou rafales de connexions successives vers la même adresse, pendant des jours ;
  • le port change tous les quelques heures ou quelques jours, l'adresse reste.

Préfixes des relais observés, tous chez Datacamp Limited (AS60068, CDN77 / DataPacket) :

89.187.180.0/22
89.187.182.0/24
152.233.22.0/23
185.156.47.0/24
195.181.171.0/24
95.173.206.0/24
79.127.250.0/24
143.244.35.0/24    (rapporté par un opérateur le 25/10/2026, vérifié avec le test et les ports de ce guide)
185.76.10.0/24     (reconnaissance avant une vague, pas un relais)

Adresses de relais nommées par les opérateurs (une adresse, un ou plusieurs appareils) :

95.173.206.249     New York
84.17.40.173       Miami, relais d'amorçage
152.233.23.68
152.233.23.69
152.233.23.70
152.233.23.71
152.233.23.72      Miami
152.233.22.97-103  Miami, TCP 443
89.187.183.70      Chicago
89.187.182.241     Chicago
89.187.182.236     Chicago
143.244.35.77      port 10045 vu par un opérateur (26/10/2026) ; SOCKS 1080 et onze ports entre 10007 et 12580 ouverts, rien d'autre
89.187.182.132     Chicago
89.187.181.161     Chicago
185.156.47.89
195.181.171.179
79.127.250.4       Seattle
95.173.192.97      Atlanta, serveur de configuration probable, TCP 80

Serveurs de contrôle vus depuis un boîtier analysé (AS60068, TCP 80) :

185.152.67.99  185.152.67.98  185.152.67.166
84.17.45.169   84.17.45.172   84.17.45.17   84.17.45.177
89.187.173.109 89.187.173.89  89.187.173.142 89.187.173.121
89.187.187.184 149.34.240.4

Hors Datacamp, même rôle, vus chez un seul opérateur :

107.155.67.26        Hivelocity AS29802, relais pendant deux mois
199.101.137.19:9000  Blazing SEO AS397630
67.205.165.57:9000   DigitalOcean AS14061

Une seconde infrastructure de relais, sans aucune adresse Datacamp (la capture de paquets d'un opérateur sur un boîtier Android TV, le 30/10/2026, trois minutes et demie ; le boîtier n'a contacté aucune des adresses ci-dessus dans cette fenêtre). Même forme, d'autres hébergeurs :

TCP 14101 de longue durée, plusieurs en parallèle (le canal de jobs) :
47.79.3.101  47.79.127.183  47.79.1.108  47.79.125.58  47.79.255.15
43.117.136.1  43.117.136.32  43.119.51.36                 Alibaba AS45102
43.102.158.23  43.102.158.28  43.102.158.31  43.102.158.32
43.102.154.23  43.102.154.26                              Taobao AS24429
128.14.147.52  128.14.147.233                             Zenlayer AS62610

TCP 14302 / 14303 / 14307 courts (environ 2 Ko chacun, répétés) :
47.79.250.76 (14302, 14303)  43.102.130.13 (14307)        Alibaba AS45102
66.93.179.193 (14302)                                     Zenlayer AS62610

TCP 9000, un en-tête de trame de 12 octets puis les données tunnelées :
66.92.17.48  199.190.45.87  107.151.141.171  162.128.70.89  Zenlayer AS62610
199.190.45.101 sur TCP 58000, même comportement           Zenlayer AS62610

Ports bas, ouverts par l'appareil, portant des battements de cœur
chiffrés (base64 « IV:ciphertext » sur le 136) :
43.102.25.182  TCP 202, 246, 119                          Alibaba AS45102
43.116.38.114  TCP 162                                    Alibaba AS45102
45.78.209.249  TCP 229, 136                               BytePlus AS150436
101.47.139.76  TCP 212                                    BytePlus AS150436
43.152.72.237  TCP 263, 128                               Tencent AS132203

Même prudence que pour Datacamp : ce sont des fournisseurs de cloud aux innombrables clients légitimes. Surveillez ou bloquez les adresses, jamais l'AS. Un foyer qui tient une connexion sur le port 14101 ou 9000 vers l'une d'elles pendant des minutes, ou qui ouvre du TCP 119 à 263 vers Alibaba ou Tencent, a l'appareil.

Cette liste n'est pas exhaustive : elle rassemble ce que les opérateurs ont vu et nous ont rapporté. D'autres relais existent sûrement.

Attention au blocage par AS. AS60068 héberge aussi le CDN de CDN77, qui sert des sites légitimes. Bloquez ou surveillez les adresses et les préfixes de relais, pas l'AS entier. Ces blocs sont loués et peuvent bouger : la liste est datée, revenez la lire.

3. Signature B : TCP 7001 vers 22 serveurs fixes

Une seconde composante, présente sur certains appareils avec ou sans la signature A : des connexions TCP 7001 maintenues en parallèle, jour et nuit, vers un jeu fixe de serveurs. Un foyer normal n'en a aucune ; sur un réseau entier, une poignée d'hôtes seulement les présentent, et ce sont les infectés.

Oracle Cloud AS31898 :
40.233.79.245  40.233.91.190  40.233.99.51   40.233.107.223
40.233.113.91  132.145.101.198  132.145.102.197  147.5.98.109

DigitalOcean AS14061 :
104.248.105.59  146.190.190.244  152.42.144.4   152.42.144.63
152.42.144.89   159.203.48.195   159.203.49.5   159.203.50.188
174.138.113.174 174.138.113.216  174.138.114.218 174.138.115.8
174.138.115.38  209.38.0.103

4. Signature de volume

Sans aucune liste d'adresses, l'appareil infecté est l'hôte le plus actif de son réseau, de loin :

Mesure Appareil infecté Foyer ordinaire
Destinations distinctes par 24 h 3 000 à 20 000 quelques dizaines à quelques centaines
Nouvelles connexions sortantes 100 à 136 toutes les 10 secondes quelques-unes par minute
Requêtes DNS par jour environ 48 000, en clair, chaque nom envoyé à 8.8.8.8, 1.1.1.1 et 223.6.6.6 en même temps quelques milliers, vers vos résolveurs
Profil horaire plat, 24 h sur 24 suit la vie du foyer
Tentatives vers TCP 25 environ 12 000 par jour (si non filtré) aucune
Connexions IMAP (TCP 993) vers des fournisseurs de mail où le foyer n'a pas de compte des dizaines en quelques minutes (test de mots de passe relayé) aucune

Un balayage par « destinations distinctes par hôte et par jour », trié par ordre décroissant, fait remonter les appareils en tête de liste. Un opérateur l'a fait sur tout son réseau et a trouvé neuf appareils en une journée, tous confirmés ensuite par la signature A ou B.

Des indices plus fins, tirés de la capture de paquets d'un opérateur (30/10/2026), utiles quand vous voyez le DNS de l'abonné ou les SYN :

  • le boîtier résout s1.gmslb.net toutes les trente secondes ; beaucoup de listes de blocage publiques renvoient déjà ce nom vers 0.0.0.0, c'est un domaine de contrôle du plugin proxy Popa du botnet Vo1d ; si votre résolveur le journalise, l'hôte qui le demande est l'appareil ;
  • il vérifie sans cesse sa propre adresse publique via api.ipify.org, ipv4.icanhazip.com, ip-api.com, ident.me, ip.intrastack.dev, ipvws.com ;
  • ses SYN TCP portent un TTL de 64 avant NAT, une fenêtre de 65535 et une échelle de fenêtre de 6, la pile Linux/Android que nous avions mesurée côté serveur un mois plus tôt ;
  • le relais lui envoie les poignées de main TLS brutes des sites à aller chercher : le boîtier transmet des octets, il ne termine pas le TLS, donc les noms SNI de ses connexions sont les cibles des clients du proxy, des centaines de sites sans rapport en quelques minutes.

Un troisième motif, à confirmer. Un opérateur, sur un appareil retrouvé à partir de notre signalement, décrit quelque chose que ni A ni B ne montrent : « des dizaines de milliers de connexions simultanées, un maillage UDP sur le port 7649 et des tunnels sur des ports inhabituels », la forme d'un réseau de partage de bande passante en pair à pair plutôt que d'un canal unique vers un relais. Il a bloqué ce trafic sur son routeur de cœur et en a ajouté la détection sur tout son réseau. Une observation ne fait pas une signature ; si vous voyez un hôte qui s'éparpille en UDP sur le port 7649, dites-le-nous, et elle en deviendra une ici.

5. Identifier l'appareil sur le réseau local

Sur la box de l'abonné, la liste des appareils connectés donne l'adresse MAC. Préfixes (OUI) vus à ce jour :

Préfixe MAC Fabricant Appareil
58:E4:EB FN-LINK Technology module Wi-Fi d'un boîtier Android TV vendu comme « Chromecast »
68:B9:C2 Earda Technologies (Guangzhou) module Wi-Fi, boîtiers Android TV
A8:2C:3E Shenzhen Cultraview carte Android TV, boîtier sans marque
28:24:C9, 48:B4:23, 00:F3:61, 68:B6:91, 18:48:BE, 08:A6:BC, 8C:2A:85, 1C:93:C4, F0:2F:9E, B4:B7:42, 40:A9:CF, A0:D2:B1 Amazon Technologies Fire TV Stick ou appareil de type Fire TV, Android 9, classe DHCP android-dhcp-9
FC:B9:7E GE Appliances électroménager connecté, un seul signalement, non confirmé
84:B4:D2 Shenzhen iComm Semiconductor puce Wi-Fi courante dans les boîtiers Android TV bon marché ; l'appareil retrouvé et retiré chez un abonné brésilien (cas IPv6)
C0:8A:60 AltoBeam un second appareil sur le réseau du même abonné brésilien ; son rôle n'est pas établi
DC:72:23 Hui Zhou Gaoshengda Technology boîtier Android TV X88 Mini 14, Rockchip RK3518, vendu sur Amazon UK comme « Android TV Box 14.0, 4K HDR10, 2 Go/16 Go » ; classe DHCP android-dhcp-9 (un abonné britannique)
68:8F:C9 Zhuolian (Shenzhen) Communication boîtier Android TV, modèle pas encore connu ; l'appareil de la capture canadienne (seconde infrastructure de relais, section 2)

Modèles nommés par les opérateurs : X96, X98 et boîtiers Android TV bon marché du même type, Superbox, Vseebox, Amazon Fire TV Stick (avec un app store alternatif installé), de vieux Roku, des téléviseurs Samsung de plus de neuf ans, et un X88 Mini 14 (Rockchip RK3518), vendu sur Amazon UK comme « Android TV Box 14.0, 4K HDR10, 2 Go/16 Go » (ASIN B0F8BBZZJH), dont la classe DHCP dit Android 9. Le boîtier que nous avons analysé est un Android TV sans marque, processeur Rockchip RK3228, firmware « HX », applications IPTV préinstallées.

Deux indices de plus : le client proxy démarre sept à huit minutes après la première apparition de l'appareil sur le réseau ; et l'appareil reste actif quand le téléviseur est éteint.

6. Vérifier avant d'agir

La preuve est simple et réversible : bloquez l'adresse MAC de l'appareil sur la box. Le trafic vers le relais cesse à la seconde. Débloquez une minute : il reprend à la seconde. Un opérateur l'a fait dans les deux sens ; c'est la confirmation la plus nette qu'on puisse avoir, et elle ne demande ni capture ni analyse.

7. Agir

  1. Quarantaine par adresse MAC sur le routeur de l'abonné, IPv4 et IPv6 : l'appareil garde le réseau local, perd internet, le reste du foyer n'est pas touché.
  2. Prévenir l'abonné. Il ne sait rien. Dites-lui quel appareil, et que la réinitialisation d'usine ne suffit pas pour un boîtier infecté avant la vente : il faut le remplacer. Pour un Fire TV Stick, retirer l'app store alternatif et les applications qui en viennent, ou réinitialiser. Et dites-lui de changer les mots de passe de tous les comptes utilisés sur l'appareil, Prime Video, Netflix, Google, et d'en fermer les sessions depuis un autre appareil : le boîtier est rooté et piloté à distance, et qui le pilote peut lire les identifiants et les jetons de session qu'il contient.
  3. Garder les journaux de sessions actifs sur tous les équipements : le prochain signalement se traite en minutes.
  4. Surveiller ou bloquer les relais listés plus haut, à l'adresse, et les signaler à l'hébergeur (abuse@datacamp.co.uk pour AS60068). Trois opérateurs l'ont fait, deux sur tout leur réseau à partir de cette seule page ; l'un a vu d'autres foyers infectés frapper le blocage en quelques minutes, ce qui fait du blocage un recensement.
  5. Nous dire ce que vous trouvez : marque, modèle, préfixe MAC, et si possible l'application en cause. Chaque appareil identifié entre dans ce guide et aide le suivant. Un appareil récupéré peut nous être confié pour analyse.

Texte prêt à envoyer à un abonné, à adapter :

Un appareil connecté à votre box (un boîtier TV ou une clé de streaming, adresse MAC xx:xx:xx:xx:xx:xx) a été identifié comme faisant partie d'un réseau de proxys utilisé pour attaquer des sites web, à votre insu. Nous avons coupé son accès à internet ; le reste de votre installation fonctionne normalement. Cet appareil doit être retiré ou réinitialisé ; s'il a été acheté hors des circuits officiels ou promet des chaînes gratuites, il doit être remplacé : il est infecté d'usine. Comme l'appareil est piloté à distance, changez aussi le mot de passe de tous les comptes que vous y avez utilisés (streaming vidéo, compte Google ou Amazon) et fermez leurs sessions depuis un autre appareil. Nous restons à votre disposition.

8. Ce que nous fournissons

  • Les signalements en continu, X-ARF, avec heure et port source, au contact abuse de votre réseau.
  • Sur demande : l'historique des adresses de votre réseau que nous avons bloquées, avec les heures et les ports, pour recouper vos journaux.
  • Ce guide, tenu à jour. Les adresses de relais sont des blocs loués : ce qui est vrai aujourd'hui peut bouger ; revenez à la version datée en haut de page.
  • Une oreille attentive : tout ce que ce guide contient vient des réponses des opérateurs à nos signalements. Ce que vous nous écrivez, en réponse à un abuse report ou directement, entre dans la prochaine version.

Contact : abusereport@lrob.net, en français ou en anglais.

Journal des mises à jour

  • 30 octobre 2026 : une seconde infrastructure de relais hors Datacamp, chez Alibaba, Taobao, Zenlayer, BytePlus et Tencent, avec ses ports (section 2) ; le DNS vers trois résolveurs publics à la fois, les connexions IMAP relayées, le beacon s1.gmslb.net, les services « quelle est mon IP » et l'empreinte TCP (section 4) ; un préfixe MAC (68:8F:C9, Zhuolian) en section 5. Le tout tiré de la capture de paquets d'un opérateur canadien.
  • 28 octobre 2026 : un préfixe MAC (DC:72:23) et un modèle nommé, le X88 Mini 14 (Rockchip RK3518) vendu sur Amazon UK, d'un opérateur britannique (section 5) ; l'abonné doit aussi changer les mots de passe des comptes utilisés sur l'appareil (section 7).
  • 26 octobre 2026 : un préfixe de relais (143.244.35.0/24, Datacamp), une adresse de relais dedans (143.244.35.77, port 10045) et un douzième préfixe MAC Amazon (A0:D2:B1), d'un opérateur qui a vérifié deux cas avec ce guide.
  • 25 octobre 2026 : un troisième motif de trafic rapporté par un opérateur (maillage UDP sur le port 7649), à confirmer, en section 4 ; deux préfixes MAC du cas brésilien en section 5.
  • 22 octobre 2026 : première publication.