If you manage more than a couple of generic Android TV boxes — the ones without a recognizable brand like ZTE or onn, but that arrive labeled "X96", "H96", or with no name at all — chances are at least one of them is running processes you never installed. This isn't an infection that happened later. It shipped that way.
How malware gets on the device before you even power it on
Most low-cost Android STBs aren't built end-to-end by a single company. A board manufacturer buys a chipset (typically Amlogic or Rockchip), flashes a generic Android firmware onto it, and that firmware passes through several hands — integrators, distributors, resellers — before it ends up in your customer's hand or in your fleet.
At any of those steps, someone can (and often does) bundle system-level apps with elevated permissions: "update" apps that are actually adware, background services that generate traffic to third-party servers, or outright botnet components that use the device as a proxy node. Because they're signed as system apps, the end user can't uninstall them from normal Android settings.
The manufacturer doesn't need to be malicious on purpose. Malware often enters through a third-party update component (a "FOTA agent") the manufacturer integrated to save the effort of building its own — and that component was compromised somewhere along the supply chain.
The symptom you see isn't the real problem
The most visible effect of these processes is bandwidth consumption: the device generates constant outbound traffic, even with nothing on screen. If you're an ISP or manage a network with many of these STBs, this translates into:
- "Slow internet" tickets that have nothing to do with your network — they're malicious processes consuming the subscriber's link from the inside.
- Device performance degradation: CPU and RAM occupied by background processes that give the user nothing in return.
- Network reputation risk if the device participates in a botnet or outbound attack traffic, which can end up hurting the reputation of your IP range.
The problem is that almost no network diagnostic tool points this out directly. You see the symptom (slowness, anomalous traffic) but not the origin (a specific process on a specific device).
Why a factory reset isn't enough
A factory reset doesn't help, because the malware is baked into the factory image itself: reboot, and it's back. And a mass remote factory reset across hundreds of active devices isn't realistic if it means reconfiguring each one by hand afterward.
What actually works is identifying the specific packages that are running and force-stopping them in a targeted way — without touching the rest of the system, without user interaction, and repeatably across the fleet. That's exactly what AdminSTB's malware process killer does: a kill list managed from the dashboard that the agent enforces on every telemetry cycle, on every device, regardless of root access.
You'll find more than you expect
With AdminSTB's app network usage ranking you can see, device by device, which process is generating the traffic and kill it from the same dashboard.
What to do if you suspect your fleet has this problem
- Pick a representative device and check for system processes you don't recognize — apps with generic names, packages with unusual Chinese domain names, or "update" services with no clear brand.
- Cross-reference that list with each process's network usage during a period of no active use (overnight, for example). Constant background consumption is the clearest signal.
- If your suspicion is confirmed, you need a way to apply the fix to the whole fleet at once, not device by device — otherwise the problem comes back the moment one slips through.
This last point is what costs teams managing fleets by hand the most time. With centralized visibility and a kill list that applies itself on every check-in, it goes from being a recurring problem to a routine maintenance task.