Google and six partners, including carrier Lumen, have dismantled XCPE, a botnet of more than 1.3 million Android TV boxes that, according to Google Threat Intelligence Group (GTIG), their own manufacturer, Videostrong Technology Co., turned into an ad-fraud and residential-proxy business. The report, published on November 2, 2026, describes a problem ISPs know well: home devices that the customer can’t clean, with traffic that reaches the internet carrying the access provider’s own IP address.
The XCPE botnet for ISPs in 30 seconds
- More than 1.3 million Android TV boxes shipped from the factory with a backdoor attributed to Videostrong.
- Access was sold to third parties, who installed up to three residential-proxy SDKs on the same device.
- Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI all took part.
- Google estimates that taking down the affiliates’ domains cuts off access to another 10 million devices.
- Behind a CGNAT, a single infected device can damage the reputation of a shared IP address.
According to GTIG, the backdoor came preloaded in the system partition of the set-top boxes, with system-level privileges, and reinstalled itself after every reboot from the /oem/ partition. Google states, with high confidence, that Videostrong, an OEM (Original Equipment Manufacturer) and ODM (Original Design Manufacturer) of Android devices, developed and exploited the botnet intentionally. The full technical breakdown of the persistence mechanism, the three-stage architecture, and the published indicators is in OpenSecurity’s article on the XCPE botnet.
Google’s response combines legal and platform-level action. The company has moved to take down the domains and servers Videostrong used to control the botnet, along with the command-and-control (C2) domains of more than a dozen malware families that were loaded as modules. It has also cut ties with the manufacturer, banned it from building certified Android devices or supplying software to other certified manufacturers, and announced changes to firmware-integrity verification for certified Android TV devices. Videostrong had used obfuscation to exploit a gap in certification testing and load the code after the first boot.
An exit node in the customer’s living room
The business model explains why this case affects infrastructure well beyond the device itself. According to the report, Videostrong sold access to criminal affiliates, who loaded their own modules onto the devices: ad fraud, silent enrollment in residential-proxy networks, and the installation of further malware. Google identified around a dozen residential-proxy and bandwidth-sharing SDKs, and cases where as many as three coexisted on the same device. GTIG adds that silent enrollment, without user consent, remains the most common way devices get turned into exit nodes.
For a cloud provider, an e-commerce platform, or an authenticated service, that traffic doesn’t come from data-center ranges that are easy to filter — it comes from home-ISP addresses shared with legitimate customers. Google’s report describes ad fraud, data exfiltration, and the routing of malicious traffic through the devices. That’s why companies that block or score traffic from residential proxies face a delicate trade-off: tightening the filter on a residential IP can shut out real users who have nothing to do with the abuse. cloudnews.tech already covered this pressure in its report on the connected home as ammunition for botnets and proxies against the cloud.
The figure of 10 million deserves a precise reading. These aren’t XCPE devices, but devices compromised by the affiliates through distribution channels other than this backdoor. Google estimates that taking down those affiliates’ C2 domains cuts off access to at least that many additional devices.
CGNAT, IP reputation, and network detection
Alejandro D’Egidio, head of special projects at CABASE (the Argentine Internet Chamber), has laid out the operator’s-side reading in a LinkedIn post. According to D’Egidio, behind a CGNAT (Carrier-Grade NAT, the carrier-scale address translation that lets many subscribers share a single public IP) a single infected device can get that address added to blocklists, affecting hundreds of customers. He also notes that the user can’t clean something that lives in the firmware, so asking them to fix it on their own doesn’t work.
His proposal for ISPs (Internet Service Providers) is to review flows against the C2 infrastructure that has been made public. NetFlow or IPFIX (IP Flow Information Export, the IETF standard derived from NetFlow) exports let operators cross-reference subscriber connections against the indicators Google published. These include the MQTT broker mqtt.szbboys[.]com on ports 3885 to 3887, the addresses 219[.]134[.]163[.]210 and 219[.]134[.]163[.]211 that hosted it, and the servers 23[.]94[.]49[.]57 and 38[.]145[.]197[.]135, used for file hosting and as C2. The domains, such as subdomains of anyevonline[.]com, also require cross-referencing DNS logs, since a flow record only shows IP addresses.
That list has an expiration date. The report itself warns that once a piece is dismantled, the operators behind these networks quickly swap in a new loader or monetization SDK, and documents that since August 2026 the botnet was already replacing its loader with new installers. The indicators are useful for locating affected devices now, but they don’t replace ongoing monitoring of anomalous outbound traffic.
Notify the customer, and share intelligence between operators
D’Egidio’s second idea is procedural: notify the customer instead of simply blocking, and share intelligence between operators. Blocking without notice leaves the subscriber with a degraded service and no explanation, while notification lets them disconnect the device and replace it — the only real fix when the code lives in the firmware. Google, for its part, encourages mobile platforms, ISPs, and online marketplaces in its report to keep sharing intelligence and apply best practices to identify backdoors and illicit proxy networks.
The operation itself is an example of that cooperation. Alongside Google, Japan’s National Police Agency, carrier Lumen, HUMAN Security, Plume, Synthient, and TrendAI all took part. Google is also asking distributors and retailers to require independent security audits from ODMs and pull implicated manufacturers from their catalogs, and asking the proxy industry to back up any claim of ethically sourced traffic with transparent, auditable proof of consent.
The case doesn’t come out of nowhere. On June 5, 2025, the FBI warned, through the IC3 (Internet Crime Complaint Center), about BADBOX 2.0, a botnet of IoT devices infected before purchase or during setup and used for residential-proxy services. On July 17, 2025, Google sued its operators in New York and put the network’s size at more than 10 million uncertified devices based on AOSP (Android Open Source Project). GTIG doesn’t present XCPE as part of BADBOX, though it notes that two of the modules it loaded, Moyu and Bird, had already been seen in that scheme.
Frequently asked questions
Why does XCPE affect telecom operators?
Because the infected set-top boxes worked as residential proxies, and their traffic went out carrying the home ISP’s own IP addresses. Behind a CGNAT, that IP is shared by many customers.
How can an ISP detect devices infected by XCPE?
By cross-referencing NetFlow or IPFIX flow logs and DNS records against the command-and-control infrastructure Google published, such as the MQTT broker on ports 3885 to 3887 and its associated IP addresses.
Who is behind the XCPE botnet?
Google attributes the backdoor and the botnet, with high confidence, to Videostrong Technology Co., an Android device manufacturer, and states that it acted intentionally for financial gain.
Is it enough to just block the affected IP?
No — it doesn’t fix the source, because the malware lives in the firmware and reinstalls itself. Alejandro D’Egidio (CABASE) proposes notifying the customer so they remove the device, instead of simply blocking it.
Sources:
- Google Threat Intelligence Group: Shutting the door on the XCPE botnet
- OpenSecurity: Google dismantles XCPE, the factory-installed botnet in 1.3 million Android TV boxes
- Alejandro D’Egidio (CABASE) on LinkedIn
- FBI / IC3: Home Internet Connected Devices Facilitate Criminal Activity (06/05/2025)
- Google: We’re taking legal action against the BadBox 2.0 botnet (07/17/2025)
- BleepingComputer: Google disrupts million-device XCPE Android malware botnet
This article is also available in Spanish: «La botnet XCPE pone a prueba a los operadores: CGNAT, NetFlow y proxies», on revistacloud.com.

