14 minhigh
The invisible passenger in your car
Kaspersky identified a multi-stage Android downloader distributed through the built-in update functionality of DoFun-based automotive head unit firmware. The legitimate TWCore system app receives MQTT-based instructions that allow installation of apps not already present on the device, which attackers abused to deliver a JarService dropper that chains through a loader, a clicker/loader, and finally a reverse proxy module (zhima) that recruits the device into a proxy botnet. The activity is attributed with high confidence to MoYu Group based on code artifact naming, thread names, and infrastructure overlap with a related implant found on TV set-top boxes.
Conf:high
Showing defanged values
- domainadmin[.]uipoxy[.]comHosts the zhima proxy botnet operator login/registration panel, linked to MoYu Group infrastructure
- domaincardoor[.]cnDomain hosting the MQTT broker subdomain (ovcloudcontrol.cdn.cardoor.cn) used by the legitimate TWCore app to distribute the JarService dropper as an update
- domainishano456[.]sbsDomain associated with malware C2 infrastructure identified in indicator list
- domainkookjar[.]comDomain used in an http command task contacted by stage 3 payload as part of the C2 infrastructure
- domainkshahnd[.]sbsC2 host used by stage 3 clicker/loader to fetch updated configuration and commands
- domainmdsjhd[.]sbsC2 host used by stage 3 clicker/loader to fetch updated configuration and commands
- domainnmnsny[.]sbsC2 host used by stage 3 clicker/loader to fetch updated configuration and commands
- domainproxyforu[.]comResidential proxy vendor domain referenced via copyright string on the malware operator registration panel
- domainpxyedge[.]comResidential proxy vendor domain hosting terms of use/privacy policy linked from the malware operator registration panel
- domainty4523[.]spaceDomain associated with malware C2 infrastructure identified in indicator list
- domainty54fgd435[.]myDomain associated with malware C2 infrastructure identified in indicator list
- domainue886578433[.]onlineDomain associated with malware C2 infrastructure identified in indicator list
- domainxmsae[.]sbsDomain associated with malware C2 infrastructure identified in indicator list
- domainxshaon123[.]sbsDomain associated with malware C2 infrastructure identified in indicator list
- filename<TWCoreexternalcachedir>/push/apk/Directory path used by TWCore to download and stage malicious APK files for silent installation
- ip107[.]151[.]248[.]132C2 address passed as a connection parameter to the zhima reverse proxy module via the loadlib2 command
- ip128[.]14[.]210[.]58C2 server used by zhima proxy module; also resolves from the domain admin.uipoxy.com hosting the malware operator admin panel
- ip144[.]217[.]243[.]201C2 server hosting stage 3 payload downloads (dex files) and the zhima reverse proxy module payload
- md50fbaa7092204f4b1494e0b840b014774Stage 3 loader/clicker payload variant
- md51dcf031c40ce456b6a36a00b0acf3d11Stage 3 loader/clicker payload variant
- md52a64c3efc11bf224aa54f24e876446c9Legitimate TWCore software sample abused to distribute the JarService dropper
- md53ad4bf5a86d26ffbf09cae42af330a98Malicious app com.abc.nexus found on TV set-top boxes, source of attribution artifact AdmoyuService
- md5412e9243f2981bbea3894254d105b3b8zhima reverse proxy module variant
- md544b6b213a6a3f299eaf88e078de95ecbStage 3 loader/clicker payload variant
- md567dc78e544ebce16b85dc7c195dfbc58Stage 3 loader/clicker payload variant
- md56c2e34b30da42085240ede53ab6107d4JarService dropper sample
- md571ab5517f71866279d0d87d37f2ae320zhima reverse proxy module variant
- md57a4d3ba2dacccfdda55859a5dfee2671Legitimate TWCore software sample abused to distribute the JarService dropper
- md589ef78f716a75964539f2db6520be362zhima reverse proxy module variant
- md58b5e513144a6138a966ea59e68bf9da2JarService dropper sample
- md59642ae619b3165d23c6349002d1abe24Stage 3 loader/clicker payload variant
- md5a4223ce4288a230d1e6c3ff2c7639045zhima reverse proxy module variant
- md5b067d5b0dbecbd6498bcdfba45dba77eStage 3 loader/clicker payload variant
- md5ba27951b4ee1c341f4415d033369ecd3JarService dropper sample
- md5bd4d81cd27125ad3d9a114922d468499zhima reverse proxy module variant
- md5c6bfb1643ac7474ed8a7b4f96a187fdbzhima reverse proxy module variant
- md5d63bacd6d6709dd68a10ef9d374c7835JarService dropper sample
- md5de77c3303e93c9450424759f1741441czhima reverse proxy module referenced in C2 loadlib2 command response
- md5e119845877089d6f4b0a70dc7388f316JarService dropper sample
- md5e9f3a0dab6949ce2cddab9e0aa80ae1aStage 2 loader payload sample
- md5ea24487996eb70c1780922fb3063bcc5Legitimate TWCore software sample abused to distribute the JarService dropper
- md5f0e3f7eba2cde91e2dedb921bab47422Stage 3 loader/clicker payload variant
- md5f8cf8c23ff597700d471fb7767df8baczhima reverse proxy module variant
- urlhxxp://144[.]217[.]243[.]201/vr34der34/dex3[.]68[.]pngStage 3 payload download URL disguised with a .png extension
- urlhxxp://144[.]217[.]243[.]201/vr34der34/sh65[.]ioDownload URL for the zhima reverse proxy module payload delivered via the loadlib2 command
- urlhxxp://admin[.]uipoxy[.]com/proxy/u/loginLogin page for the zhima proxy botnet admin panel used by operators
- urlhxxp://ovcloudcontrol[.]cdn[.]cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad[.]apkMalicious APK download URL delivered via TWCore update mechanism
- urlhxxp://ovcloudcontrol[.]cdn[.]cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04[.]apkMalicious APK download URL delivered via TWCore update mechanism
- urlhxxp://ovcloudcontrol[.]cdn[.]cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5[.]apkMalicious APK download URL delivered via TWCore's update mechanism, containing the JarService dropper
- urlhxxps://api[.]kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}C2 endpoint contacted via an http task command for tracking/reporting
- urlhxxps://proxyforu[.]comResidential proxy service website linked from the malware operator panel copyright notice
![hxxp://144[.]217[.]243[.]201/vr34der34/dex3[.]68[.]png](/iocs/url/http%3A%2F%2F144.217.243.201%2Fvr34der34%2Fdex3.68.png){kind=link}
Detection / HunterAnthropic
What Happened
Security researchers found a new type of malicious software that infects the entertainment and control screens (called head units) built into some cars. Instead of tricking a driver into installing something, the malware exploits the head unit's own automatic software update system to secretly install itself, without the owner noticing anything unusual since there is no visible app icon or interface. Anyone driving a car with this specific head unit firmware could be affected, and once infected, the device is quietly turned into part of a network used for fraud (like faking ad clicks) or hidden internet proxy services. This matters because it shows attackers are expanding malware distribution beyond phones and set-top boxes into vehicles, an area with less security scrutiny. Owners of affected vehicles should check for firmware updates from their vendor and manufacturers should audit their update mechanisms for similar abuse potential; the vendor in this case has reportedly already fixed the underlying issue after being notified.
Key Takeaways
- A multi-stage Android downloader was found being distributed through the built-in update mechanism of car head unit firmware, marking the first documented case of malware delivered specifically through an automotive head unit's software update chain.
- The infection begins with a legitimate system app, TWCore, which receives MQTT messages instructing it to download and silently install APK files, including ones not previously present on the device via an installNotExists flag.
- The infection chain progresses through four stages: JarService dropper, an intermediate loader, a clicker/loader payload, and a reverse proxy module named zhima, which turns infected devices into nodes in a proxy botnet.
- The malware's final payload matches a proxy module independently identified by Nokia Deepfield researchers on TV set-top boxes, indicating shared infrastructure and tooling across device types.
- Researchers attribute the activity with high confidence to MoYu Group, an actor linked to the BADBOX botnet, based on code artifacts (thread name mosdk-host-loader), naming overlap with a set-top box implant, and infrastructure overlap with known MoYu Group proxy services.
Affected Systems
- Android-based automotive head units running DoFun firmware
- Devices with the TWCore system application (package name com.tw.core)
- Android-based TV set-top boxes (related campaign infrastructure)
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: MQTT message broker on a subdomain of cardoor.cn instructs the legitimate TWCore head unit update app to download and install an APK, including apps not previously installed via the installNotExists flag.
- Execution: TWCore downloads the APK to a push/apk cache directory and silently installs it, delivering the JarService dropper (stage 1) with no user interface.
- Payload Decryption: JarService decrypts XOR-encrypted blocks containing information about the next stage's entry point and code, then loads the stage 2 loader.
- C2 Communication: The stage 2 loader reports implant details to a C2 server via POST request and receives a versioned download link for the stage 3 payload.
- Secondary Payload Execution: Stage 3 clicker/loader periodically polls C2 servers for configuration updates and command tasks, executing commands such as loadlib2 to download and run additional modules.
- Proxy Botnet Recruitment: The loadlib2 command downloads and executes the zhima reverse proxy module, converting the infected device into a SOCKS5/HTTP proxy node as part of a larger proxy botnet used for ad fraud and traffic relay.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
- Platforms: Kaspersky
The article states that Kaspersky solutions detect the described threats under specific proprietary verdict names (e.g., HEUR:Trojan-Dropper.AndroidOS.Agent.vu, HEUR:Trojan-Downloader.AndroidOS.Agent.ov, HEUR:Trojan-Proxy.AndroidOS.Zhima., HEUR:Trojan.AndroidOS.Vo1d.). No YARA, Sigma, Snort/Suricata, or query-language detection content is provided in the article.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | Automotive head units typically lack endpoint detection and response tooling, and this malware runs without a visible UI, making behavioral detection reliant on mobile threat defense or manual firmware inspection rather than conventional EDR. |
| Network Visibility | Medium | If network monitoring exists for head unit connectivity (e.g., cellular/SIM data usage), outbound connections to the identified C2 domains and IPs, along with periodic beaconing at fixed intervals (e.g., every 90 minutes), could be observed, but most consumer and fleet networks likely lack this visibility. |
| Detection Difficulty | Hard | The malware abuses a legitimate, pre-trusted system application's update functionality rather than exploiting a vulnerability, and it has no user interface, so typical user-facing indicators of compromise (icons, permission prompts) are absent. Detection depends on identifying anomalous update payloads, unexpected package installations, or beaconing patterns. |
Required Log Sources
- DNS query logs
- Proxy/firewall logs for outbound HTTP/HTTPS connections
- MQTT broker connection logs on head unit gateways
- Application installation logs on Android-based head units
- Mobile threat defense or Android package manager telemetry
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for Android package installation events on head unit or vehicle infotainment devices where the installing application is a system updater and the installed package has no corresponding icon or UI, consistent with silent installation. | Package manager installation logs, application inventory snapshots | Execution / Persistence | Medium - some legitimate silent system updates may also lack visible UI, requiring correlation with unusual package names or install sources |
| Consider hunting for outbound network connections from head unit or embedded device IP ranges to newly registered or low-reputation domains using unusual TLDs (e.g., .sbs, .my, .online, .space) at fixed periodic intervals. | DNS logs, proxy/firewall connection logs, NetFlow | Command and Control | Low - periodic beaconing to unusual TLDs from embedded devices is uncommon in normal automotive telemetry traffic |
| Consider hunting for MQTT broker traffic where update messages include a flag enabling installation of apps not already present on the device, since this deviates from expected update-only behavior. | MQTT broker application logs, update service logs | Initial Access | Medium - some legitimate deployment scenarios may use similar flags for provisioning new devices |
| Consider hunting for processes or threads on embedded Android devices with names referencing loader or SDK components inconsistent with the device's known legitimate software inventory. | Process/thread listings from mobile threat defense tooling if deployed | Execution | Low - custom thread naming matching known malicious patterns is unlikely to occur in benign software |
| Consider hunting for devices establishing SOCKS5 or HTTP proxy listener behavior unexpectedly, which would indicate recruitment into a proxy botnet. | Network flow analysis, port/listener enumeration on managed devices | Impact / Command and Control | Low - proxy listener behavior is atypical for consumer automotive infotainment systems |
Control Gaps
- Standard antivirus and mobile security apps are generally not deployed on automotive head units, leaving these devices unmonitored
- Trust in built-in vendor update mechanisms means malicious payloads delivered through them may bypass app store vetting and code-signing checks that would apply to sideloaded apps
- Lack of visibility into MQTT-based update protocols used by proprietary vendor update systems limits network-based detection
- No app store review process applies to first-party system app updates, removing a common control point for catching malicious payloads
Key Behavioral Indicators
- Presence of an installed application with no launcher icon or user interface installed via a system update service
- Package installation events initiated by a system updater application where the target package was not previously present on the device
- Periodic outbound HTTP/HTTPS beaconing at a fixed interval (e.g., every 90 minutes) to domains under uncommon TLDs
- Presence of SharedPreferences-stored serialized JSON configuration data referencing command identifiers (productId) not part of the legitimate app's known functionality
- Creation of application threads with SDK-like or loader-like naming conventions inconsistent with the parent app's documented purpose
False Positive Assessment
Medium - some detection hypotheses, such as periodic beaconing or silent app installation via system updaters, could overlap with legitimate vendor telemetry or provisioning processes, requiring correlation with specific domain, package name, or behavioral indicators identified in this report to reduce false positives.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. If you manage a fleet of vehicles or devices using DoFun-based head unit firmware, consider checking for and applying any vendor-issued firmware or TWCore application updates addressing this distribution issue.
- If network visibility into head unit or embedded device traffic exists, consider blocking outbound connections to the domains and IP addresses identified in this report at the DNS or firewall layer.
- Consider auditing installed packages on managed Android-based head units for the presence of unfamiliar package names such as com.tw.jar or com.tw.jar1, or applications lacking a visible UI or launcher icon.
Infrastructure Hardening
- Evaluate whether update mechanisms in embedded/IoT and automotive firmware restrict installation to only pre-approved, previously installed application package names, rather than allowing arbitrary new package installation.
- Consider implementing code-signing verification and integrity checks for any application delivered through proprietary update channels such as MQTT-based update brokers.
- If applicable, evaluate segmenting head unit network connectivity from other in-vehicle systems to limit the impact of a compromised infotainment component.
- Consider requiring vendors to disclose and restrict use of flags similar to installNotExists that permit silent installation of previously absent applications.
User Protection
- Where supported, consider deploying mobile threat defense or endpoint monitoring solutions capable of covering Android-based embedded devices, including automotive head units.
- Consider monitoring device data usage patterns for anomalies consistent with proxy or ad-fraud activity, such as unexpected data volume from infotainment systems.
- If your organization procures vehicles or fleet devices with Android-based head units, consider requesting security assessments of the update mechanism from vendors prior to procurement.
Security Awareness
- Consider raising awareness among fleet managers, procurement teams, and IT security staff that automotive head units and other embedded Android devices are potential targets for supply-chain style malware distribution.
- Consider including automotive and IoT device security considerations in existing vendor risk assessment processes.
- Consider educating relevant technical staff on how legitimate update mechanisms can be abused to distribute malware, using this case as a reference example.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping8 techniques
Tactic
Initial Access
Tactic
Stealth
Tactic
Defense Impairment
Tactic
Command and Control
Additional IOCs
- Domains:
xmsae[.]sbs- Domain associated with malware C2 infrastructure identified in indicator listishano456[.]sbs- Domain associated with malware C2 infrastructure identified in indicator listxshaon123[.]sbs- Domain associated with malware C2 infrastructure identified in indicator listty54fgd435[.]my- Domain associated with malware C2 infrastructure identified in indicator listue886578433[.]online- Domain associated with malware C2 infrastructure identified in indicator listty4523[.]space- Domain associated with malware C2 infrastructure identified in indicator listpxyedge[.]com- Residential proxy vendor domain hosting terms of use/privacy policy linked from the malware operator registration panelproxyforu[.]com- Residential proxy vendor domain referenced via copyright string on the malware operator registration panel
- Urls:
hxxp://ovcloudcontrol[.]cdn[.]cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk- Malicious APK download URL delivered via TWCore update mechanismhxxp://ovcloudcontrol[.]cdn[.]cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk- Malicious APK download URL delivered via TWCore update mechanismhxxp://144[.]217[.]243[.]201/vr34der34/dex3.68.png- Stage 3 payload download URL disguised with a .png extensionhxxp://144[.]217[.]243[.]201/vr34der34/sh65.io- Download URL for the zhima reverse proxy module payload delivered via the loadlib2 commandhxxps://api[.]kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}- C2 endpoint contacted via an http task command for tracking/reportinghxxp://admin[.]uipoxy[.]com/proxy/u/login- Login page for the zhima proxy botnet admin panel used by operatorshxxps://proxyforu[.]com- Residential proxy service website linked from the malware operator panel copyright notice
- File Hashes:
ba27951b4ee1c341f4415d033369ecd3(MD5) - JarService dropper sampled63bacd6d6709dd68a10ef9d374c7835(MD5) - JarService dropper sample6c2e34b30da42085240ede53ab6107d4(MD5) - JarService dropper sample8b5e513144a6138a966ea59e68bf9da2(MD5) - JarService dropper samplee119845877089d6f4b0a70dc7388f316(MD5) - JarService dropper samplee9f3a0dab6949ce2cddab9e0aa80ae1a(MD5) - Stage 2 loader payload sample0fbaa7092204f4b1494e0b840b014774(MD5) - Stage 3 loader/clicker payload variant1dcf031c40ce456b6a36a00b0acf3d11(MD5) - Stage 3 loader/clicker payload variant44b6b213a6a3f299eaf88e078de95ecb(MD5) - Stage 3 loader/clicker payload variant67dc78e544ebce16b85dc7c195dfbc58(MD5) - Stage 3 loader/clicker payload variant9642ae619b3165d23c6349002d1abe24(MD5) - Stage 3 loader/clicker payload variantb067d5b0dbecbd6498bcdfba45dba77e(MD5) - Stage 3 loader/clicker payload variantf0e3f7eba2cde91e2dedb921bab47422(MD5) - Stage 3 loader/clicker payload variant412e9243f2981bbea3894254d105b3b8(MD5) - zhima reverse proxy module variant71ab5517f71866279d0d87d37f2ae320(MD5) - zhima reverse proxy module variant89ef78f716a75964539f2db6520be362(MD5) - zhima reverse proxy module varianta4223ce4288a230d1e6c3ff2c7639045(MD5) - zhima reverse proxy module variantbd4d81cd27125ad3d9a114922d468499(MD5) - zhima reverse proxy module variantc6bfb1643ac7474ed8a7b4f96a187fdb(MD5) - zhima reverse proxy module variantde77c3303e93c9450424759f1741441c(MD5) - zhima reverse proxy module referenced in C2 loadlib2 command responsef8cf8c23ff597700d471fb7767df8bac(MD5) - zhima reverse proxy module variant3ad4bf5a86d26ffbf09cae42af330a98(MD5) - Malicious app com.abc.nexus found on TV set-top boxes, source of attribution artifact AdmoyuService2a64c3efc11bf224aa54f24e876446c9(MD5) - Legitimate TWCore software sample abused to distribute the JarService dropper7a4d3ba2dacccfdda55859a5dfee2671(MD5) - Legitimate TWCore software sample abused to distribute the JarService dropperea24487996eb70c1780922fb3063bcc5(MD5) - Legitimate TWCore software sample abused to distribute the JarService dropper
- File Paths:
<TWCore external cache dir>/push/apk/- Directory path used by TWCore to download and stage malicious APK files for silent installation
- Other:
com.tw.core- Package name of the legitimate TWCore system app abused to install the malwarecom.tw.jar1- Package name reported by the stage 1 JarService dropper to the C2 servermosdk-host-loader- Name of a thread created by the stage 2 loader, used as an attribution artifact linking to MoYu Group