Skip to main content
Emerging ThreatsMalware & Ransomware

Malware Targets Automotive Head Units

Car interior with head unit screen displaying a blank interface, dashboard, center console, and plugged-in smartphone…

"While monitoring Android threats in June 2026, we discovered a new piece of Android malware," Kaspersky reported — and that discovery reached into an unexpected place: the Android-based head units that sit in many cars.

How a legitimate updater, TWCore, became an infection vector

The delivery method was not a phishing SMS or a sideloaded app from an unknown store. Instead, attackers abused a legitimate system application named TWCore (package name com.tw.core) that is responsible for analytics and firmware updates on certain Android-based DoFun head units. TWCore receives update instructions via an MQTT broker hosted on cardoor[.]cn. Those messages include an installNotExists boolean flag that controls whether the updater will install applications not already present on the device; TWCore only checks whether an app is installed when installNotExists is false.

APK files are downloaded to the head unit path <TWCore external cache dir>/push/apk/ for installation. Kaspersky’s telemetry found previously unknown malware in that directory and observed that, in every case, the malicious APKs were installed by an app with the com.tw.core package name. The vendor reported fixing the security issues after being notified.

The multi-stage malware chain: JarService → loader → zhima

The malicious payload observed by Kaspersky unfolds in three stages. Stage 1 is a dropper called JarService: a UI-less app that decrypts encrypted blocks embedded in its code to load the next stage. The analyzed JarService version pointed to the wa method of com.c.j.qbh as the entry for stage 2.

Stage 2 is a loader that uses reflection to run a stage 3 payload. The loader posts device and implant information to attacker-controlled C2 servers (an example POST includes fields such as userId, dexVersion, channelId, packageName: "com.tw.jar1", appVersion and appName: "JarService"). The loader receives a dexUrl in response (examples include hxxp://144.217.243[.]201/vr34der34/dex3.68.png) and uses numeric and floating-point keys to decrypt and load the next payload.

Stage 3 is a clicker and reverse-proxy loader. It reports device characteristics to /cpc/api/task roughly every 90 minutes and receives either updated configuration (the report shows a most up-to-date configVersion 3.820 with hosts such as hxxp://t2.kshahnd[.]sbs and an updates array) or integer productId command identifiers. The malware implements a range of commands — including http, web, loadlib2 (used to download and execute arbitrary code), deeplink and traceroute — but in real attacks the operators mainly used loadlib2 and http to fetch and run additional modules.

Zhima: a reverse-proxy module and the botnet goal

The payload delivered via loadlib2 is a reverse proxy module named "zhima." Nokia’s Deepfield Emergency Response Team independently discovered zhima in TV set-top boxes around the same time, confirming the module’s role in building a proxy botnet. Kaspersky recovered multiple zhima variants (the report lists eight identified zhima module hashes including de77c3303e93c9450424759f1741441c) and found the module’s C2 infrastructure and admin panel accessible at admin.uipoxy[.]com (resolving to 128.14.210[.]58).

The admin panel hosted at hxxp://admin.uipoxy[.]com/proxy/u/login appears to allow registrations with a valid invite code and links to terms hosted under pxyedge[.]com — a domain tied to a residential-proxy vendor named PXYEDGE — and contains references to proxyforu[.]com. Kaspersky therefore links the infrastructure and services to the actors operating the malware.

Attribution: MoYu Group and ties to BADBOX

Kaspersky attributes the activity with high confidence to the MoYu Group, a threat actor previously linked to the BADBOX platform. The assessment rests on several facts found during analysis: the stage‑2 loader creates a thread named mosdk-host-loader; a related malicious TV set-top box app used an AdmoyuService component; and there is substantial overlap between the network infrastructure used by the head‑unit malware and infrastructure independently associated with MoYu Group by Nokia and HUMAN researchers.

Indicators of compromise and observed infrastructure

  • Detections: HEUR:Trojan‑Dropper.AndroidOS.Agent.vu; HEUR:Trojan‑Downloader.AndroidOS.Agent.ov; HEUR:Trojan‑Proxy.AndroidOS.Zhima.*; HEUR:Trojan.AndroidOS.Vo1d.* (per Kaspersky)
  • Notable domains and hosts: cardoor[.]cn (MQTT broker), ovcloudcontrol.cdn.cardoor[.]cn (APK download paths), admin.uipoxy[.]com, pxyedge[.]com, proxyforu[.]com; other domains include kshahnd[.]sbs, mdsjhd[.]sbs, nmnsny[.]sbs and kookjar[.]com
  • Observed IPs used by payloads or C2: 144.217.243[.]201; 107.151.248[.]132; 128.14.210[.]58
  • Sample APK download addresses used to deliver JarService: hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk (and earlier dates listed)
  • Hashes: TWCore legitimate installer hashes (three listed) and multiple malware hashes for stages 1–3 and zhima modules are provided in Kaspersky’s report

What this means for automotive vendors, security teams, and proxy services

  • Automotive vendors and head‑unit OEMs should note that a system updater capable of installing apps without robust verification can become a distribution channel for multi-stage malware; Kaspersky notified the vendor and it reported fixing the security issues.
  • Security teams operating device fleets or connected-car telemetry should watch for the indicators above (com.tw.core installations, APKs in TWCore cache paths, and connections to the listed hosts and IPs) and for unexpected background services such as JarService and zhima.
  • Proxy vendors and providers named in the infrastructure (PXYEDGE, ProxyForU) are implicated by domain and API similarities; their public-facing signup and admin APIs mirrored aspects of the malware’s admin panel, linking commercial proxy services to the botnet operator’s tooling.

The case changes a simple calculus: head units are not merely vehicles for infotainment; when an updater can install apps silently, it becomes a conduit for recruitment into large-scale proxy botnets. Kaspersky’s report supplies the technical trail — from MQTT messages on cardoor[.]cn to the zhima admin panel on admin.uipoxy[.]com — and leaves a clear set of artifacts for defenders to block and investigate.

Source: https://securelist.com/android-head-unit-malware/121106/