logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·01.11.26
← Back to news

Malware infects Android-based automotive head unit firmware

Original article
securelist.com|158 points|74 comments|by campuscodi|Aug 23, 2026

The Invisible Passenger: Android Malware in Automotive Head Units

While analyzing Android-based threats in June 2026, researchers identified a sophisticated new strain of malware. What made this discovery particularly striking was the app's behavior: it installed like a standard user application but possessed no user interface (UI) and made no effort to masquerade as a legitimate tool.

This lack of visibility suggested the software was infiltrating devices without user consent. Subsequent analysis allowed researchers to map the entire infection sequence.

🚩 Key Findings

  • Nature of Threat: A multi-stage downloader designed for ad fraud and the construction of a proxy botnet.
  • Vector: Distributed via the integrated firmware updaters of Android-based automotive head units.
  • Significance: This marks the first documented instance of malware specifically utilizing an infection chain tailored for car head units.
  • Attribution: High-confidence attribution to the MoYu Group, the actors behind the infamous BADBOX botnet.

🚗 Understanding Head Unit Firmware

A head unit is the central hub of a vehicle's dashboard, merging multimedia entertainment with controls for various car functions. These can be factory-installed or added as aftermarket upgrades.

Attack Surface

Historically, these systems are compromised via:

  1. Physical access.
  2. Vulnerabilities within the OS or specific components.

Many manufacturers utilize Android because its open-source nature allows for easy customization. Vendors can inject system applications during the build process to tailor the UI or add proprietary components. While most Android apps—including malware—can run on these units, not all are effective.

Malware Applicability Comparison

Malware CategorySmartphone TargetHead Unit TargetLogic/Nuance
Banking Trojans✅ High❌ LowBanking apps are rarely used on dashboards.
Botnet/Proxy✅ High✅ HighUnits have SIM slots/internet; ideal for IoT-style botnets.
Ad Fraud✅ High✅ HighConstant connectivity allows for background click fraud.

The firmware for DoFun head units specifically contained design flaws that enabled this distribution. The vendor has since been notified and reports that the security gaps have been patched.


🛠️ The Infection Mechanism

The breach centers around a legitimate system application called TWCore.

The Role of TWCore

TWCore is designed for two primary purposes:

  • Collecting analytics data.
  • Managing software updates for the head unit.

The Update Process

The update mechanism relies on an MQTT message broker located at the subdomain cardoor[.]cn. This broker pushes messages containing details about APK files that the device should download.

A critical vulnerability exists in the message object's installNotExists field. This is a Boolean flag that determines the installation logic:

If installNotExists=True  ⟹  Install APK regardless of whether it exists on the device.\text{If } \text{installNotExists} = \text{True} \implies \text{Install APK regardless of whether it exists on the device.}If installNotExists=True⟹Install APK regardless of whether it exists on the device.

Essentially, TWCore only updates existing apps →\rightarrow→ TWCore can be forced to install entirely new, unauthorized apps.

Infection Workflow

The following task list describes the sequence of events during a compromise:

  • MQTT broker sends a command to the head unit.
  • TWCore receives the APK metadata.
  • The APK is downloaded to the external cache directory: /push/apk/.
  • The system executes the installation via the com.tw.core package.

🔍 Technical Breakdown of the Payload

The malware operates in three distinct phases to evade detection and achieve its goals:

  1. Stage 1: The JarService Dropper The initial entry point that prepares the environment for further payloads.
  2. Stage 2: The Loader A secondary component that fetches the final malicious modules.
  3. Stage 3: The Clicker / Reverse Proxy The "business end" of the malware, used for generating fraudulent ad revenue and routing traffic for the botnet.

Visual Evidence

Below are the components of the infection chain as identified during analysis:

Head unit infection scheme Figure 1: Overview of the infection flow.

TWCore logic Figure 2: The logic governing the installNotExists flag.

File Paths Figure 3: The specific directory used for malicious APK storage.


🛡️ Detection and Indicators

Kaspersky identifies these threats using the following detection signatures:

  • HEUR:Trojan-Dropper.AndroidOS.Agent.vu
  • HEUR:Trojan-Downloader.AndroidOS.Agent.ov
  • HEUR:Trojan-Proxy.AndroidOS.Zhima.*
  • HEUR:Trojan.AndroidOS.Vo1d.*

Summary of Indicators (IoCs)

The investigation tracked several key markers:

  • Domains: cardoor[.]cn
  • Package Name: com.tw.core
  • Storage Path: /push/apk/

For more detailed technical data, refer to the full list of hashes for TWCore and the associated zhima modules in the original research logs.

Banner