Malware in Android Car Head Units: Updates Become a Channel for Ad Fraud and Proxy Botnets

A New Infection Chain Targeting DoFun Head Units

In June 2026, Kaspersky researchers identified a malware family designed to target the firmware of Android head units developed by DoFun. According to the published analysis, this is the first documented infection chain built specifically for automotive infotainment systems.

The goal is not to directly control driving functions, but to turn the Android unit into a platform for ad fraud and proxy activity. Once compromised, the device can install additional modules, display unwanted content, execute remote code, and use the vehicle’s connection to relay traffic.

The threat affects an area often treated as mere infotainment. In reality, head units are Android computers with connectivity, applications, persistent storage, and, in many cases, Internet access through an integrated SIM.

The Update Application Is the Weak Link

The central component in the attack is TWCore, a system application with the package name com.tw.core. The software performs legitimate functions: it collects analytics data and updates the head unit by downloading APK files.

The operators behind MoYu exploited this mechanism to distribute malware directly to the units. Communication with the update infrastructure takes place over MQTT, using the subdomain cardoor[.]cn. APK packages are stored in:

<TWCore external cache dir>/push/apk/

The abuse was responsibly disclosed, and the issue that allowed unauthorized software distribution has been fixed. However, the exact patched versions and a complete public procedure for checking every affected model remain unknown.

The risk is greater because Android head units may be installed by manufacturers or added later as aftermarket systems. The same attack surface can therefore include both new vehicles and older cars upgraded with retrofit components.

JarService Launches a Multistage Downloader

The first piece of malware identified in the chain is a dropper called JarService. Its role is to evade initial checks and launch a loader responsible for retrieving the next-stage payload.

The sequence observed by researchers works as follows:

1. the loader collects information about the compromised head unit;
2. it sends the data to a remote server in an HTTP POST request;
3. it receives a link to the next component;
4. it downloads the payload from 144.217.243[.]201/vr34der34/dex3.68.png.

The .png extension does not necessarily indicate an image. The file serves as a container for the code to be installed. The dex3.68 reference identifies a payload version: by changing the number in the URL, Kaspersky retrieved seven variants, including versions dating back to 3.57.

At the end of the chain, the malware is installed as a regular user application. It displays no windows or visible interface and continues running in the background, making it less likely that the vehicle owner will notice the infection.

A Remotely Updated C2 Infrastructure

The installed component periodically contacts its command-and-control infrastructure. By default, it sends a POST request to the /cpc/api/task endpoint every 90 minutes.

The communication includes device details and the version of the local configuration. If the configuration is outdated, the server provides new C2 addresses and HTTP paths. Otherwise, the response contains numeric command identifiers that the operators call productId.

The trojan maps each identifier to the required parameters and stores the information as serialized JSON through SharedPreferences, the Android mechanism normally used to store application preferences.

This architecture allows the operators to quickly change servers, paths, and instructions without reinstalling the main component. The compromise therefore does not depend on a fixed, easily blocked infrastructure.

Nine Commands for Advertising, Downloads, and Remote Control

The malware implements nine operational functions:

• return, to read and return values stored in SharedPreferences;
• copy, to modify the clipboard contents;
• http, to send HTTP GET or POST requests;
• web, to open content in a WebView and execute JavaScript;
• loadlib, intended to load libraries but not fully implemented;
• loadlib2, to download and execute code from a URL;
• loadlib3, a second incomplete loading function;
• deeplink, to open addresses in the browser;
• traceroute, to check whether a resource is reachable through ICMP ping.

These capabilities are sufficient to display ads without consent, generate fraudulent advertising traffic, and install additional modules. JavaScript execution in a WebView further expands control over loaded content.

The malware also collects technical information about the environment, including screen resolution, head-unit model, Wi-Fi network identifier, and MAC address. This data can help operators classify devices and distribute targeted commands.

From Ad Fraud to a Proxy Network

One of the most significant aspects is the use of the loadlib2 and http commands to install zhima, a reverse-proxy module previously associated with campaigns conducted through IPTV applications found on inexpensive Android TV boxes.

A compromised head unit can thus become a node for relaying third-party traffic. The vehicle’s mobile or Wi-Fi connection is used as if it belonged to a legitimate user, while the operator retains control of the traffic flow.

The infection therefore serves two connected purposes: monetizing the device through ad fraud and adding it to a proxy infrastructure. Owners may notice unusual data consumption, slowdowns, or unexpected network traffic, but the malware provides no reliable visible warning signs.

MoYu and the BADBOX Connection

Kaspersky attributes the campaign to MoYu with high confidence. The group has been linked to the BADBOX scheme, whose activities were previously brought to public attention by the HUMAN Satori Threat Intelligence and Research team.

In July 2025, Google filed a lawsuit against 25 unnamed individuals or entities in China, accusing them of operating the BADBOX botnet and its supporting infrastructure. The head-unit case indicates that the operation is not limited to low-cost Android devices sold as TV boxes.

It is unknown whether this specific campaign affected a particular number of vehicles or which markets were most heavily targeted. No CVE identifiers have been provided for the exploited vulnerability. Based on the available information, there is also no indication that the flaw appears in CISA’s KEV catalog.

What to Check on Affected Units

The update-channel issue has been fixed, but the exact patched versions remain unknown. Organizations and individuals managing vehicles equipped with DoFun head units should therefore verify the integrity of the firmware and system applications, installing only updates obtained from the manufacturer or an authorized reseller.

Useful monitoring indicators include:

• traffic to cardoor[.]cn;
• connections to 144.217.243[.]201;
• periodic requests to /cpc/api/task;
• APKs or files referencing versions from dex3.57 through dex3.68;
• background applications with no graphical interface;
• unusual WebView activity or code downloads through loadlib2;
• traffic consistent with reverse-proxy activity.

The presence of any one of these indicators does not, by itself, prove an infection. It may, however, justify a forensic examination of the firmware and installed applications. Because detailed remediation procedures have not been disclosed, software reinstallation should be performed only with official images and the manufacturer’s procedures.