XCPE Botnet: How to Find and Contain Backdoored TV Boxes

The XCPE botnet became an urgent connected-device security story on November 3, 2026, when Malwarebytes reported that a hidden firmware backdoor had put more than 1.3 million Android TV boxes to work for criminals. Unlike ordinary malware, this threat did not wait for an owner to click a bad link. Google says the code was built into devices associated with manufacturer Videostrong and could restore itself after removal.

The infrastructure takedown disrupted current criminal control, but it did not clean the hardware already in homes and businesses. If you manage streaming boxes, digital signs, telehealth equipment, or other inexpensive Android appliances, the practical question is no longer whether the command server is online. It is whether you can trust the firmware, network behavior, and supplier behind each device.

Key Takeaway: A takedown can disconnect a botnet without removing its backdoor. Treat affected or unverifiable devices as untrusted hardware until you replace them or install authenticated clean firmware.

What the XCPE botnet did

Google Threat Intelligence Group published its technical findings on November 2, one day before the Malwarebytes report that cleared today's freshness gate. Google assesses with high confidence that Videostrong Technology intentionally developed, deployed, and operated XCPE for financial gain. That is Google's attribution, and it should be described as such rather than as an independent legal finding.

Google says the backdoor was embedded in firmware under package names including x.cpe and com.oemservice. It ran with Android system privileges, contacted operator infrastructure, and received commands through an MQTT broker. Criminal affiliates could then load modules onto the device.

Those modules supported several profitable activities:

• routing third-party traffic through the owner's internet connection as a residential proxy
• generating fraudulent advertising impressions and clicks
• silently installing more applications and malware
• collecting account, device, application, and system-log data
• capturing screenshots and injecting keystrokes
• running shell commands and opening reverse shells
• probing the local network from a trusted residential or business connection

Google and its partners used legal and technical action to take down servers and domains tied to XCPE and more than a dozen related malware families. Google also ended its relationship with Videostrong, banned the company and future affiliates from producing certified Android devices, and changed its review process.

That response matters, but it has a limit. The backdoor remains in compromised firmware. Removing the visible package may not work because the device can reinstall it from the OEM partition after reboot.

Key Stat: The XCPE botnet enrolled more than 1.3 million set-top boxes, while the broader disruption affected command infrastructure associated with at least 10 million additional compromised devices, according to Google and follow-up reporting.

Why a firmware backdoor changes the response

Most endpoint playbooks assume the operating system is a trustworthy place from which to remove a malicious application. XCPE breaks that assumption. When persistence lives in the system image and starts with system-level authority, a factory reset may simply return the device to the same compromised state.

This creates three separate risks for owners.

First, your public IP address can become someone else's exit point. Fraud systems, account providers, and investigators may see activity coming from your connection even though you never initiated it. That can trigger blocks, reputation damage, abuse complaints, or scrutiny.

Second, the device can become a foothold near more valuable systems. A TV box may look harmless, but it shares network proximity with laptops, phones, cameras, printers, payment devices, or clinical equipment unless you deliberately isolate it. Network reconnaissance and reverse-shell capability make that proximity relevant.

Third, normal device behavior does not prove safety. A backdoored box can still stream video, show signs, or run a telehealth application while malicious modules operate in the background. Availability is not integrity.

This is why the case differs from a routine vulnerable-app story. A patch may close a software bug, but it cannot restore trust when the party controlling the firmware is the party Google says operated the backdoor.

Hexon's guide to IoT botnets and connected-device risk explains how weak devices become distributed criminal infrastructure. XCPE adds a harder supply-chain lesson: some devices may arrive enrolled before the buyer has a realistic chance to defend them.

How to find XCPE botnet exposure

Google had not published a complete affected-model list at the time of writing. That means a reliable review must combine procurement records, device identity, software inspection, and network evidence rather than relying on one brand label.

Start with an inventory of Android-based appliances, including devices that facilities, marketing, retail, or clinical teams bought outside the normal IT process. Look for:

• Android TV and set-top boxes attached to televisions or meeting-room displays
• digital signage players in stores, offices, schools, and public spaces
• karaoke, hospitality, and entertainment hardware
• telehealth devices and specialized Android appliances
• products supplied under different retail brands by the same OEM or ODM
• unsupported devices with unclear update ownership

Record the manufacturer, retail brand, model, serial number, Android build, firmware version, purchase source, network segment, physical location, and business owner. Photograph labels if the management interface does not expose trustworthy identity information.

Then review network telemetry for unusual patterns. Google published indicators and infrastructure details in its technical report. Search historical DNS, firewall, secure web gateway, and DHCP records for relevant domains and for devices that make unexplained outbound connections, maintain persistent MQTT sessions, or send large amounts of traffic while supposedly idle.

Do not interpret one blocked domain as proof that a device is clean. The operators changed loaders and modules over time, and a sinkholed or offline domain only describes one control path. Focus on behavior as well as indicators:

• recurring outbound traffic at all hours
• connections to residential proxy or bandwidth-sharing services
• DNS requests unrelated to the device's stated function
• unexpected APK downloads or package changes
• outbound scanning or attempts to reach internal addresses
• unexplained bandwidth, ad traffic, or connection spikes

Pro Tip: Compare each device's observed destinations with a short allowlist from the service owner. A streaming box that cannot justify its outbound connections should not receive open internet access by default.

Hexon's OT asset inventory guide is useful beyond industrial environments because it connects devices to owners, dependencies, locations, and recovery decisions. That context is exactly what an XCPE investigation needs.

Contain a suspected XCPE device safely

If a device matches a known indicator or you cannot establish a trustworthy firmware path, disconnect it from the internet. Preserve enough evidence to understand where it was connected and what it could reach, but do not keep a suspicious appliance online merely to watch it.

For a business-managed device, use a controlled containment sequence:

1. Record the device label, physical location, IP address, MAC address, switch port, and current connections.
2. Export relevant DNS, firewall, DHCP, wireless, and proxy logs before normal retention removes them.
3. Isolate the switch port, wireless client, or VLAN from the internet and sensitive internal networks.
4. Identify every account, application, and workflow used on the device.
5. Change credentials and revoke sessions from a known-clean system if account data may have appeared on screen or passed through the device.
6. Review nearby systems for unusual authentication, scanning, or lateral traffic.
7. Replace the hardware or install clean, authenticated firmware from a source you can verify.

Do not assume that uninstalling x.cpe, running a mobile antivirus scan, or performing a factory reset solves the problem. Google's analysis says the system preload can restore the package from the OEM partition. Clean recovery requires a trustworthy replacement image, and many low-cost appliances do not provide one.

For home users, the safest practical action is usually to unplug a suspected box and contact the seller for a replacement or verified clean firmware. If neither exists, replace the device. The cost of a new streaming box is usually lower than the time and uncertainty involved in rebuilding untrusted firmware.

Common Mistake: Moving a suspicious box to guest Wi-Fi and calling the incident closed. Segmentation limits the blast radius, but the device can still misuse your public IP address and bandwidth if outbound traffic remains unrestricted.

Use network controls that assume IoT devices can fail

Connected appliances should not share the same trust zone as employee laptops, servers, payment systems, or sensitive home devices. Put streaming and IoT equipment on a dedicated VLAN or wireless network with client isolation and restrictive routing.

Hexon's guest Wi-Fi security guide covers the core separation pattern. For devices such as Android TV boxes, go further by controlling outbound access rather than only blocking movement toward internal systems.

A useful policy should:

• deny access from the IoT segment to corporate and administrative networks
• allow only required DNS, time, update, and service destinations
• block direct outbound MQTT unless the business function requires it
• log denied connections and unexpected destination changes
• apply bandwidth thresholds and alerts to normally quiet devices
• prevent devices from acting as inbound services from the internet
• review exceptions on a fixed schedule

Network access control can also quarantine devices that present unknown manufacturers, unexpected operating systems, or stale firmware. Small businesses without enterprise tooling can still create a separate SSID, disable peer-to-peer access, use router-level DNS logging, and replace devices that cannot be updated.

Segmentation is not a cure for malicious firmware. It is a resilience control that reduces what one bad appliance can see, reach, and impersonate while you arrange replacement.

Fix connected-device procurement after XCPE

XCPE shows why a certification logo cannot be the only trust signal. Google says Videostrong evaded existing checks by loading malicious code after first boot, and Google has since strengthened firmware integrity review. Buyers still need evidence from the seller and manufacturer.

Before purchasing connected hardware, require answers to these questions:

1. Who builds and signs the firmware?
2. Which company operates the update infrastructure?
3. How long will security updates be provided?
4. Can the buyer verify firmware signatures and version history?
5. Which domains and protocols does the device require?
6. Does it include proxy, bandwidth-sharing, advertising, or monetization software?
7. Can all nonessential modules be removed?
8. Is a software bill of materials or component inventory available?
9. What is the replacement process after a security incident?
10. Will the supplier notify you if its OEM, certificate, or update service changes?

Prefer devices with a named security contact, documented update lifetime, signed firmware, published advisories, and a clear model-level support page. Avoid products whose real manufacturer is difficult to identify or whose business model depends on unexplained "free" services.

The hardware wallet supply-chain attack guide addresses a different device category, but the trust principle transfers cleanly: verify provenance, software integrity, and recovery before a device receives access to something valuable.

Key Takeaway: Procurement is a security control when firmware defines the root of trust. If a supplier cannot explain who signs updates or how clean recovery works, the device is cheap because you are carrying the uncertainty.

What the XCPE takedown does and does not solve

The coordinated action removed important command infrastructure, disrupted affiliate malware, and cut a manufacturer accused by Google out of the certified Android ecosystem. Those are meaningful defensive wins. They raise operating costs for the botnet and reduce immediate control over many enrolled devices.

The takedown does not prove every affected box is clean. It does not publish a complete model list, rewrite compromised firmware, or guarantee that another actor cannot find a remaining control path. Owners still need to identify devices, review traffic, isolate risk, and replace hardware that cannot establish a trustworthy state.

The broader lesson reaches beyond TV boxes. Digital signs, telehealth appliances, conference-room systems, kiosks, and other Android-based devices often sit outside endpoint management while retaining constant network access. That makes them attractive infrastructure for anyone selling proxy capacity, ad fraud, malware delivery, or covert access.

Start with one concrete action today: list every Android appliance on your network and identify who supplies its firmware updates. If you cannot answer that for a device, isolate it until you can. The XCPE botnet is a reminder that connected hardware should earn network trust through verifiable software and constrained behavior, not through a familiar logo on the box.