Detecting Proxynvader on your network: a guide for operators

Published October 22, 2026 · last updated October 30, 2026

This guide goes with the Proxynvader report. It is written for the abuse or network team of an operator, small or large, and it is kept up to date: relay addresses change, device models get added. Everything below was measured by operators who found the devices; nothing is theoretical. Our lists of addresses and models come from what those operators reported back to us: they are not complete, and every abuse-mail exchange can add to them. If you see something else, tell us.

TL;DR#

An infected device at a subscriber's is recognised by three things, without any content inspection:

1. A permanent TCP connection to a relay address (list below), on a port between 10,000 and 20,000, the port changing every few hours to two weeks, the address staying the same for months.
2. An abnormal volume: thousands of distinct destinations a day, where a household has a few dozen; up to one new outbound connection every 100 ms; flat activity, day and night, TV off.
3. The device type: an Android TV box, a streaming stick, rarely anything else. The MAC prefixes seen are listed below.

Once you have the device: you block its MAC address on the router, the traffic stops within the second, and you tell the subscriber. That is all. Fourteen operators have done it, most of them within hours.

1. Starting from a report#

Every report we send is an X-ARF mail, readable by a person and by a machine. It carries:

• the source IP address, IPv4 or IPv6 (for IPv6, the subscriber's /64);
• the UTC time, to the second;
• the TCP source port of the request;
• the attacked server's log line, verbatim;
• an identifier [SL-xxxxxxxx] in the subject, to keep in your answers.

With a shared IPv4 address (CGNAT), the time and the source port designate a single session in your NAT logs, hence a single subscriber. With a dedicated address, the address is enough. If session logging is off on some equipment, now is the time to turn it on: one operator found this way that one of its building routers was not sending its logs, and fixed it within the hour.

Once the subscriber is known, the device is found on their local network with the signatures of the next section, or simply by looking at the list of devices connected to their router: the one that is permanently active is the one.

2. Signature A: the job channel to the relay#

The device keeps one TCP connection to a single relay open, through which the requests to execute arrive. In your NetFlow or IPFIX flows, or in your NAT sessions:

• destination within one of the prefixes below;
• destination port between 10,000 and 20,000 (observed: 10,008 to 19,017);
• a long-lived connection, or bursts of successive connections to the same address, for days;
• the port changes every few hours or days, the address stays.

Relay prefixes observed, all at 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    (reported by an operator on 2026-10-25, verified against the test and ports of this guide)
185.76.10.0/24     (reconnaissance before a wave, not a relay)

Relay addresses named by operators (one address, one or several devices):

95.173.206.249     New York
84.17.40.173       Miami, bootstrap relay
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 seen by an operator (2026-10-26); SOCKS 1080 and eleven ports between 10007 and 12580 open, nothing else
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, probable configuration server, TCP 80

Control servers seen from an analysed box (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

Outside Datacamp, same role, seen at a single operator:

107.155.67.26        Hivelocity AS29802, relay for two months
199.101.137.19:9000  Blazing SEO AS397630
67.205.165.57:9000   DigitalOcean AS14061

A second relay infrastructure, with no Datacamp address in it (one operator's packet capture of one Android TV box, 2026-10-30, three and a half minutes; the box contacted none of the addresses above in that window). Same shape, other hosts:

Long-lived TCP 14101, several in parallel (the job channel):
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

Short TCP 14302 / 14303 / 14307 (about 2 KB each, repeated):
47.79.250.76 (14302, 14303)  43.102.130.13 (14307)        Alibaba AS45102
66.93.179.193 (14302)                                     Zenlayer AS62610

TCP 9000, a 12-byte frame header then tunnelled data:
66.92.17.48  199.190.45.87  107.151.141.171  162.128.70.89  Zenlayer AS62610
199.190.45.101 on TCP 58000, same behaviour               Zenlayer AS62610

Low ports, opened by the device, carrying encrypted heartbeats
(base64 "IV:ciphertext" on 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

The same caution applies as for Datacamp: these are cloud providers with countless legitimate tenants. Watch or block the addresses, never the AS. A household that holds a connection on port 14101 or 9000 to one of them for minutes on end, or opens TCP 119 to 263 toward Alibaba or Tencent, has the device.

This list is not exhaustive: it gathers what operators saw and reported to us. Other relays surely exist.

Careful with blocking by AS. AS60068 also hosts the CDN77 content delivery network, which serves legitimate sites. Block or watch the relay addresses and prefixes, not the whole AS. These blocks are leased and can move: the list is dated, come back to it.

3. Signature B: TCP 7001 to 22 fixed servers#

A second component, present on some devices with or without signature A: TCP 7001 connections held in parallel, day and night, to a fixed set of servers. A normal household has none; on a whole network, only a handful of hosts show them, and those are the infected ones.

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. Volume signature#

Without any address list, the infected device is the busiest host of its network, by far:

A sweep by "distinct destinations per host per day", sorted in descending order, brings the devices to the top of the list. One operator did it on its whole network and found nine devices in a day, all confirmed afterwards by signature A or B.

Smaller tells, from one operator's packet capture (2026-10-30), useful when you can see the subscriber's DNS or the SYNs:

• the box resolves s1.gmslb.net every thirty seconds; many public blocklists already sinkhole this name, which is a control domain of the Popa proxy plugin of the Vo1d botnet; if your resolver logs it, the querying host is the device;
• it keeps checking its own public address through api.ipify.org, ipv4.icanhazip.com, ip-api.com, ident.me, ip.intrastack.dev, ipvws.com;
• its TCP SYNs carry a TTL of 64 before NAT, a window of 65535 and a window scale of 6, the Linux/Android stack we had measured from the server side a month earlier;
• the relay sends it raw TLS handshakes for the sites to fetch: the box forwards bytes, it does not terminate TLS, so the SNI names on its connections are the targets of the proxy's customers, hundreds of unrelated sites in minutes.

A third pattern, to confirm. One operator, on one device found from our report, describes something neither A nor B shows: "tens of thousands of concurrent connections, a UDP mesh on port 7649 and tunnels on uncommon ports", the shape of a peer-to-peer bandwidth-sharing network rather than of a single relay channel. It blocked that traffic at its core router and added network-wide detection of it. One observation is not a signature; if you see a host fanning out in UDP on port 7649, tell us, and it will become one here.

5. Identifying the device on the local network#

On the subscriber's router, the list of connected devices gives the MAC address. Prefixes (OUIs) seen so far:

Models named by operators: X96, X98 and cheap Android TV boxes of the same kind, Superbox, Vseebox, Amazon Fire TV Stick (with an alternative app store installed), old Rokus, Samsung televisions more than nine years old, and an X88 Mini 14 (Rockchip RK3518), listed on Amazon UK as "Android TV Box 14.0, 4K HDR10, 2 GB/16 GB" (ASIN B0F8BBZZJH), whose DHCP class says Android 9. The box we analysed is an unbranded Android TV, Rockchip RK3228 processor, "HX" firmware, pre-installed IPTV apps.

Two more clues: the proxy client starts seven to eight minutes after the device first appears on the network; and the device stays active when the television is off.

6. Verifying before acting#

The proof is simple and reversible: block the device's MAC address on the router. The traffic to the relay stops within the second. Unblock for a minute: it resumes within the second. One operator did it both ways; it is the clearest confirmation there is, and it needs no capture and no analysis.

7. Acting#

1. Quarantine by MAC address on the subscriber's router, IPv4 and IPv6: the device keeps the local network, loses the internet, the rest of the household is unaffected.
2. Tell the subscriber. They know nothing. Say which device, and that a factory reset is not enough for a box infected before sale: it must be replaced. For a Fire TV Stick, remove the alternative app store and the apps that came from it, or reset. And tell them to change the passwords of every account used on the device, Prime Video, Netflix, Google, and to sign out of its sessions from another device: the box is rooted and remotely controlled, and whoever controls it can read the credentials and session tokens stored on it.
3. Keep session logging on across all equipment: the next report is handled in minutes.
4. Watch or block the relays listed above, by address, and report them to the hosting company (abuse@datacamp.co.uk for AS60068). Three operators have, two of them network-wide from this page alone; one saw other infected homes hit the block within minutes, which makes the block a census.
5. Tell us what you find: brand, model, MAC prefix, and if possible the app at fault. Every device identified goes into this guide and helps the next one. A recovered device can be handed to us for analysis.

Text ready to send to a subscriber, to adapt:

A device connected to your router (a TV box or a streaming stick, MAC address xx:xx:xx:xx:xx:xx) has been identified as part of a proxy network used to attack websites, without your knowledge. We have cut its internet access; the rest of your installation works normally. This device must be removed or reset; if it was bought outside official channels or promises free channels, it must be replaced: it is infected from the factory. As the device is controlled remotely, please also change the password of every account you used on it (video streaming, Google or Amazon account) and sign out of their sessions from another device. We remain at your disposal.

8. What we provide#

• Reports in continuous flow, X-ARF, with time and source port, to your network's abuse contact.
• On request: the history of your network's addresses we have blocked, with times and ports, to cross-check your logs.
• This guide, kept up to date. Relay addresses are leased blocks: what is true today can move; come back to the dated version at the top of the page.
• An attentive ear: everything in this guide comes from operators' answers to our reports. What you write to us, in reply to an abuse report or directly, goes into the next version.

Contact: abusereport@lrob.net, in English or French.

Change log#

• 30 October 2026: a second relay infrastructure outside Datacamp, at Alibaba, Taobao, Zenlayer, BytePlus and Tencent, with its ports (section 2); DNS to three public resolvers at once, relayed IMAP logins, the s1.gmslb.net beacon, the IP-check services and the TCP fingerprint (section 4); a MAC prefix (68:8F:C9, Zhuolian) in section 5. All from one Canadian operator's packet capture.
• 28 October 2026: a MAC prefix (DC:72:23) and a named model, the X88 Mini 14 (Rockchip RK3518) sold on Amazon UK, from a UK operator (section 5); the subscriber must also change the passwords of the accounts used on the device (section 7).
• 26 October 2026: a relay prefix (143.244.35.0/24, Datacamp), a relay address in it (143.244.35.77, port 10045) and a twelfth Amazon MAC prefix (A0:D2:B1), from an operator who verified two cases with this guide.
• 25 October 2026: a third traffic pattern reported by one operator (UDP mesh on port 7649), to confirm, in section 4; two MAC prefixes from the Brazilian case in section 5.
• 22 October 2026: first publication.