A single Boolean field turned a routine car-stereo updater into a remote app installer. When installNotExists was set to true, the updater on certain DoFun Android head units would accept an APK even if that app had never been on the device. Kaspersky says attackers used that path to deliver a three-stage downloader for ad fraud and a residential proxy botnet. The finding matters beyond one accessory vendor: an update client with system privileges became the malware's distribution channel, so the person driving did not need to tap, sideload, or approve anything.
Kaspersky researcher Dmitry Kalinin reported the infection chain on August 21 after the company's telemetry found an Android app with no interface being installed by com.tw.core. That package name belongs to TWCore, the legitimate analytics and update app in the affected firmware. Kaspersky calls this the first documented malware case with an infection chain built specifically for automotive head units. The company did not publish an infection count, model list, or geographic breakdown, which leaves the reach of the campaign unknown.
The updater crossed its own trust boundary
TWCore receives update instructions through an MQTT broker on a cardoor.cn subdomain. Each message describes APKs to download and install. According to Kaspersky's technical analysis, the installNotExists flag determines whether TWCore limits itself to packages already present. With the flag enabled, the same mechanism can introduce a new app. Telemetry linked the malicious APKs to TWCore in every case Kaspersky observed.
That detail changes the usual advice about Android malware. There was no deceptive download page or fake prompt for the user to spot. The malicious JarService package arrived through software that already had authority to maintain the head unit. Its lack of a user interface made sense because it had no reason to win the user's trust after installation.
DoFun told Kaspersky that it fixed the security issues after receiving the researcher's report. The published account does not name a firmware version, patch date, or list of devices that received the correction. Owners therefore have no public version threshold to compare against their own units. That missing release information is especially awkward for aftermarket hardware, where support pages and update histories can be harder to trace than those for phones.
Three stages kept the final job out of the first APK
JarService was a small first-stage dropper. It decrypted embedded blocks containing code and metadata, then invoked a second-stage loader through an entry-point method identified by Kaspersky. The loader reported details such as its package name, version, and channel ID to a command server. The server responded with a URL for another encrypted payload.
The third stage checked in every 90 minutes by default. Its report included the device model, display resolution, connected Wi-Fi SSID, and MAC address, along with the current configuration version. A server could return revised command addresses or tell the implant to fetch instructions it did not yet know. Kaspersky recovered seven variants of this stage and eight variants of the later zhima proxy module, evidence that the operators revised the components rather than relying on one fixed build.
Researchers found nine commands in the third stage. They included opening a WebView and running JavaScript, making HTTP requests, changing clipboard contents, following deep links, and downloading executable code. Kaspersky said the live campaign used a smaller subset: an HTTP command and loadlib2, which fetched and started the zhima module. Those observed actions support the report's conclusions about ad activity and proxy-node creation. The broader command table describes available capability, not proof that every command ran on every infected unit.
Why a head unit is useful to a proxy seller
A car stereo is an odd place for banking malware because drivers generally do not run banking apps there. It can still be useful infrastructure. Many Android head units have Wi-Fi or a SIM slot and remain connected long enough to download maps, media, and updates. A reverse-proxy module can borrow that connection and present the vehicle's public IP address to somebody elsewhere.
Kaspersky connected the activity with high confidence to MoYu Group, an actor tied to the BADBOX operation. Its attribution rests on names inside the code and overlap in network infrastructure. A separate Nokia Deepfield Emergency Response Team investigation had already reverse-engineered the same zhima module after finding it delivered to Android TV boxes through IPTV apps. Nokia described a proxy engine that makes outbound connections to the operator's relay, then carries SOCKS5 or HTTP traffic for a customer. Since the infected device initiates the connection, an outside scan does not need to find an open proxy port on it.
The delivery vehicles differ. Nokia followed apparently clean IPTV apps that fetched their incriminating code after launch; Kaspersky followed a privileged firmware updater that installed JarService. Both paths ended at zhima. This overlap is useful confirmation of the final module and its purpose, while Kaspersky's head-unit chain remains a distinct finding. It also shows why checking only the first APK can miss the working payload.
The surrounding operation is much larger than the head-unit cases Kaspersky documented. In July 2025, Google said BADBOX 2.0 had compromised more than 10 million uncertified AOSP devices, mainly internet-connected television hardware. Google updated Play Protect to block associated apps and filed a lawsuit against unidentified operators. That 10 million figure applies to BADBOX 2.0 as a whole. It should not be read as a count of infected DoFun units.
The damage can leave the dashboard
The proxy module turns the victim's internet connection into inventory. Traffic sent by a proxy customer can appear to originate from the head unit's network, attaching abuse reports, service blocks, or investigative attention to an address used by the owner. Nokia's module analysis also found that its local-network target filter was incomplete. The researchers did not run an exit node or publish a working exploit. They concluded that the filter could not be treated as a dependable boundary around the infected network.
Kaspersky's third stage adds another concern: the loader can download and run arbitrary code. The campaign observed by the company focused on ad fraud and proxy access, and the report does not claim interference with braking, steering, or other safety systems. A head unit may expose some vehicle functions, but there is no evidence here that the attackers crossed into safety-critical controls. Keeping that distinction clear avoids turning an Android botnet report into a car-takeover story it does not support.
For developers of embedded Android products, the defect sits at the update-policy layer. An authenticated instruction channel still needs rules about which package identities may be introduced, which signer is accepted, and whether an update is replacing an approved component or adding a new one. Kaspersky's account shows TWCore making the already-installed check conditional. The public report does not explain how the malicious instructions entered the update flow, so it would be premature to assign the initial breach to the broker, vendor credentials, or another backend component.
What owners and defenders can verify
Kaspersky published package names, hashes, domains, and IP addresses for the campaign. Fleet operators or technicians with access to head-unit logs can check for installations attributed to com.tw.core, the JarService package com.tw.jar1, and the listed network indicators in the researcher's indicator section. A match on a historical domain should be investigated in context because infrastructure and ownership can change.
For an individual owner, the practical questions are more basic: who built the firmware, whether the supplier has issued an update after DoFun's reported fix, and whether the unit still receives supported releases. Reflashing unknown firmware from a forum introduces another supply-chain risk, so the absence of a clear vendor package is not a reason to install the first image that shares a model label. Replacing an unsupported connected unit may be the only clean option when its software provenance cannot be established.
The next evidence to watch is a vendor advisory that names fixed firmware builds and affected hardware. Researchers could also establish the campaign's scale by publishing telemetry totals without exposing owners. Until either appears, the defensible conclusion is narrower: attackers found a privileged Android updater that could add an absent package, used it to stage a maintained proxy implant, and reached a class of connected devices that often lacks a visible security-update record.