Proxynvader: inside the TV-box botnet that attacks websites from its victims' living rooms

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

This article is a living document: it will be completed as the investigation goes on. The change log is at the bottom.

Since the summer of 2026, the sites hosted by LRob, the French hosting company that founded Shieldlist, have been under an attack unlike anything we had seen in fifteen years of hosting: hundreds of thousands of IP addresses a day, one request each, coming from ordinary homes all over the world. Behind each address, an infected TV box or streaming stick, in the living room of someone who has no idea. We have named this network Proxynvader. Here is what we know, how we learnt it, and why, in France, nobody wants to hear it.

The short version#

• A residential proxy network runs on infected consumer devices: cheap Android TV boxes (X96, X98, Superbox, Vseebox, FN-LINK and Earda Wi-Fi modules), but also, and increasingly, Amazon Fire TV Sticks on which someone installed an alternative app store: eleven of the twelve devices found at a single US operator are ones. One operator reports, without being able to confirm it, a General Electric smart appliance.
• The devices act as exit nodes: a relay sends them HTTP requests, they fetch the page and send it back. The targeted sites see millions of residential addresses arrive.
• We measured close to 1.2 million distinct addresses banned on a single online shop between 18 August and 21 October 2026, 2.57 million in 29 hours on a community website, and a continuous wave on our code forge.
• Six operators, five of them abroad, found the devices at their subscribers' thanks to our reports, which carry the UTC time and the TCP source port. The control relays they identified were, until 30 October, all but one hosted at a single hosting company; a Canadian operator's packet capture has since shown a second relay infrastructure, at Alibaba, Tencent, BytePlus and Zenlayer, and the first direct evidence of what the exits are used for besides scraping: testing stolen mailbox passwords.
• The French share is massive: close to 52,000 addresses of Free, Orange, SFR and Bouygues subscribers banned, 37,000 of them in 29 hours during the calendar wave. Close to 5,000 reports sent to those four operators. No answer.
• This is the continuation of BADBOX 2.0, which the FBI warned about in 2025 and again in March 2026. The network signatures to detect the devices are published below, and laid out step by step in the guide Detecting Proxynvader on your network.

1. What we saw#

It all starts on an online bicycle shop running PrestaShop. The faceted search pages ("bikes between 2,000 and 3,000 euros, brand X, 36 per page") start receiving requests by the thousand. Each one builds a complete page, never cached, since every combination of filters is new. The server saturates, not on bandwidth, but on computation.

What made the attack so strange was its shape:

• One or two requests per source address, never more. The address does not come back within the wave. Banning an address therefore does not protect in the moment; it protects over time, because the same fleet serves from one attack to the next: a third of the addresses of the wave on our code forge were already banned since the wave on the shops. Hence long bans, a year, which cut the next waves before they start.
• A constant rate, day and night, going up and down in steps, like a tap being adjusted.
• Residential addresses, in Brazil, the United States, Argentina, Colombia, Mexico, then everywhere: 211 countries, 17,400 networks of origin.
• A counterfeit browser. Every request claims to come from a recent Chrome, but none loads an image, a stylesheet or a script, none carries a Referer, and the TLS fingerprint gives away three client programs in Python and Go, all on the same Linux stack. The devices relay traffic that is not their own.

Measured peak: 390,000 distinct addresses in 24 hours, on 19 August 2026. Another hosting provider, running Magento shops, describes the same campaign on AbuseIPDB with figures ranging from 2 to more than 6 million addresses over the year.

Then the waves moved on to other targets:

• 16 and 17 October: the calendar of a community website running WordPress, 40,000 addresses an hour for 29 hours, 2.57 million addresses banned, plus about 600 servers rented at a large French hosting company. The attack stopped dead, within thirteen minutes, at the moment we began reporting the addresses and refusing the requests instead of serving them; we first credited the reports, and the next wave taught us that the refusal is what counts, see below.
• Since 12 October at least: our own code forge, git.lrob.net, whose history pages (commits, blame, diffs) are being sucked up at 23,000 to 57,000 requests a day. A third of the addresses were already known from the first wave: it is the same fleet.
• 23 and 24 October: the forecast maps of a regional weather site, every combination of map, hour and day requested once, 8,358 addresses in thirteen hours. This wave taught us two things. The fleet adapts within minutes: refused by a gate that demanded a Referer, it came back within the minute with a Referer imitating a click and another User-Agent. And what stops it is not the report: seven minutes after our firewalls began dropping its connections instead of answering, the job stopped, before any of the twelve operators notified could have acted. An HTTP refusal tells it "try another way"; a dropped connection tells it "dead target", and it moves on. What it never did, under any profile, is load the page's scripts and styles: that is how it is recognised.

2. Why a hosting provider ended up writing its own defence#

When the attack began, LRob's servers were protected by a classic intrusion detection system. It gave way, not on detection, on volume. The rate was too much for it: it used more CPU than the attack itself, its bans fell behind, which, on a repeated attack, lets the next wave through, and its unofficial interface stopped syncing. Above all, it handled hundreds of thousands of banned addresses badly: every restart was an ordeal. We needed a tool that convicts on the first request, on its shape and not on its repetition, that holds millions of bans without slowing the server down and restores them in seconds, and above all that reports every address to its operator with what it takes to find the device.

That is why LRob wrote Shieldlist. It is a free application firewall, an agent on each server and a central controller, which reads the logs, convicts on readable rules, shares bans between machines, and sends an X-ARF report to the abuse desk of the network of origin, with the log line, the UTC time and the TCP source port. That last detail is what changed everything.

3. Back to the device: the source port#

A residential subscriber often shares an IPv4 address with others, behind a CGNAT. The address alone designates nobody. But the operator keeps its NAT session logs: with the exact time and the source port, it finds the subscriber, then, on the subscriber's network, the device's MAC address.

Six operators did that work from our reports. We do not name them, their country is enough; what strikes us is that they are often very small ISPs, a rural operator, an apartment-building network, who read their reports and act within hours, where the large ones do not answer. What they found, in short:

• A Chilean ISP: unbranded "pirated" Android TV boxes, old Rokus, Samsung televisions more than nine years old.
• Another US ISP: a device with an Earda Technologies Wi-Fi module (MAC prefix 68:B9:C2, a Guangzhou maker of modules and Android TV boxes), offline at the time of the check.
• A small US ISP: a box sold as a "Chromecast", Wi-Fi module from a Chinese manufacturer (MAC prefix 58:E4:EB), in an idle household; 100 to 136 new outbound connections every 10 seconds. Blocked, the traffic stops within the second; unblocked for a test, it resumes within the second.
• Another US ISP, on three reports and then a sweep of its whole network: twelve devices in eight apartment properties in four states. Eleven carry an Amazon MAC prefix, Android 9, Fire TV type; one is a Shenzhen Cultraview Android TV board. Each device holds one permanent connection to a single relay, on a port between 10,000 and 20,000 that changes every few hours to two weeks. The proxy client is active seven minutes after the device first appears on the network. On 12 October, three devices switched relays at the same minute: the fleet is steered centrally.
• A rural US ISP: a Vseebox, a "free IPTV" box sold online, talking to data centres in China and Russia.
• A US ISP, at the traffic level: "this is not a command-and-control beacon. The relay opens a connection, submits an HTTP request with a spoofed browser User-Agent, the device fetches the page and sends the response back." 72% of the device's requests followed a connection from the relay by less than 100 ms. Then three devices on its network, each with its relay, all at the same hosting company.
• A Ukrainian ISP: "the overwhelming majority of these events come from cheap Chinese Android TV boxes, X96, X98 and similar, pre-infected. This traffic is purely application-level, on standard ports: impossible to filter at the ISP level without cutting the subscriber off. Our only remedy: identify the subscriber from the CGNAT logs and require the box to be removed."
• A US provider of guest networks (hotels, residences): a guest's device, Amazon MAC prefix, blocked by hardware address. A campsite, earlier, had not found the device: the guest had left.
• A US ISP running apartment buildings, reported once so far: the address of a vacant unit, whose only connected device was a General Electric smart appliance (MAC prefix FC:B9:7E, GE Appliances). The ISP could not confirm it was the culprit; it cut all the unit's traffic. If confirmed, it will be the first non-TV device: kitchen IoT.
• A Lebanese ISP, one day after this report was published: from the detection guide alone, it blocked across its whole CGNAT pool the relay and control addresses, TCP 7001 of signature B and outbound TCP 25, logs the attempts, and is contacting the subscribers concerned to have the devices removed. It promises to report new relays and the models found.
• And the first explanation of an infected Fire TV: the subscriber had lent his sticks to a friend, who had installed an alternative app store full of "free" Netflix and Hulu clients. Those cracked apps carry the malware. The subscriber is replacing the sticks with new ones.
• A Brazilian ISP, the first case in IPv6: for a report on our code forge, the /64 prefix turned out to be delegated to a single residential subscriber, identified through the operator's access servers (session open since 14 October, covering the event). The subscriber will be asked to check for Android TV boxes and streaming sticks, "as described in your Proxynvader documentation". Asked which IPv6 hosts control the device, the operator ran its sampled flow data for the /64 over twenty hours: all traffic on TCP 443, single-occurrence destinations spread over hosting providers worldwide, and a handful of destinations recurring over several hours, among them CDN fronts. That is the relayed traffic itself: a proxy exit talks to the sites its customers ask for, and a site scraped for hours recurs as much as a relay would. Nothing in it looks like a control channel, whose IPv4 signature is a permanent connection on a port between 10,000 and 20,000. The likely reason is that the box receives its orders in IPv4, through the CGNAT, and only exits in IPv6: the control channel is to be looked for in the subscriber's IPv4 NAT sessions, which is what we asked next. On the subscriber's router, the operator then found an Android device with a Shenzhen iComm Semiconductor Wi-Fi chip (MAC prefix 84:B4:D2), a chip common in cheap Android TV boxes, and removed it from the network; brand and model are not known yet.
• A Colombian ISP, from one report on our code forge, with the UTC time and the source port: one residential subscriber through the CGNAT logs, and on that subscriber's network a device "taking part in a residential proxy / P2P bandwidth-sharing network: tens of thousands of concurrent connections, a UDP mesh on port 7649 and tunnels on uncommon ports". The operator blocked that traffic at its core router without cutting the subscriber's service, notified the subscriber, and added network-wide detection of the pattern. The UDP mesh is new to us: neither signature A nor B, seen once, on one device; it is in the guide as a pattern to confirm.
• A UK ISP, the day after a report on the shops wave: the device is an X88 Mini 14 (Rockchip RK3518), bought on Amazon UK where it is listed as "Android TV Box 14.0, 4K HDR10, 2 GB/16 GB", Wi-Fi chip from Hui Zhou Gaoshengda (MAC prefix DC:72:23). Sold as Android 14, it announces itself to the router as Android 9, like the Fire TV-type boxes. After AliExpress, the second purchase channel named is Amazon's marketplace. Asked whether anything had been installed on it, the subscriber answered that nothing had: the standard apps were already there. The box was infected as sold, which is what the disk image of section 4 showed. And this one promised nothing illegal: no "free sports and movies", just Prime Video and Netflix in a living room. Whether the box itself is a legitimate product is another question, an unbranded Android TV clone rarely is; but the subscriber bought it and used it as an ordinary player, and the idea that only people who go looking for a pirate box end up in the fleet does not hold.
• A Pakistani ISP, the day after a report on the shops wave: the subscriber found through the CGNAT port-block logs, a bridged CPE with "most likely an infected Android TV box" behind it, the subscriber being contacted. And, from the guide alone, the relay prefixes, the control servers and the TCP 7001 set blocked network-wide on its access routers: "within minutes the block was already dropping connection attempts from other subscriber devices", which the operator is now identifying one by one. The block list doubles as a census of the infected homes, which is what we hoped it would do.
• A Canadian ISP, the same day as the report: the richest answer so far, a packet capture on the WAN side of the subscriber's router, three and a half minutes long. The device is an Android TV box with a Zhuolian (Shenzhen) Communication Wi-Fi module (MAC prefix 68:8F:C9); the operator is working with the subscriber to find and remove it. In those three and a half minutes: 708 outbound connections to about 400 addresses and 350 different site names, shops, forums, sports and news sites worldwide; fifty-two IMAP logins to a Canadian mail provider, and others to German, French, American and Microsoft mailboxes, relayed through the box, which is what testing stolen passwords looks like from the outside; every DNS name sent in the clear to 8.8.8.8, 1.1.1.1 and the Chinese resolver 223.6.6.6 at once; and the box checking its own public address over and over through six "what is my IP" services. The TCP fingerprint of the connections is the one we had measured from our servers a month earlier, a Linux stack with a 65535 window, now seen from the device side. The relay sends the box raw TLS handshakes for the sites to fetch: the box relays bytes, the encryption is between the proxy's customer and the target, which is why we see Python and Go clients under a TV box's TCP stack. And none of the relays were the ones we had published: this box talks to Alibaba, Tencent, BytePlus, Taobao and Zenlayer servers, on a long-lived port 14101, on port 9000 with a 12-byte frame header, and on a handful of low ports carrying encrypted heartbeats. A second relay infrastructure, detailed in section 5 and in the guide. One more thing: every thirty seconds, the box resolves s1.gmslb.net, the control domain of Popa, the proxy plugin of the Vo1d botnet documented by Qurium and Brian Krebs in June 2026, and that name resolves to the same ten servers as the control domain of the firmware backdoor in the box we dissected in section 4.

4. Inside a box#

We were able to analyse the storage of an infected box: an unbranded Android TV box, Rockchip RK3228 processor, firmware from a manufacturer "HX", pre-installed IPTV apps (Magis TV, Latino TV). Stacked inside:

• a factory backdoor in libandroid_runtime.so, at the firmware level, able to install silently;
• ad-fraud modules;
• an Android.Pandora, of the Mirai family, dormant, downloaded from a French server;
• and the proxy node itself, a daemon named gomediad, which connects on port 80 to thirteen servers of a single hosting company and keeps a WebSocket "backconnect" channel through which the requests to relay arrive.

All of it with adb open on the network, no password, as root. In other words, a device entirely controllable from afar, on the same Wi-Fi as the household's computers, phones and connected objects. The proxy is only the visible use.

This is the exact profile of BADBOX 2.0 as described by HUMAN Security: devices infected before sale, a loader at the firmware level, several monetisation "schemes" stacked up, the residential proxy among them. And it has a name on the other side of the world: the backdoor's control domain, ycxrl.com, resolves to ten servers at Leaseweb and Hurricane Electric, and those same ten servers answer for s1.gmslb.net and lb.gmslb.net, the control domain of Popa, which Qurium and Brian Krebs described in June 2026 as the proxy plugin of the Vo1d botnet, feeding the residential-proxy provider NetNut, with one and a half to two and a half million addresses a day. A Canadian operator saw an infected box on its network query that very name every thirty seconds (section 3). The loader in our box and the beacon in theirs share one backend. We write it as what it is, a verified DNS fact, and leave the attribution of the proxy traffic itself to those who can see the relays from inside. And it is the profile of the Superbox described by Brian Krebs in November 2025, and of the boxes that Kimwolf has been recruiting by the million since late 2025 through residential proxy networks. None of this is a succession of separate cases. It is a single attack base: the same factories, the same supply chains, the same proxy vendors, different customers renting the exit.

5. How it works, seen from the server and from the home#

A job-based residential proxy network. The network's customer, here a program scraping shop catalogues at scale, sends its requests to a gateway. The gateway hands them out to thousands of devices, each executes one or two, and sends the response back. For the targeted site, each request comes from a different home, with a fresh address. For the home, it is a box that "downloads a bit". The box is used as a plain HTTP proxy: on port 80, some of its requests reach us in the absolute form a client only sends to a proxy, GET http://site/page HTTP/1.1, forwarded as received from the gateway. The same home relays again weeks later with a different browser signature each time: the User-Agent is the gateway's, chosen per job, not the device's.

Two network signatures, measured by the operators, let any ISP find these devices without inspecting content:

• Signature A, the job channel: a permanent TCP connection from a device to an address at a relay hosting company, on a port between 10,000 and 20,000, the port rotating every few hours to two weeks, the address fixed for months. Prefixes seen: 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, a second component: TCP 7001 connections held in parallel to a fixed set of 22 servers at Oracle Cloud and DigitalOcean. Five devices out of nine carry it without signature A: it is another component, on the same class of devices, whose role is not established yet.
• The volume: 3,000 to 20,000 distinct destinations a day where a household has a few dozen; up to a million connections a day for a single box.

Until 30 October, every control relay reported by the operators was hosted at Datacamp Limited (AS60068, brands CDN77 and DataPacket), in at least six US sites, except one controller at Hivelocity (AS29802) and secondary channels at Blazing SEO (AS397630), a proxy vendor, and DigitalOcean (AS14061). A Canadian operator's capture then showed a second relay infrastructure, with no Datacamp address in it: long-lived connections on port 14101 to Alibaba (AS45102), Taobao (AS24429) and Zenlayer (AS62610) servers, framed tunnels on port 9000 at Zenlayer, and control-like channels on low ports (119 to 263) at Alibaba, BytePlus (AS150436) and Tencent (AS132203). Same device class, same job-channel shape, other hosts: either a second proxy vendor loading on the same boxes, or the same vendor's other pool. Both are in the guide. The second component (TCP 7001) runs on 22 servers at Oracle Cloud (AS31898) and DigitalOcean. We write this as a fact from logs, not as an accusation: a hosting company rents servers, and three operators have reported its relays to it, the last one on 26 October with the relay's address and port. To our 310 reports, its abuse desk answers with an automatic acknowledgement: "unmanaged server provider, forwarded to the relevant customer". No known follow-up: the relays are still there.

In IPv6, the only observation to date (a Brazilian operator's sampled flow data for one infected prefix, section 3) shows exits only, all on TCP 443, and no control channel: the device most likely takes its orders in IPv4, through the CGNAT, like the others.

What the exits are used for. Scraping our sites is what we see; it is not all. In the Canadian capture, a fifth of the box's connections in three and a half minutes were IMAP logins to mail providers, fifty-two of them to a single Canadian one: someone was testing mailbox passwords through a Canadian home, so that the mail provider sees a Canadian subscriber log in. The American device of section 3 tried TCP 25 twelve thousand times a day. Account takeover and spam ride the same boxes as the scrapers.

6. How big?#

We only see what hits our servers. What we measured, distinct addresses banned by this fleet's rules:

An address is not a device: a residential address changes, a shared one hides several. But more than a million distinct addresses in twenty-four hours, against a single site, is the order of magnitude of the fleet this operator can mobilise at once. For comparison: BADBOX 2.0 counted more than a million devices; Kimwolf, according to Synthient, two million devices and twelve million addresses a week; a proxy botnet on Windows and macOS described by Gridinsoft in July 2026 counted 400,000. Another hosting provider, on Magento shops, saw more than six million addresses of the same campaign over the year. The fleet behind Proxynvader counts in millions of devices, and what we see is only a part of it.

Who sells these exits? For the calendar wave, and for it alone, we have a name: Kookeey (kookeey.net, a Hong Kong company). Here is how we got there, by cross-referencing public OSINT sources, and with the care this demands. Among the some 600 OVH servers relaying the attack, we studied one: the technical profile recorded by Shodan and by our own measurements (every port from 1 to 10,000 open on a mute daemon, a default web server, a VPS with its default name) is that of a proxy gateway, and about a third of the 600 servers show the same profile. The Spur database, which classifies addresses by their observed use, labels that gateway "KOOKEEY_PROXY, Callback Proxy". The provider's profile at Synthient describes it as a high-risk residential proxy reseller, supplied by a proxyware SDK embedded in applications, with a pool made of 63% Brazilian and 10% Argentinian addresses. And the addresses attacking us were first Brazilian and Argentinian, home routers and phones. Three independent sources agreeing on an address, a geography and a way of operating; but a single labelled gateway, and public profiles. It is a correlation, not a proof: only OVH, or an investigation on those machines, could say which customer rented them, and we do not write it for the shops wave, where nothing of the kind was observed.

What Kookeey sells, in plain words, is what we suffer. The site advertises a "47 M+ Residential IP Pool" in 190 countries, 6.9 million addresses in Brazil, 2.5 million in the United States and 1.8 million in India, and "mobile" proxies in the same number. One buys traffic by the gigabyte, around ten yuan, a little over one euro, drawn from the pool of a country of one's choice, a million US addresses for instance, with a new address at every request, over SOCKS5, HTTP, Vmess, Shadowsocks or WireGuard. The pitch: "clean IPs", data collection, SEO, ad verification, social media account management. Nothing on where the addresses come from, nothing on the consent of those who provide them. That is the market: people's devices, resold by the gigabyte, to whoever asks.

7. Why "Proxynvader"#

BADBOX 2.0 is the name HUMAN Security gave to the 2025 operation. What we see in 2026 is its continuation, and the difference that matters: no longer only unbranded pre-infected boxes, but also brand-name devices, infected by what gets installed on them. The name had to say the object of the offence, a proxy, and the intrusion into the place of someone who asked for nothing, home, office, hotel or campsite. Proxynvader, the proxy that invades. The waves keep their technical names: facet flood for the shops, calendar flood for the calendars, forge crawl for the code forges.

8. France: thousands of reports, no answer#

Every French address we ban gets a report to its operator's abuse desk: the log line, the UTC time, the source port. Everything needed to find the subscriber and tell them that a device in their home is working for others.

Distinct addresses banned since 18 August, reports sent since 20 September, as of 21 October 2026; reports are capped per network and per day, hence the gap. The curve of these four operators' addresses: 2,081 in the week of 21 September, 1,371 the next, 40,167 in the week of 12 October, 37,273 of them for the calendar wave alone in 29 hours, then 8,215 from 19 to 21 October, four times a late-September week in three days. 98% of these addresses were banned since 1 October. Other attacks coming from French residential addresses, SQL injections and probes, overlap this fleet for 10 to 30% of their addresses: a part comes from it, not the bulk. Six foreign operators found and neutralised the devices from the same reports. The four French ones did not send an acknowledgement. Meanwhile, the French share grows week after week, and legitimate subscribers find their address blocked on online shops, sometimes because a neighbour on a shared IPv4 address hosts the box.

We wrote to the CERTs, to ANSSI, the national cybersecurity agency. ANSSI answered, courteously, that this falls outside its remit, and pointed us to a platform for reporting illegal content that has no box for "mass infection of devices". We do not blame them: their perimeter is what it is. But we ask the question publicly, since nobody takes it privately: who, in France, receives the alert when tens of thousands of French homes serve as relays for a worldwide attack? The operators are operators of vital importance. Their subscribers host, unknowingly, devices controlled from abroad. The evidence is there, dated, sourced, and preserved.

This article exists for that too. From today on, nobody can say they did not know.

Who answers, who does not#

This list will be kept up to date. It does not judge the size of a network or how many infected devices it has, nobody can help that; it says who reads its reports and acts.

9. What to do#

If you are an operator#

1. Apply the two signatures above to your NetFlow and NAT session logs; the guide for operators gives the method, the relay addresses and the MAC prefixes, ready to copy. A US operator did it on its whole network and found nine more devices in a day.
2. Notify each subscriber concerned, individually, and ask for the device to be removed or reset. Block its MAC address on the router meanwhile.
3. Read your abuse reports. An X-ARF report with time and source port is handled in minutes.
4. Blackhole the known relays, and report them to their hosting company. The list is available on request, and will be published here.
5. Collect devices for analysis, and share: every model identified helps the others.

If you own a TV box or a streaming stick#

The FBI published a dedicated alert in March 2026, Evading Residential Proxy Networks, which says the essential:

• avoid boxes that promise "free sports, shows and movies";
• do not install alternative app stores or apps from outside the official stores, especially on a streaming stick or an Android TV box;
• a pre-infected device stays infected after a factory reset; the only remedy is to replace it;
• once it is out, change the password of every account you used on it, Prime Video, Netflix, Google, Amazon, and sign out of their sessions from another device: the box is rooted and controlled from outside, and whoever controls it can read what it stores, passwords and session tokens included;
• look at the list of devices connected to your router: the one that is active day and night, TV off, is the one.

And do not think a box is safe because you only use it for Prime Video and Netflix: the X88 Mini 14 found at a UK subscriber in October promised nothing illegal, had nothing installed on it, and came infected from the factory. What protects you is not what you watch, it is where the box comes from: an unknown brand on a marketplace is a risk in itself, whatever the listing says.

And if your address ends up blocked on a site, look for the device before asking to be unblocked: it will start again elsewhere.

If you host websites#

• Answer these requests before the application: a facet page requested without a Referer and without a session cookie can get a 429 from the web server itself, without computing anything.
• Convict on the first request on its shape, not on repetition: there is no second request.
• Report every address to its operator with the UTC time and the source port. It is long, it is thankless, and it is the only thing that, so far, has got devices removed.
• If you want a tool that does all of this, Shieldlist is free software, and it was written for this attack.

10. A call for coordination#

This attack has no centre that could be taken down in one go: factories, proxy vendors, relay hosts, millions of homes. But it has a weakness: every device sits at a subscriber of an operator, and every operator can find it in minutes with the signatures published here. If ISPs coordinate, the attack goes out. If they do not, each one can still put it out at home, one subscriber at a time. Nine already have, one of them from the guide published here alone, the day after it appeared. The data is available to any operator, CERT or researcher who asks.

Sources and references#

• HUMAN Security, Satori Threat Intelligence Disruption: BADBOX 2.0 (2025)
• FBI / IC3, Home Internet Connected Devices Facilitate Criminal Activity (June 2025)
• FBI, Evading Residential Proxy Networks: Protecting Your Devices from Becoming a Tool for Criminals (12 March 2026)
• Brian Krebs, Is Your Android TV Streaming Box Part of a Botnet? (November 2025), The Kimwolf Botnet is Stalking Your Local Network (January 2026) and 'Popa' Botnet Linked to Publicly-Traded Israeli Firm (June 2026)
• Qurium, Finding "Popa": When Your Smart TV Stops Being Yours (June 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
• Wikipedia, Ipidea, one of the largest residential proxy networks
• Shieldlist, the project and its code

Change log#

• 30 October 2026: a fourteenth operator, in Canada, with a packet capture of an infected box: a second relay infrastructure outside Datacamp, relayed IMAP logins, the TCP fingerprint confirmed from the device side (sections 3 and 5); the box's control domain is Popa's, and it shares its servers with the backdoor of the box we dissected (section 4).
• 29 October 2026: a thirteenth operator, in Pakistan, blocks the relays network-wide from the guide and sees other infected homes hit the block within minutes (section 3); the box used as a plain HTTP proxy, the User-Agent chosen per job (section 5).
• 28 October 2026: a twelfth operator, in the United Kingdom, and a named model bought on Amazon (section 3).
• 26 October 2026: an eighth relay prefix, reported and verified by an operator with the guide (section 5 and the guide).
• 25 October 2026: an eleventh operator, and a third traffic pattern to confirm (a UDP mesh on port 7649), in section 3 and in the guide.
• 24 October 2026: the fourth wave (weather maps), what stops a wave and what does not; a tenth operator, the first IPv6 attribution and the first IPv6 flow data (sections 3 and 5).
• 23 October 2026: the fleet's size (section 6), the market for residential exits, a ninth operator.
• 22 October 2026: first publication.