Loading malware…
Zhima is an Android reverse-proxy malware module used to turn infected devices into residential proxy exit nodes and botnet infrastructure. It has been observed as a later-stage payload in multi-stage malware chains associated with MoYu Group, an actor linked to the BADBOX ecosystem. Zhima has been deployed on Android TV devices and Android-based automotive head units, where upstream loaders and droppers retrieve it dynamically and execute it through arbitrary code-loading mechanisms.
On automotive head units, zhima has been delivered through a staged infection chain abusing the legitimate update workflow of the TWCore system application on DoFun-based devices. In that campaign, a first-stage dropper and subsequent loaders ultimately fetched zhima via a command used for dynamic module loading, alongside other monetization-oriented functionality such as ad-fraud activity. On Android TV and IPTV ecosystems, zhima was delivered by grey-market streaming applications that fetched configuration and module descriptors from operator-controlled infrastructure before downloading and loading the proxy component at runtime.
Zhima implements reverse-proxy functionality over outbound connections initiated by the infected device, allowing operators to use compromised endpoints as proxy nodes without exposing an externally reachable listener on the victim system. Analyses of recovered builds show support for SOCKS5 and HTTP CONNECT style proxying, relay-based control and job handling, heartbeat processing, and module self-replacement to hand over execution to newer builds. The malware relies on upstream relay infrastructure for traffic brokering and authentication rather than authenticating proxy requests locally on the infected device.
The malware’s operational purpose is covert monetization through proxyware-style abuse: it converts consumer and embedded Android devices into part of a proxy botnet that can route third-party traffic through residential or otherwise trusted network connections. Researchers also linked the broader campaigns delivering zhima to ad-fraud and clicker behavior in earlier stages, indicating a multi-purpose monetization ecosystem rather than a single-function implant.
Recovered variants included multiple zhima builds, and independent investigations connected the same module family across both TV set-top box and automotive head-unit compromises. Attribution to MoYu Group is supported by infrastructure overlap, naming patterns, and links to BADBOX-related operations. Zhima is therefore best understood as a modular Android proxy payload within a broader MoYu-operated malware and monetization platform targeting nontraditional Android form factors.
Mallory pivots from this family to the IOCs, detections, and named campaigns that touch your stack, and pages you when something new lands.
2 distinct threat actors attributed by public researchers. Open in Mallory to see the full evidence chain and overlapping campaigns.
The payload downloaded via the loadlib2 command is a reverse proxy module named “zhima”... This confirms that the attackers’ ultimate goal is building a proxy botnet.
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.
Every string literal in the module is run through a per-character Caesar shift (subtract a per-string key)...
It decrypts data stored as encrypted blocks within the Trojan’s code. Each block is XOR-encrypted with a single-byte key that shifts linearly from block to block.
The loader sends implant information to one of the attackers’ servers via a POST request.
The command information includes a tagName field... at the time of publishing this report the attackers were using the loadlib2 and http commands.
The payload downloaded via the loadlib2 command is a reverse proxy module named “zhima”... This confirms that the attackers’ ultimate goal is building a proxy botnet.
The infected TV always dials out. It opens the connection to the operator's relay; the paying customer only ever talks to the relay; the TV then connects onward to the real target and shuttles bytes in both directions.
Each proxy job opens a fresh outbound connection to the relay's :7777, writes a session id, and then wraps the pipe in either a SOCKS5 or an HTTP CONNECT handler depending on the job type.
Three ports face the relay: :9999 carries registration and the control plane, :7777 carries the bulk data plane, and :5555 is a per-job bridge for heavier sessions.
23 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.
4 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A reverse proxy module downloaded in the later stage of the infection chain. It turns infected Android-based head units into nodes in a proxy botnet.
Reverse-proxy module delivered at the final stage to turn infected Android head units into part of a proxy botnet.
A reverse proxy module downloaded in the later stage of the infection chain. It is used to turn infected Android-based head units into nodes of a proxy botnet and is associated with the malware’s monetization and infrastructure operations.
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.