Researchers have reported a new campaign involving Android Car Malware that targets Android-based vehicle head units. Instead of relying on random downloads, the threat abuses legitimate update functionality inside the vehicle system firmware to deliver a multi-stage payload.
According to Kaspersky, the activity was identified in June 2026 and linked with high confidence to the MoYu Group, previously associated with ad fraud and residential proxy infrastructure known as BADBOX. This matters for drivers and fleet operators alike: the head unit acts as a central hub for multimedia and some vehicle-related controls, and it often stays connected through built-in connectivity features.
Why vehicle head units attract attackers
A car head unit combines the infotainment experience with partial control features and may be installed at the factory or added later as an aftermarket upgrade. Because Android-powered models have become common for both retrofits and new vehicles, they also inherit the same app ecosystem and risks seen on other Android devices.
In this case, the researchers point to a specific advantage for attackers: Android head units can include a SIM card slot, which provides internet access for navigation and software updates. That connectivity, combined with updaters designed to keep firmware and apps current, creates an attractive path for malware distribution.
How the infection spreads through built-in updaters
The report describes an infection chain tailored specifically to Android automotive head units developed by DoFun. Kaspersky states that this is the first documented case of malware on a car head unit with a chain crafted for that device type.
At the starting point is a legitimate system application called TWCore, identified as com.tw.core. Its role includes collecting analytics and distributing software updates by downloading APK packages to a cache path used for installation. The delivery mechanism relies on an MQTT message broker hosted under the cardoor[.]cn subdomain.
While TWCore is a real, expected component, the attackers leveraged its update pathway to deliver a previously unknown dropper named JarService. To reduce the chances of detection, the dropper initiates a loader sequence that communicates with attacker-controlled infrastructure before pulling the next stage of the malware.
From dropper to next-stage payload
The loader first sends implant details to one of the attackers’ servers using an HTTP POST request. The server responds with a link pointing to the next payload stage. One example path referenced in the report is:
144.217.243[.]201/vr34der34/dex3.68.png
Notably, the payload naming includes a version reference (such as dex3.68). Kaspersky explains that by trying other version numbers, it was possible to retrieve seven distinct variants dating back to version 3.57.
The payload runs as a hidden user app
The final stage is deployed as what appears to be a regular user application. However, it does not present a user interface. Instead, it operates covertly in the background.
By default, the malware is configured to send periodic updates to its command-and-control (C2) endpoint every 90 minutes. Alongside connectivity signals, it transmits information about the infected device and its configuration version.
The C2 server behavior depends on whether the configuration is outdated. If the configuration version needs updating, the server replies with new C2 addresses and fresh request paths. If not, it sends back integer command identifiers that the attackers refer to as `productId` values.
Once received, the malware maps each identifier to a corresponding command definition. It stores these command details as serialized JSON using Android’s SharedPreferences API.
Commands used for ad fraud and additional payloads
The malware supports nine commands intended to drive unwanted advertisements, enable ad fraud activities, and download additional malicious modules when required. The capabilities also extend to collecting device information relevant to targeting and control.
Kaspersky reports that the command set can retrieve details including display resolution, device model, the identifier of the connected Wi‑Fi network, and the device’s MAC address. It can then use that context to coordinate further operations.
Command list highlighted by the researchers
- return: return a value from SharedPreferences
- copy: set clipboard contents
- http: perform POST/GET HTTP requests to a specified resource
- web: open a link in WebView and execute arbitrary JavaScript
- loadlib: not fully implemented
- loadlib2: download and execute arbitrary code from a URL
- loadlib3: not fully implemented
- deeplink: open a URL in the browser
- traceroute: check resource availability via an ICMP ping
Proxy botnet modules delivered via load mechanisms
One of the critical outcomes described in the report is how the campaign ties together ad fraud and proxy infrastructure. The attackers are said to use commands such as loadlib2 and http to download another module called zhima.
In the report, zhima is described as a reverse proxy module previously documented by the Nokia Deepfield Emergency Response Team. It is reportedly selectively delivered through IPTV applications often found on inexpensive Android TV boxes.
By adapting delivery into the vehicle head unit environment, the campaign can expand the pool of infected devices that may support the broader proxy scheme—while also enabling advertisement manipulation through the malware’s command set.
Evidence of earlier tracking and ongoing threat activity
Kaspersky attributes the activity with high confidence to the MoYu Group. That group was previously disclosed by the HUMAN Satori Threat Intelligence and Research team as part of BADBOX, a broader operation tied to ad fraud and residential proxy infrastructure.
Additionally, Google reportedly filed a lawsuit in July 2025 against 25 unnamed individuals or entities in China, alleging operation of the BADBOX botnet and related infrastructure. Despite disruption efforts by security teams and law enforcement, the researchers emphasize that associated actors continue malicious activity, including infecting devices across locations.
What this means for automotive security
This case is notable not only because it targets vehicle systems, but because the malware’s delivery chain is crafted specifically for Android head units using their firmware update mechanisms. Kaspersky frames it as a warning: modern automotive platforms require stronger defenses that cover the full software update and application delivery path.
In the reported case, after responsible disclosure, the underlying issue enabling software distribution abuse was addressed. Still, the broader lesson remains: when an attacker can piggyback on “legitimate” update workflows, even devices designed to receive updates safely can become distribution points.
How to reduce risk in the meantime
While the report focuses on the technical infection chain, drivers and fleet managers can take practical steps to limit exposure. Start by keeping head unit software up to date only through trusted update sources and vendor processes.
Also consider hardening the environment around the vehicle system. If your setup allows installation of third-party apps, apply strict controls and avoid unknown sources—especially for applications that may interact with network traffic, update channels, or web content rendering features.
Finally, watch for unusual behavior from the head unit, such as unexpected network activity, unexpected ad behavior, or unexplained changes in connectivity patterns. Early detection can reduce the window for malicious modules to download and run.
Conclusion
The discovery of Android Car Malware shows how attackers can turn essential vehicle features—like firmware update functionality—into a delivery mechanism for ad fraud and proxy-related capabilities. By abusing a legitimate system updater component and deploying hidden background functionality, the campaign demonstrates an increasingly sophisticated approach to compromising modern automotive Android devices.
As Android-based head units continue to spread in both factory and aftermarket settings, robust security controls across the update lifecycle will be essential to prevent similar infections.
Source: https://thehackernews.com/2026/08/android-car-malware-spreads-through.html
