Google Bans Android TV Box Maker Videostrong Over a Backdoor on 1.3 Million Devices, but the Takedown Holds Domains and Leaves the Implant on Each Box

Google Threat Intelligence Group said on November 2 that it and its partners “dismantled the XCPE backdoor which enrolled more than 1.3 million set-top boxes into a botnet.” It assesses “with high confidence” that Videostrong Technology Co., an Android device maker that The Verge places in Shenzhen, developed and ran the backdoor “for financial gain,” and it has banned the company, along with any future subsidiaries or affiliates, from building and selling certified Android devices.

The takedown cut off the operator, not the devices. TrendAI, one of the partners, says removing the two central servers “cut the operator off from the devices, although the implant remains on each box.” Google’s own description adds that the main component, as a system preload, “cannot be removed by the user.” On November 3 we checked every domain in Google’s indicator table against registration and DNS data. Registrars have put most of them on hold, ten names still resolve, and a configuration host that Plume ties to one line of the boxes still resolves to the address Plume gives for its broker.

What Google says it did

Google’s post lists four actions:

• Legal action “to take down the domains and servers Videostrong used to control the botnet and install malware modules.”
• Legal action against command-and-control domains “used by over a dozen malware families loaded as modules via this backdoor.” Those affiliates distribute their modules through other channels too, so Google assesses that the action “will sever access to at least 10 million additional compromised devices.”
• A ban on Videostrong, and on any future subsidiaries or affiliates, from building and selling certified Android devices or supplying software to other certified vendors.
• “Improvements to how we ensure the integrity of firmware on certified Android TV devices.”

The admission with the most consequence for other device makers concerns Google’s own certification. Google requires OEMs to pass “a comprehensive suite of compatibility and security tests,” but says “Videostrong employed obfuscation techniques to exploit a gap in our tests and load malicious code after the device’s first boot,” and that it has changed its review process. Its partners were Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient and TrendAI. Lumen says it is helping null-route the proxy servers involved and is publishing indicators in ThreatFox.

How the backdoor works

Google describes a three-stage design that Videostrong has run since at least late 2024. A stub preloaded in the firmware partition runs at the android.uid.system privilege level, under the name x.cpe or com.oemservice depending on the build. It fetches configuration over HTTP, then keeps an MQTT connection open to take orders: silent app installs, arbitrary shell commands, screen captures, and a setting change that disables Google Play Protect app verification. A loader, com.abc.nexus, runs the monetization modules. They come from other parties and turn the box into a residential proxy exit node, an ad-fraud engine or a further backdoor. “Since August 2026,” Google says, new dropper packages disguised as Android system apps have begun to replace that loader. Most infected devices are Android TV set-top boxes, with some telehealth devices, karaoke machines and digital signage.

The counts measure different things

The headline figure is “more than 1.3 million” in Google’s and TrendAI’s posts, with close variants elsewhere, but the figures underneath count different things.

Read together, the 1.3 million is a count of devices seen over months, not of boxes online at once. Plume’s September 8 snapshot of the two brokers that had devices adds up to 450,585 concurrent connections (our sum), about 35 percent of the 1.3 million floor, which fits Synthient’s “around half a million actively online.” TrendAI’s average of 182,025 residential addresses available on a single day is about 12 percent of its 1,472,554 observed devices (our arithmetic). Lumen’s per-service populations cannot be added to the fleet total, because each describes a whole service, and Google notes that one device can run “as many as three residential proxy SDKs.” TrendAI’s top five countries are Malaysia, Brazil, Iraq, Mexico and Taiwan, with the United States, Germany, the United Kingdom, Australia and Canada each at roughly 26,000 to 42,000 devices.

What the takedown did to the infrastructure

We parsed the network-indicator table in Google’s post, which holds 145 domains, 6 subdomains, 11 GitHub account paths and 4 IP addresses, and skipped two wildcard rows. Starting at 10:29 UTC on November 3 we asked Cloudflare’s and Google’s public DNS-over-HTTPS resolvers for the address of each of the 151 domain and subdomain names, and the registry RDAP services listed in IANA’s bootstrap file for each registrable domain. No request went to any listed host.

The last row groups the Spirit, IPWeb, EarnFM, Fission, Gaganode and HiddenView labels.

All 123 held registrable domains carry the EPP status client hold, which RFC 5731 defines as “DNS delegation information MUST NOT be published for the object.” For 122 of them RDAP’s last-changed date falls between October 28 and November 2, and 113 of those on October 30. GoDaddy is the registrar of record for 108 of the 123. The two core domains, szbboys.com and the bootstrap domain anyevonline.com (which Google’s table covers with a wildcard row), are both held at Alibaba Cloud (Beijing), with registrations that run to February 24, 2027 and August 6, 2029. Under RFC 5731 a client status is one the sponsoring registrar can add or remove. The registry RDAP records show only the registrar, not the registrant or who asked for the hold, so we cannot say whether a court order stands behind these holds or how durable they are. Lumen describes emkmoh.com and io.pyuio.com as “seized by Google”; in RDAP their registrable domains carry the same kind of hold, at Cloudflare and GoDaddy, with last-changed dates of October 30, so what Lumen calls a seizure shows up in public data as a registrar hold.

Google says the operators hosted payloads as GitHub releases. GitHub no longer serves any of the 11 account paths in the table (HTTP 404 from its API at 10:29 UTC), though a 404 does not tell us whether an account was deleted or suspended.

Ten names still resolve. Three are Google-listed AppSalt domains registered through Tucows (dramapi.com, winklenark.com and wogglenift.com); one is earn.fm, which Lumen says Google “targeted” but which shows no hold; the rest are a HiddenView domain, two Fission subdomains, a Jaguar subdomain, a Spirit domain and a .my name we could not check through RDAP.

The YOKATV configuration host

Plume found three pairs of configuration server and MQTT broker. The first pair uses anyevonline.com and szbboys.com, both held. The second serves the YOKATV line of boxes: configuration at tms.yokatvonline.com:8443 and a broker at usamqtt.szbboys.com, address 38.145.197.30, where Plume counted 26,477 live connections on September 8. The broker’s name is now dead because szbboys.com is held. The configuration host is not. At 10:29 UTC on November 3, tms.yokatvonline.com resolved to 38.145.197.30 on both resolvers, and yokatvonline.com, which Google lists with the note “Fallback C2 for system packages,” has no hold. Google’s table lists 38.145.197.135, a neighbor in the same /24 block, but not 38.145.197.30. Plume says each configuration server returns its own MQTT host to the boxes. We did not connect to the address, so we cannot say whether it still answers, whether the YOKATV boxes would follow a new broker name, or whether Google’s legal action reaches it.

Past disruptions in this market did not last. Lumen says IpMoYu, a service that installed malware on X.CPE-backdoored devices, “began operating under multiple names” after the BadBox 2.0 operation seized its primary domain, TrendAI warns that “operators of this kind have rebuilt on new infrastructure before,” and Google’s post says that “when one component is disrupted, operators quickly pivot to new loaders or rival monetization SDKs.”

Plume’s analysis of the update client it found in Videostrong’s STV-2000 firmware shows what a lapse would cost. The client acts on an unsigned XML file, and for the generated update host under szbboys.com Plume says “DNS is the only security measure left.” The registrations run to 2027 and 2029, which is the window in which a hold would need to become a seizure or a sinkhole.

Where the reports disagree

• Which boxes. Google’s post names no brand; “mecool” appears once, inside the ro.mecool.device system property the malware checks. Synthient attributes the MECOOL brand to Videostrong and published 182 model strings, with the caveat that “A model name alone is not sufficient to confirm compromise.” Plume says “more than a dozen different devices appeared to use the same MQTT broker, with MECOOL devices making up the majority,” and its device table also covers white-label models, some carrying other companies’ names. Online, mecool.com, which Plume cites for a MECOOL product photo, was still up at 10:29 UTC, with 115 of its 116 product variants marked unavailable (we cannot tell when that changed), and videostrong.com still carries “Google Certified Android TV Box” product labels.
• Cleaning a box. Plume concludes that the botnet’s “core infrastructure is gone” and advises “a full factory reset” because modules may have dropped further backdoors. TrendAI says “Owners cannot remove the implant themselves.” Synthient advises that consumers “permanently dispose of these devices.” Google says x.cpe, as a system preload, “cannot be removed by the user,” and that after an uninstall it “automatically reinstalls from the /oem/ partition upon reboot.” A reset wipes user data, and none of the reports says it clears a firmware stub.
• The 10 million. BleepingComputer says the additional devices include “retail set-top boxes, karaoke machines, and telehealth hardware” and that “Google says that not all of them are Android devices.” We could not find either statement in Google’s post, which lists karaoke machines, telehealth devices and digital signage among the infected “Android-based IoT devices” in the XCPE botnet itself.
• Countries and counts. Lumen says “more than 200 countries”; TrendAI says “more than 170.” TrendAI notes that “Counts differ slightly between partners depending on when each snapshot was taken and what each could see,” and that every figure it gives is a lower bound.
• Who is in the proxy market. Google says the AppSalt SDK is “owned by Honeygain, which is in turn owned by Oxylabs,” and its table labels 100 of its 151 domain and subdomain names Honeygain / AppSalt. Plume says AppSalt “appears to be built from the Honeygain SDK codebase, but operates as an independent network using its own servers and infrastructure.” Google says the integration “explicitly calls the optIn() method which sets a consent flag without displaying any user interface,” and Plume found two builds of the loader, one with a consent dialog and one without, with the second on the devices. Lumen says SOAX, “a service that claims legitimacy,” kept installing proxies on X.CPE-backdoored devices, while TrendAI says of the LinkFog and DianxinCloud services that they are “not necessarily malicious themselves” and that “The abuse lies in how the operator enrolled devices without their owners’ consent.” We found no response from Honeygain, Oxylabs, SOAX, EarnFM or Videostrong in the reports or coverage we read.

Each report also describes its own part of the operation and its own interests. Synthient’s was produced with the Motion Picture Association, whose executive is quoted on illicit streaming devices, and TrendAI’s closes by recommending its own products.

What owners and network teams can do

None of the reports gives a way to remove the firmware component from a box that is already in a home. Synthient recommends that the devices “be immediately pulled from online retail stores and marketplaces.” TrendAI advises consumers to avoid “unbranded or uncertified Android TV boxes and apps that pay for shared bandwidth.” Google tells users to keep built-in protections such as Google Play Protect active and to buy set-top boxes from reputable manufacturers, and points to its Android TV partner list. For companies, TrendAI says the exit addresses sat on consumer providers such as Comcast, Charter, AT&T, Virgin Media and Vodafone, “Blocklists of data-center ranges would not and did not catch this traffic,” and fraud teams “should stop relying on IP reputation alone.” It also says access “was sold as residential proxy and AI gateway services,” while adding that it observed no buyer and that nothing in its report is evidence of nation-state use.

To check a box you own, the reports give package names to look for: x.cpe and com.oemservice for the main component, com.abc.nexus for the loader, and, since August, droppers such as com.android.system.ntp and com.android.sso.auth.handler. With developer options and debugging over the network switched on (the menu names vary by box), a computer on the same network can list matching packages through adb. Its pm list packages command prints packages whose names contain the text you give it, as the Android Developers documentation describes. Run it once and switch debugging off again. An empty result for every name does not clear the box, because the operators have already renamed components once. Replace the address with your box’s.

adb connect 192.168.1.50:5555
for p in x.cpe com.oemservice com.abc.nexus \
         com.android.sso.auth.handler com.android.system.ntp; do
  echo "== $p"
  adb shell pm list packages "$p"
done
adb disconnect 192.168.1.50:5555

adb connect 192.168.1.50:5555
'x.cpe', 'com.oemservice', 'com.abc.nexus',
  'com.android.sso.auth.handler', 'com.android.system.ntp' |
  ForEach-Object { "== $_"; adb shell pm list packages $_ }
adb disconnect 192.168.1.50:5555

On the network side, the retry traffic should show up in resolver logs: the boxes keep asking for names that no longer resolve. Search your resolver or router log for the held names and match the client addresses to devices. We ran the loops above and the log search below against a stand-in adb and a sample log, not against an infected box.

grep -Ei '(^|[^a-z0-9-])(anyevonline|szbboys|yokatvonline)\.com' resolver.log

$names = 'anyevonline|szbboys|yokatvonline'
Select-String -Path resolver.log -Pattern "(^|[^a-z0-9-])($names)\.com"

What is still not public

• The legal action. Google’s post names no court or case, and neither do the three outlets we read. A search of CourtListener’s RECAP archive for “Videostrong,” “anyevonline” and “szbboys” returned no results on November 3, though RECAP holds only filings that users uploaded.
• Boxes already sold. Google’s stated firmware change is about “how we ensure the integrity of firmware on certified Android TV devices.” It does not say whether Play Protect or a firmware update will clear boxes already in homes, and Plume found a fleet that “mixes AOSP (Android Open Source Project) and Google-certified devices.”
• Videostrong’s side. We found no statement from Videostrong or from the sellers of the affected boxes in the coverage we read.
• The YOKATV configuration host. Whether it still answers, and whether it falls inside Google’s legal action, is not stated anywhere we looked. A similar completeness check on the Popcorn Time updater takedown found three of 20 listed domains outside the sinkhole.