XCPE Botnet: Google Blames Videostrong for 1.3M Android TV Boxes

Google says the XCPE botnet was built by Videostrong, an Android device maker that preloaded a backdoor into its own firmware and rented more than 1.3 million set-top boxes to ad-fraud and residential proxy operators. For Cyprus hotels, clinics, casinos and retailers running white-label Android screens, the risk sits below the app layer, in firmware that uninstalling will not clean.

What did Google dismantle, and who does it blame for the XCPE botnet?

Google and six partners have disrupted XCPE, a firmware-level backdoor that had enrolled more than 1.3 million set-top boxes into a botnet. Google assesses with high confidence that the backdoor and botnet were “intentionally developed, deployed, and operated for financial gain” by Videostrong Technology Co., an Android original equipment manufacturer (OEM) and original design manufacturer (ODM).

That is Google’s attribution, not a court ruling, but it is an unusually direct one: the company names the factory, not a hacker group. Google rules out a rogue employee or a coding mistake. The backdoor appears across many device models and brands over several years, ran on dedicated infrastructure, and its configuration changed regularly. That looks like a product line, not an accident.

The partners were Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI. Google’s own response went well beyond a report:

• It cut all ties with Videostrong and banned it from building devices with pre-installed Google apps. The ban covers future subsidiaries and business partners, and Videostrong can no longer supply software to other certified device makers.
• It took legal action against the domains and servers controlling the botnet, and against the control domains of more than a dozen malware families distributed through XCPE. The courts and jurisdictions have not been disclosed.
• It changed its review process and is improving firmware checks for certified Android TV devices.

Google also estimates the action cuts operator access to at least 10 million further compromised devices. That figure is broader because the affiliate malware families also spread through channels other than XCPE, so it should not be added to the 1.3 million.

How did a certified Android TV box ship with a backdoor?

The backdoor passed Google’s compatibility and security testing because it was obfuscated and only loaded after the device’s first boot. Certification examines the build; XCPE stayed quiet until the box was in a customer’s hands, and Google’s tests missed it.

The business model, according to Google, was simple: “Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices.” Those modules did three jobs: ad fraud, enrollment in residential proxy networks, and installation of further malicious software. In Google’s words, Videostrong “prioritized illicit post-sale recurring revenue over the safety and privacy of its users.” The box was sold once, then billed out to criminals for years.

The ODM angle matters for buyers. An ODM designs and builds devices that other companies sell under their own names. A procurement team in Limassol or Nicosia can buy a branded signage player or hotel TV box without ever seeing the name Videostrong on the invoice.

Google makes the same point, arguing that “downstream hardware brands, white-label resellers, telecommunications providers, and online e-commerce marketplaces also share responsibility for closing this vector.” It wants retailers and distributors to require independent security audits from manufacturers. If your supplier cannot tell you who made the board and the firmware, you cannot rule XCPE out.

What can the XCPE backdoor do once it sits on your network?

XCPE gives its operators near-complete remote control of the device, and its design makes it hard to remove. The malware works in three stages:

1. Backdoor: x.cpe (named com.oemservice in some builds), preloaded in firmware and running with system privileges.
2. Loader: com.abc.nexus, which carries its own anti-analysis tricks and sets up the monetization modules.
3. Affiliate modules: the paying customers’ code, either built into the backdoor, added to the loader as packages, or downloaded later on command.

Uninstalling does not stick. If a user removes the backdoor, it reinstalls itself from the device’s /oem/ partition at the next reboot. Downloaded modules can be deleted, but the privileged first stage lives in firmware and brings everything else back.

Command and control runs in two steps. The box first makes an HTTP request to fetch its settings, location data and network information. It then holds a persistent connection to an MQTT broker, a lightweight publish-and-subscribe messaging protocol, to receive orders. Every sample Google analyzed talked to the same broker.

Network traffic suggests operators ran that infrastructure through remote interfaces and an EMQX web console, connecting from IP addresses outside the infected-device network. Most payloads were hosted as GitHub releases on operator-owned accounts, with the rest on operator servers and file-sharing services including Filemail.

The capability list is straight out of a pentest implant: install apps, run commands and scripts, take screenshots, record keystrokes, map the local network, open remote command-line sessions, and disable Google Play Protect’s app verification to install software unnoticed. Google saw operators use most of these, including theft of account data, device data, app lists and system logs. Day to day, though, they mostly installed, removed and managed modules.

The configuration shows a managed operation. MQTT messages carry per-module resource limits, download links per processor type and priority weights. Devices are sorted into six timezone-based pools and report bandwidth use and alarms, so modules stay within budget.

For a business, two things follow. A residential proxy module makes strangers’ traffic leave through your public IP, so fraud, credential stuffing and abuse complaints get traced to your office, hotel or clinic. And a box with network mapping and a remote shell is a foothold on whatever segment it shares.

Which hardware and proxy kits turned up beyond set-top boxes?

Most infected hardware was Android TV set-top boxes, but Google also found XCPE on telehealth devices, karaoke machines and digital signage. That list maps directly onto Cyprus businesses: clinic waiting-room and patient-facing kit, hospitality entertainment, betting-shop and casino screens, retail displays and boardroom TVs.

Infected devices were oversubscribed. One box could run several modules at once, including up to three residential proxy kits. The proxy and bandwidth-sharing kits named in the report are Linkfog, AppSalt, GaGaNode, BWM, Traffmonetizer, EarnFM and NetNut.

Consent was not part of the deal. AppSalt’s SDK, owned by Honeygain, calls an opt-in function without ever showing a consent screen, and it stops running if the host app came from the official Google Play Store. That last detail suggests the SDK was built to behave itself where someone might be watching. Google says silent opt-in remains the most common way devices become proxy exit nodes.

On the ad-fraud side, modules called Fission and HiddenView fire fake ad impressions in the background. HiddenView also opens hidden browser windows to simulate clicks and scrolling. A signage player doing this burns bandwidth and CPU that its owner pays for.

What should a Cyprus firm check this week?

Inventory every Android-based appliance on your networks and treat any unverified one as untrusted firmware:

• Find the hardware. List Android TV boxes, signage players, karaoke units, kiosks and telehealth devices, including guest-area and branch kit that IT never bought. Ask each supplier who manufactured the board and firmware.
• Check package names on devices you own. Look for x.cpe, com.oemservice and com.abc.nexus, unexpected contents in /oem/, and disabled package verification. Take indicators of compromise from Google’s report, not secondhand lists.
• Capture evidence, then reflash or replace. Record installed packages, running processes, active connections, DNS history and firewall logs first. Do not treat uninstalling or a factory reset as cleanup; accept only a vendor-verified clean firmware image or new hardware from a known manufacturer.
• Hunt the behavior, not the port. Look for an HTTP configuration fetch followed by a long-lived MQTT session, then download bursts and sustained outbound proxy traffic. MQTT usually runs on TCP 1883 or 8883, but neither port nor TLS is mandatory. Blocking GitHub outright is rarely practical; use URL and repository telemetry instead.
• Segment. Put screens and media boxes on their own VLAN with outbound allowlists, and alert on connection attempts toward payment, clinical or trading systems.

From our own internal network tests: lobby TVs and signage players regularly sit on the same flat network as staff laptops and point-of-sale terminals, installed by a fit-out contractor and missing from the asset register. Nobody owns them, so nobody patches or monitors them. XCPE lives in exactly that gap.

For regulated firms the paperwork follows the hardware. NIS2 and DORA both expect an asset inventory, logging, incident handling and ICT third-party risk management, and an unmanaged Android device on a corporate or customer-facing network falls inside that scope.

If a suspect box shared a segment with personal or payment data, run your incident assessment and decide on notification under NIS2, DORA and GDPR rather than assuming a proxy-only infection is harmless. Write firmware provenance and audit rights into procurement contracts for connected devices; our NIS2 penetration testing work increasingly covers that supplier evidence alongside the technical findings.

Is the XCPE backdoor still active after Google's takedown?

The command infrastructure has been disrupted, but the backdoor still sits in the firmware of devices already sold. Losing the central MQTT broker stops new orders; it removes neither the first stage nor modules already installed. A quiet device is not a clean one.

Operators will try to rebuild. Google describes backdoor makers, ad-fraud rings and proxy providers as one interconnected supply chain that switches quickly to new loaders or rival kits when a link breaks.

Several points remain open in the public reporting:

• No complete list of affected models, brands or resellers has been published, which is the detail buyers most need.
• The courts, jurisdictions and legal grounds for Google’s action are not stated.
• The reporting includes no response from Videostrong.
• Google has not published a geographic split for the 10 million figure, so any European share is unknown.

Until that model list exists, check every white-label Android appliance without clear manufacturer provenance. Testing those devices directly, covering both firmware and cloud interfaces, is what IoT device penetration testing is for.

FAQ

What is the XCPE botnet?

XCPE is a backdoor preloaded in the firmware of Android-based set-top boxes and similar devices. It enrolled more than 1.3 million devices into a botnet that was rented out for ad fraud, residential proxy traffic and further malware installs.

Who is Videostrong Technology and why did Google ban it?

Videostrong Technology Co. is an Android OEM and ODM. Google assesses with high confidence that it deliberately built and ran the XCPE backdoor for profit, so Google cut ties and banned it, including future subsidiaries and partners, from devices with pre-installed Google apps.

Does uninstalling the XCPE backdoor remove it?

No. The backdoor reinstalls itself from the device's /oem/ partition at the next reboot. Only a vendor-verified clean firmware image or replacement hardware gives a trustworthy result.

Which devices besides TV boxes were infected?

Google found XCPE on telehealth devices, karaoke machines and digital signage as well as Android TV set-top boxes. Many are sold under reseller brands, so the manufacturer name may not appear on the device.

Is the XCPE backdoor still active after Google's takedown?

The control infrastructure was disrupted, but the backdoor and installed modules remain on devices already deployed. Loss of command traffic does not mean a device is clean.

What malware did the XCPE botnet install?

Residential proxy and bandwidth-sharing kits including Linkfog, AppSalt, GaGaNode, BWM, Traffmonetizer, EarnFM and NetNut, plus ad-fraud modules such as Fission and HiddenView.

If your lobby screens, signage or clinic devices came from a supplier who cannot name the firmware maker, we can test them alongside the network they sit on. See our IoT device penetration testing service.