Google bans Videostrong after XCPE disruption, but infected TV boxes still need remediation

Google acts against the supplier and command infrastructure

Google disclosed on November 2 that it had disrupted XCPE, a botnet that enrolled more than 1.3 million set-top boxes. It attributes the operation with high confidence to manufacturer Videostrong, rather than merely describing criminals exploiting the company's products. Google places the disruption in the preceding week without specifying an exact operation date. The disclosure therefore documents an earlier intervention, not a separate November 3 takedown. [1]

The measures include legal action against XCPE infrastructure and affiliate command domains, exclusion of Videostrong and future subsidiaries or affiliates from Google's certified-device ecosystem, and changes to certification reviews. Google says malicious code evaded testing and loaded after first boot. Those actions address infrastructure access and supplier oversight, but TrendAI's research makes the remaining limitation explicit: disrupting servers does not remove the implant from equipment already sold. [1][3]

Device totals, residential addresses and wider impact are different measures

TrendAI observed 1,472,554 devices across 206 models between June 3 and October 1, 2026. Collection was intermittent, and the company explains that partners' totals vary with observation periods and visibility. Its separate count of 3,849,226 residential exit IP addresses must not be read as another 3.8 million infected devices or households. These measurements describe a large, globally distributed operation without establishing one definitive count for every point in time. [3]

Google also assesses that action against affiliate infrastructure potentially severed access to at least 10 million additional compromised devices beyond XCPE. That is a projected effect on access, not a verified number of cleaned endpoints. Geographic reporting also differs: TrendAI reports more than 170 countries, while The Register reports more than 200. The defensible synthesis is broad international exposure, with important limits on the precision and comparability of the published totals. [1][3][6]

Firmware control turned household connections into proxy capacity

Plume describes a system-privileged Android agent that retrieves remote configuration and maintains an MQTT command connection. Its analysis traces a progression from device management to remotely controlled monetization. Google's findings explain why ordinary application removal is insufficient: the firmware preload remains and reinstalls the application on reboot. Together, these observations show why loss of a command server and restoration of device integrity are separate outcomes. [1][7]

Affected equipment is not confined to one certification category. Plume mapped both Android Open Source Project and Google-certified devices, including equipment supplied through partners. Synthient directly examined a purchased MECOOL KM9PRO Max, but its repository warns that an observed model name alone does not establish compromise. Model strings can guide an investigation; they are not a blanket recall list or proof that every unit bearing a listed name is infected. [4][7][8]

The devices supplied residential-proxy capacity, allowing other parties to route traffic through owners' internet connections, and supported advertising fraud and additional malware. KrebsOnSecurity connects this activity to a wider proxy market associated with account takeover and other abuse. That context does not establish who purchased this fleet's capacity: TrendAI says it did not observe specific buyers and offers no evidence of nation-state use. [2][3]

Technical evidence supports attribution, with limits on independence

Synthient's attribution evidence extends beyond a product label. It reports finding a document signed by Videostrong's R&D director in a directory on malware-hosting infrastructure, an operator administration endpoint sharing an IP address with Videostrong's domain, and Videostrong email addresses in backdoor-signing information. These links support Google's assessment, but corporate responsibility remains an attributed technical finding, not a judicial conclusion established by the available material. [1][4]

The research supplies distinct forms of corroboration: Synthient examined purchased hardware, Plume analyzed firmware and management channels, and TrendAI measured the observed fleet. Those contributions strengthen the evidence that the operation existed and explain how it worked. However, the researchers participated in a coordinated effort, so their publications should not be treated as fully independent confirmations of every attribution or impact claim. [3][4][7]

Independent reporting adds interviews, context and response-seeking rather than a second measurement of every headline number. Krebs interviewed Synthient's founder, while The Register sought Videostrong's response and received none before publication. Repetition of Google's attribution in those reports is not additional technical proof, and the absence of a company response does not resolve the attribution question. [2][6]

Conflicting reset advice makes isolation the conservative choice

The cleanup recommendations materially disagree. Plume recommends a full factory reset, citing the possibility that modules installed additional backdoors. Synthient recommends disconnecting and permanently disposing of affected devices. TrendAI says owners cannot themselves remove the manufacturer-signed system implant and that remediation requires vendor action, platform protection or replacement. A reset therefore cannot be presented as a verified universal cure. [3][4][7]

Our inference from the documented persistence and conflicting guidance is that confirmed affected equipment should remain isolated, with replacement the conservative option unless trustworthy, device-specific remediation is validated. This is a risk-management recommendation, not an announced universal recall. Google's finding that the preload survives application removal is the central reason not to equate a successful uninstall with restored trust. [1][3][4]

For organizations, Synthient recommends inventory checks, blocking published malicious infrastructure and separating remaining IoT equipment from sensitive networks. Inventory work should respect the repository's model-name caveat rather than automatically condemning every matching product. Blocking and segmentation can contain exposure, but neither demonstrates that the firmware is clean or substitutes for resolving the status of a confirmed infected endpoint. [4]

Recovery needs device-level evidence, not another disruption total

The next consequential development would be validated remediation tied to specific hardware and firmware, together with evidence that disrupted control channels remain inactive. These are criteria for assessing recovery, not outcomes established by the current announcements. Further reporting should also separate measured endpoint cleanup from Google's projected disruption of access through affiliate infrastructure. [1][3][7]

Videostrong's response and details of Google's revised certification reviews also matter. The immediate distinction remains clear: researchers have documented a large firmware-backed operation and action against its infrastructure, but they have not demonstrated that millions of devices are now trustworthy. Owners and network administrators should judge subsequent claims against that unresolved endpoint problem. [1][3][6]