SUNG-HEE

JarService / zhima Malware Entering via Insecure Android Car Head Unit Update Paths

작성자

카테고리:

← 피드로
DEV Community · Anoymask · 2026-08-23 개발(SW)

1. Basic Information

2. Summary

A supply chain attack that distributes multi-stage Android malware through the official TWCore car software update app, turning head units into ad fraud and proxy relay nodes for external traffic.

3. Attack Flow

1. Distribution via Official Update Path

  1. The official system app TWCore on DoFun head units receives APK installation instructions from an MQTT broker under cardoor[.]cn.
  2. Enabling the installNotExists instruction allows the installation of new apps that are not yet on the device.
  3. The malicious JarService APK is downloaded and installed into the external cache directory of TWCore via this official update feature without user interaction.

2. From JarService to Stage 3

  1. The headless JarService decrypts an internal XOR-encrypted block and runs the second-stage loader.
  2. The second stage sends device and implant info to the C2 via HTTP POST and fetches the encrypted third stage from the dexUrl in the response.
  3. By default, the third stage reports the device model, screen resolution, connected Wi-Fi SSID, MAC address, and other details to the C2 every 90 minutes to receive configurations and commands.

3. Observed Monetization

  1. The commands actually used by the attacker during analysis were loadlib2 (to fetch and run arbitrary modules) and http (to access specified URLs).
  2. The loadlib2 command loads the zhima reverse proxy module and turns the infected device into a relay node for external traffic.
  3. The http command generates web traffic to use for ad click fraud.

4. Attacker Position and Execution Location

  • The malicious APK is distributed through the official TWCore update feature, but the specific method the attacker used to enable this distribution is not public.
  • TWCore, JarService, the second/third stages, and zhima run on the Android car head unit.
  • The C2, payload distribution server, and zhima management infrastructure are on the internet.
  • The article does not mention root access or privilege escalation. JarService is installed as a regular user app.

5. Visibility for Victims and Administrators

Victims

  • The official update feature handles everything automatically, so users do not need to click or manually install an APK.
  • JarService has no user interface, making the infection hard to spot on the car display.
  • Kaspersky has not seen any interference with driving operations or critical vehicle controls.

Administrators and SOCs

  • Android head units are usually outside the management scope of corporate EDRs, so APKs, processes, and C2 traffic may not be directly visible.
  • If cellular data, mobile routers, or corporate Wi-Fi can be monitored, periodic HTTP traffic to listed domains/IPs or unexpected outbound proxy traffic can be clues.
  • An unknown APK is placed under the TWCore cache directory, and com.tw.core is recorded as the installer.

6. Success and Failure Conditions

Success Conditions

  • The TWCore update feature is enabled on target head units running DoFun software.
  • The attacker can deliver instructions to install a new APK through the official update channel.
  • The head unit can connect to MQTT, the APK distribution server, and the C2.
  • The execution of JarService and subsequent DEX/modules is not blocked on the device.

Failure Conditions

  • Security fixes reported by DoFun stop the further distribution of malicious APKs. Public information does not show the fix details, whether target devices need updates, or the fixed version number.
  • Strong signature verification and allowlists are applied to update instructions and APKs to reject unknown packages.
  • Listed IOCs, unknown APKs, and JarService are detected to isolate the device before the subsequent loader runs.
  • C2 and zhima communications are blocked at the exit point to stop the retrieval of commands and additional modules.

7. What Happens Upon Success

  • The head unit is used for ad display and ad click fraud.
  • zhima abuses the IP address of the car’s cellular network or connected network as a relay point for third-party traffic.
  • Device models, resolutions, Wi-Fi SSIDs, MAC addresses, and other details are sent to the C2.
  • Additional code can be fetched and run via the implemented loadlib2.
  • No impact on vehicle driving or control functions has been confirmed.

8. Observable Logs

Email

  • This is not an email-based entry vector, so no related email logs are expected.

Proxy / SWG / DNS

  • MQTT/APK download traffic to destinations under cardoor[.]cn
  • DNS/HTTP traffic to kshahnd[.]sbs, mdsjhd[.]sbs, nmnsny[.]sbs, kookjar[.]com, etc.
  • DEX/zhima retrieval from 144.217.243[.]201
  • zhima-related traffic with 107.151.248[.]132 or 128.14.210[.]58

Endpoint / EDR

  • Unknown APKs under <TWCore external cache dir>/push/apk/
  • JarService installed by com.tw.core (e.g., com.tw.jar1)
  • Listed hashes for JarService, the second-stage loader, the third stage, and zhima
  • Loaded classes mentioned in the article, such as com.ast.sdk.BillingMain.init and com.miyc.transfer.Client

Identity / IdP

  • This attack does not abuse IdP or user account authentication, so no related logs are described in the article.

SaaS / Cloud

  • Check the vendor’s MQTT/update infrastructure for distribution instructions and download history of unknown APKs.
  • Authentication, configuration changes, and distribution job audit logs on the update infrastructure are important to find the breach origin, but they are not public.

Network

  • POST requests from the third stage to /cpc/api/task at about 90-minute intervals
  • Traffic switching to multiple *.sbs hosts after C2 configuration updates
  • Relay traffic from the car terminal to many unexpected external destinations

9. Attack Success Determination

Attack Attempt Observed (Success Unconfirmed)

Only update instructions or malicious APK download requests are confirmed in the update infrastructure or network; saving or running them on the device is unconfirmed.

User Action Confirmed

No user actions are needed for this chain. Do not use manual actions as a success condition.

Initial Execution Confirmed

Confirm either the saving of JarService to the TWCore cache, package installation, or JarService startup.

Malware Execution or Authentication Success Confirmed

Confirm loading of the second/third stages, implant registration with the C2, or periodic traffic to /cpc/api/task.

Data Theft or Session Compromise Confirmed

Confirm the C2 transmission of SSIDs, MAC addresses, and device info. Authentication session theft is not mentioned in the article.

Subsequent Compromise Confirmed

Confirm the loading of zhima, proxy relay, HTTP commands for ad fraud, or the execution of another additional module.

10. Investigation Playbook

Trigger

  • Traffic from DoFun head units to listed IOCs
  • Records of unknown APKs installed via TWCore
  • Unnatural and diverse relay traffic from car network connections to external destinations

Initial Check

  • Identify the target head unit’s manufacturer, model, DoFun software/TWCore presence, and firmware version.
  • Link the communication time, SIM/network, connected Wi-Fi, and vehicle/department.
  • Do not judge by IOC matches alone; confirm the timeline of APK retrieval, package installation, and C2 registration.

Endpoint

  • Collect the TWCore cache, installed packages, and hashes of APK/DEX/native modules.
  • Preserve the installation history of com.tw.core, JarService startup, and commands saved in SharedPreferences.
  • If device imaging is difficult, ask the vendor or car equipment management team for analysis.

Authentication / Cloud

  • Check authentication logs, management operations, and distribution jobs for MQTT and update infrastructures managed by DoFun or operations teams.
  • Identify the range of car devices that received the same update instructions and the distributed APK URLs.
  • If connected to corporate Wi-Fi, check for SSID exposure and abnormal traffic from that network.

Subsequent Actions

  • Check the third stage’s productId, loadlib2, and http commands along with their execution results.
  • Identify connection destinations, traffic volume, and relay periods caused by zhima.
  • Search across Android/IoT devices for additional payloads, ad fraud, or identical IOCs.

Containment

  • Disconnect the suspected head unit from the internet and corporate Wi-Fi.
  • Block listed C2s and distribution points via DNS/FW, and inspect all devices of the same model in bulk.
  • Check the fix content and recovery steps provided by the vendor. If device updates are required, apply the fixed software/firmware. If integrity cannot be confirmed, consider reinitializing or replacing the device.
  • Organizations managing update infrastructure must rotate credentials/keys and audit distribution history.

Judgment Categories

  • Distribution instruction/download request only
  • JarService saved/installed
  • Multi-stage loader/C2 established
  • Device info sent
  • zhima relay/ad fraud established

11. Defense and Detection Ideas

Single Event

  • New installation of unknown packages by TWCore
  • DNS/HTTP connections to listed IOCs
  • Detection of listed hashes for JarService or zhima

Timeline Correlation

  • MQTT update instruction -> APK saved to TWCore cache -> unknown package installed -> C2 POST
  • JarService startup -> third-stage DEX retrieval -> /cpc/api/task every 90 minutes -> zhima connection

Hunting Perspectives

  • Headless apps installed by com.tw.core
  • History of <TWCore external cache dir>/push/apk/ and listed JarService distribution URLs
  • loadlib2 command, zhima, mosdk-host-loader, com.miyc.transfer.Client
  • Devices in car/Android/IoT segments sharing the same C2 or periodicity

Log Gaps

  • Package/process/file telemetry on car Android devices
  • DNS, destination, and traffic logs for car SIMs or telematics networks
  • Vendor update infrastructure MQTT messages and management operation audits
  • Asset mapping between head units and corporate Wi-Fi usage history

Priority Actions

  • Inventory car devices running DoFun software and check the vendor’s fix details and whether they apply to target devices.
  • Isolate car/IoT devices from business networks and allow only necessary outbound traffic.
  • Implement operations that can verify update package signatures, distribution sources, and new app installations.
  • Visualize outbound traffic, including car network connections.

12. Facts / Inference / Hypothesis

Facts

  • Kaspersky observed an incident in June 2026 where TWCore installed JarService on a DoFun Android car head unit.
  • JarService has no UI; it decrypts and runs an XOR-encrypted second stage.
  • The third stage sends device info to the C2 and implements nine types of commands.
  • Commands confirmed in real attacks were loadlib2 and http, used for the zhima reverse proxy and ad fraud.
  • Kaspersky attributed the activity to the MoYu Group with high confidence.
  • DoFun informed Kaspersky that it fixed the security issues.
  • No interference with driving operations or critical vehicle controls has been confirmed.

Inference

  • Standard SOCs often cannot directly monitor car head units, so correlating Wi-Fi, SIM, and firewall logs with asset inventories is the main investigation method.
  • When company vehicles connect to corporate Wi-Fi, proxy relay traffic may be misidentified as coming from internal devices.
  • Nokia Deepfield identified design flaws in zhima’s local network destination filter. For infected devices connected to corporate Wi-Fi, investigating the impact on the connected network, in addition to outbound proxy traffic, is valuable. However, internal network compromises using MoYu exit nodes have not been proven.

Hypothesis

  • Update infrastructure credential compromise, abuse of management features, and distribution setting tampering are candidates, but the specific method that enabled the malicious APK distribution is unknown.

13. MITRE ATT&CK Mapping

Mapped using Android Mobile ATT&CK:

  • T1474.003 Supply Chain Compromise: Compromise Software Supply Chain (Confidence: high) — Distribution of malicious APKs through the official TWCore update feature. The specific method enabling distribution is unknown.
  • T1544 Ingress Tool Transfer (Confidence: high) — Fetching subsequent DEX and zhima from C2 response URLs.
  • T1437.001 Application Layer Protocol: Web Protocols (Confidence: high) — Device registration and retrieval of configurations/commands via HTTP POST.
  • T1604 Proxy Through Victim (Confidence: high) — Using the device as a relay node for external traffic via zhima.
  • T1406 Obfuscated Files or Information (Confidence: high) — Multi-stage code and strings encrypted with XOR.
  • T1646 Exfiltration Over C2 Channel (Confidence: medium) — Sending device info over the same C2 channel.

14. Unknowns and Further Investigation

  • The specific method that allowed malicious APK distribution via the official TWCore update feature
  • Specific affected models, firmware versions, regions, and infection counts
  • Fixes implemented by DoFun and methods to remove JarService from already infected devices
  • Presence of root access, auto-start after reboot, and extra permissions
  • Destinations and purposes of third-party traffic relayed through zhima
  • Sales, usage, and infection status globally

15. Impact on SOCs and General Enterprises

If company cars, logistics vehicles, or shuttle vans use aftermarket or built-in Android head units running DoFun software, they can become part of a botnet outside of standard IT asset management and EDR visibility. Inventorying devices, firmware, and connections, and isolating car/IoT devices from internal networks are practical priority steps. If devices connected to corporate Wi-Fi, check for impacts on the connected network based on zhima’s imperfect destination filters, in addition to outbound proxy activities. However, internal network compromises by MoYu have not been proven. Because public information does not specify local sales, usage, or infection status, confirm the presence of target products before deciding the response scope.

16. Summaries by Target Audience

For SOCs

Look for listed IOCs, unknown APKs via TWCore, C2 traffic with a ~90-minute period, and unnatural relay traffic from car network connections. If device logs are unavailable, use network and asset data as starting points.

For Administrators

Inventory head units running DoFun software, and verify vendor-provided fixes, target device applicability, recovery steps, and network isolation.

For Users

Infections are invisible even if the car screen looks normal. Do not reinitialize or delete APKs arbitrarily; contact management or the dealer with the model number and update status.

원문에서 계속 ↗

추출 본문 · 출처: dev.to · https://dev.to/anoymask/jarservice-zhima-malware-entering-via-insecure-android-car-head-unit-update-paths-221l

더 많은 게시물