Skip to content
HACKTECH
Mobile & IoTReported Published 3 sources

Google and partners dismantle XCPE backdoor botnet on 1.3 million Android TV boxes

Google Threat Intelligence Group (GTIG) said on 2 November 2026 that Google and industry partners had dismantled the XCPE backdoor, which had enrolled more than 1.3 million set-top boxes into a botnet. GTIG assessed with high confidence that the backdoor was intentionally developed and operated for financial gain by Android device manufacturer Videostrong Technology Co., which sold access to criminal affiliates whose modules carried out ad fraud, enrolled devices in residential proxy networks and loaded further malware. Google assessed that taking down the affiliates' command-and-control domains will sever access to at least 10 million additional compromised devices, and it has banned Videostrong from building certified Android devices.

  • Android
  • supply chain
  • firmware backdoor
  • residential proxies
  • botnets
  • set-top boxes

What the sources report

  • GTIG says the primary backdoor, x.cpe (com.oemservice in some builds), runs at android.uid.system privilege from the firmware and reinstalls itself from the /oem/ partition on reboot if a user removes it.
  • According to BleepingComputer, operators used an MQTT broker to silently install apps, disable Google Play Protect, run shell commands with system privileges, capture screenshots and inject keystrokes on infected boxes.
  • Affiliate modules turned devices into residential proxy exit nodes (GTIG names Linkfog, AppSalt and NetNut among others), ran ad fraud, or loaded further backdoors such as Moyu and Spirit.
  • Google said Videostrong used obfuscation to load malicious code after a device's first boot, exploiting a gap in its certification tests, and that it has changed its review process; partners included Japan's National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI.
  • GTIG and KrebsOnSecurity reported that, although most infected devices were Android TV set-top boxes, the same malware was found in other Android-based IoT products, including telehealth devices, karaoke machines and digital signage systems.
  • BleepingComputer notes that the takedown does not remove the malware from devices, so owners need clean firmware or must disconnect affected units.

What it means for your organisation

This was a supply-chain compromise: according to Google, the manufacturer built the malicious code into firmware with system privileges, so infection needed no user action or exploited vulnerability, and the backdoor reinstalls itself if removed. Low-cost Android TV boxes, signage players and similar devices can end up on office, retail or clinical networks without a clear owner, and infected units can relay third-party traffic through your IP addresses. Treat any unvetted Android-based device as untrusted: keep it on an isolated segment with restrictive egress, and watch that egress for MQTT sessions and residential-proxy traffic.

What we check

  • Discover Android TV boxes, signage players and other consumer-grade Android devices on corporate, retail and guest networks, and confirm they sit on isolated segments with restrictive egress.
  • On sample devices, list installed system packages (for example over adb) for components named in the report, such as x.cpe, com.oemservice and com.abc.nexus, and verify Play Protect certification status.
  • Inspect egress logs for unexpected MQTT sessions and residential-proxy traffic patterns from IoT segments.
  • Confirm hardware procurement requires firmware provenance and certification, and review third-party SDKs in your own Android apps for bandwidth-sharing or proxy components.

Sources

Services that cover these checks

  • Network & infrastructure testing

    Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

  • Mobile application testing

    iOS and Android testing of the binary, on-device storage and transport, and of the backend API the app calls, replaying the app's own tokens to check whether one user can read another's data. On the device we check what the keychain or keystore stores, whether certificate pinning survives a bypass attempt and what deep links can trigger.

    Duration: 6 to 10 working days

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow the scoping call works