Loading malware…
Zhima is an Android reverse-proxy malware module used to convert compromised devices into residential proxy nodes. It has been observed as a later-stage payload in a multi-stage malware chain targeting Android-based automotive head units running DoFun software, where attackers abused the legitimate TWCore update mechanism to install intermediary components that ultimately downloaded and executed zhima. The same module has also been documented on Android TV and set-top box ecosystems associated with the BADBOX operation, indicating reuse across consumer Android device classes.
On infected systems, zhima is delivered through a loader command that retrieves additional code and invokes the module dynamically. Its role is to establish outbound connections to operator-controlled relay infrastructure and forward third-party traffic through the victim device, effectively enrolling the device into a proxy botnet. Analysis of zhima variants shows support for reverse-proxy functionality including SOCKS5 and HTTP CONNECT style traffic relaying, with the infected device acting as an exit node while maintaining outbound-only connectivity to the relay. This design reduces exposure of directly reachable listening services on the victim while still enabling proxy abuse.
Zhima has been linked with monetization-focused activity attributed with high confidence to MoYu Group, an actor associated with the BADBOX ecosystem and residential proxy services such as PXYEDGE and ProxyForU. In the automotive campaign, operators also used adjacent malware stages for ad fraud, web requests, and device-information collection, while zhima specifically provided the proxy-botnet capability. Targeted platforms directly supported by the evidence are Android-based head units and Android TV or set-top box devices. The malware's operational purpose is covert traffic relaying and botnet expansion rather than destructive effects or direct interference with vehicle safety-critical functions.
Mallory pivots from this family to the IOCs, detections, and named campaigns that touch your stack, and pages you when something new lands.
3 distinct threat actors attributed by public researchers. Open in Mallory to see the full evidence chain and overlapping campaigns.
Stage 3 – Clicker / Reverse proxy loader : ... télécharge et exécute le module zhima (proxy inversé).
Researchers found that operators were using commands to fetch a reverse-proxy module named zhima, allowing an infected head unit to relay traffic for someone else.
The app downloads the JAR at url2, verifies it against md52, loads it with a DexClassLoader, and calls com.miyc.transfer.Client.start(…) with the relay address and ports from params. The name field, zhima, is the operator's own label for what comes next.
17 distinct techniques documented for this family, organized by ATT&CK tactic.
Rather than tricking drivers into installing a suspicious app, attackers used the software update path already built into Android-based head units.
Le malware est distribué via TWCore ( com.tw.core ), une application système légitime responsable des mises à jour du firmware. TWCore reçoit des instructions via un broker MQTT hébergé sur cardoor[.]cn , qui lui ordonne de télécharger et d’installer des APK malveillants.
The third stage checks in at regular intervals... then receives fresh configuration data or commands.
Envoie des informations sur l’implant au C2 via POST ... Stage 3 ... Envoie toutes les 90 minutes des informations sur l’appareil infecté ... au C2 via /cpc/api/task
Researchers found that operators were using commands to fetch a reverse-proxy module named zhima, allowing an infected head unit to relay traffic for someone else.
The resulting botnet powers a so-called residential proxy service, allowing attackers to route their traffic through infected devices
Stage 3 – Clicker / Reverse proxy loader : ... télécharge et exécute le module zhima (proxy inversé).
Only loadlib2 and http were seen in use, with loadlib2 pulling down zhima, the reverse proxy module... This confirms that the attackers’ ultimate goal is building a proxy botnet.
70 indicators attributed across vendor reports, sandbox runs, and researcher write-ups. Full values are available in Mallory.
IPs, domains, and DNS infrastructure linked to this family.
File hashes (MD5, SHA-1, SHA-256) from samples and reports.
Other indicator types observed in public reporting.
16 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Stage 3 module used to turn infected Android head units into residential proxy nodes; downloaded and executed by the loader/clicker component.
A reverse proxy module delivered as a later-stage payload to turn infected devices into nodes in a proxy botnet.
A secondary module delivered by JarService that turns infected Android head units into reverse-proxy nodes for traffic relaying and botnet monetization.
Named Android malware associated with the listed APK delivery URLs, package identifiers, and command-and-control/proxy infrastructure.
Match every observed IP, domain, and hash against your live telemetry.
Named campaigns wielding this family, with evidence pinned to each claim.
CVEs this family uses for access and lateral movement.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Every documented technique, ranked by evidence weight.
Reddit, Mastodon, and CTI community discussion around this family.