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 :
- 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.
- 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.
- 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.nettoutes 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
- 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é.
- 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.
- Garder les journaux de sessions actifs sur tous les équipements : le prochain signalement se traite en minutes.
- 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.
- 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.