Malware Infects Android Car Head Unit Firmware for the First Time

Kaspersky researchers documented, in a report published on August 21, 2026 on Securelist, what they describe as the first recorded case of malware in an automotive head unit with an infection chain specific to this type of device. The entry point was neither physical access nor a vulnerability exploited from outside: the malicious code arrived through the firmware's built-in updater of DoFun brand head units.

The campaign's ultimate goal, according to the analysis, is ad fraud and the creation of a reverse proxy botnet. The company attributes the activity, with high confidence, to MoYu Group, an actor linked to the BADBOX botnet.

What a Head Unit Is and Why It Becomes a Target

A head unit is the system that combines multimedia functions with partial control of vehicle functions. It can come from the factory or be installed as an aftermarket upgrade. Most of these systems run Android, because the platform's source code already covers automotive use cases and allows manufacturers to add system apps during the build.

The detail that matters to those who work with embedded systems: almost every app built for Android also runs on a head unit, and that includes malware. The difference is that a car's head unit rarely holds anything of direct value (it makes no sense, for example, to plant a banking trojan there). The logical attack scenario is different: infect the device to recruit it into a botnet, exactly as is done with IoT equipment. Head units usually have a SIM slot and internet connection for navigation and updates, which makes them convenient network nodes.

How the Firmware Distributed the Malware

The vector was TWCore, a legitimate system app (package com.tw.core) responsible for collecting analytics and updating the head unit's software. The update mechanism works via an MQTT broker hosted at the subdomain cardoor[.]cn, which sends messages describing which APKs to download and install.

The problem lies in a boolean field in that message: installNotExists. When set to true, it allows TWCore to install apps that were not even present on the device without checking anything. The APK is downloaded to /push/apk/. Kaspersky's telemetry found previously unseen malware exactly in that path, and in every observed case the installation originated from an app with the TWCore package. Kaspersky notified the manufacturer, which reported having fixed the flaws.

A Three-Stage Chain

What caught the researchers' attention was an app that installs like any other, but with no interface at all and without trying to disguise itself as legitimate software, a sign that it reaches the user without their knowledge.

• Stage 1, the JarService dropper: a tiny app, with no UI, that decrypts blocks embedded in its own code. Each block uses XOR with a one-byte key that changes linearly from block to block. The decrypted data describes the version and entry point of the next payload.
• Stage 2, the loader: sends implant information to the C2 via POST (with fields such as userId, dexVersion, packageName and appName). The server responds with a dexUrl pointing to the next payload, disguised as a .png image. By testing version numbers in the URL, the researchers obtained seven distinct variants.
• Stage 3, clicker / reverse proxy loader: sends a POST to /cpc/api/task every 90 minutes by default, with screen resolution, device model, Wi-Fi network SSID and MAC address. The C2 returns both updated configurations (new addresses and paths) and command identifiers that the attackers call productId.

The Command Arsenal and the zhima Botnet

At the time of the research, stage 3 had nine commands implemented, including http (GET/POST requests), web (opening a link in a WebView and executing arbitrary JavaScript), deeplink, traceroute and loadlib2 (downloading and executing arbitrary code). This gives the malware the ability to display ads, commit click fraud and download additional code.

In practice, however, the attackers used only a subset: essentially http and loadlib2. The payload delivered by loadlib2 is a reverse proxy module called zhima (class com.miyc.transfer.Client), which Nokia Deepfield's emergency response team independently identified in TV set-top boxes around the same time. The convergence of the two findings confirms the final objective: building a proxy botnet, with the infected car acting as a traffic exit point for third parties.

What This Means for Embedded Developers in Brazil

The case is not about a specific car, but about a class of risk that directly affects anyone developing for Android devices outside the smartphone: TV boxes, automotive head units, dashboards, kiosks. The weak link here was a poorly designed OTA update mechanism, capable of silently installing any APK because of a boolean flag with no validation of origin or signature.

For teams that maintain firmware or system apps, the concrete points to review:

• Never trust an update channel without strong validation: verification of both the package signature and the server itself, not just transport. Several endpoints in the campaign used plain http.
• Be careful with flags that allow installing missing apps: an uncontrolled installNotExists=true is an open door.
• IoT/embedded devices can be recruited even without valuable local data: the value for the attacker is connectivity and the IP address, not the content.

Brazil's aftermarket head unit market is large and relies heavily on imported firmware with little visibility into the build chain. It remains unclear how many devices were affected globally and whether the specific model reached the country, but the indicators of compromise (hashes, domains and IPs such as 144.217.243[.]201) are published in Kaspersky's report for anyone who wants to cross-check them against their own logs.