“It could expand one address to a 65,025‑host range and probe it with 50 workers.”
How the packed loader hides THost9’s second stage
Dark Atlas’s September 8 research describes a packed Android loader that conceals executable code inside an application asset, then recovers and runs a second‑stage payload called tc9.dex. The embedded asset is decoded using a single‑byte XOR operation and decompressed with gzip before the recovered payload is loaded dynamically. After loading, the loader starts a foreground service, removes its activity from Android’s Recents view and presents a nearly blank notification.
Where the device already granted the protected settings permission, the loader could enable an accessibility service that gives control over the device interface. The second stage brings an expanded toolset: shell execution, file transfers, tunneling, reverse‑shell access and downloadable modules.
ADB worm: scanning, authenticating, and installing on exposed devices
The most consequential propagation capability in the second stage is an ADB worm that seeks exposed Android Debug Bridge (ADB) services. Dark Atlas says the worm discovers targets via Android’s local service‑discovery mechanisms or through operator‑selected targets. Once a seed address is selected, the worm can expand it into a 65,025‑host range and probe that range using 50 concurrent workers.
When a reachable ADB service responds, the malware attempts to authenticate with prepared ADB key material, retrieve an installer package and run it. If the remote session is privileged, THost9 can alter ADB settings and ports and copy itself into a system directory. Dark Atlas cautions that scanning an ADB service alone does not by itself grant access, but notes that incident records and the recovered scanner directly link infections with public ADB or exposed Redroid containers.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildCommand‑and‑control, anti‑analysis and an unauthenticated controller
Dark Atlas resolved the malware’s command‑and‑control (C2) host on September 4 and reported that an analyst check the previous day found the endpoint still accepting the loader’s connection sequence. One tested build contained a local controller that accepted commands without authentication; the researchers observed the component binding to all interfaces but said that did not prove the socket was reachable from the internet.
Newer builds of the malware include an anti‑analysis check for Frida, the instrumentation framework used by many security researchers. When the Frida marker is detected, the sample exits. These operational checks and an unauthenticated local controller, at least in one build, flesh out a toolkit capable of remote execution, persistence and modular expansion.
Incidents linking THost9 and THost4 to exposed ADB and Redroid (Oct 2024–2026)
Public incident reporting connects THost9 and an earlier family member, THost4, to infections on Android phones and Redroid containers with exposed ADB. That connection spans from the first located THost4 sample in October 2024 through reporting into 2026. Dark Atlas highlights a July 2026 remediation in which a Redroid deployment was rebound to localhost only after an infection had occurred, illustrating the operational impact of public ADB exposure.
What this means for technologists, affected enterprises, and end users
- Technologists and security teams: review and remove any public ADB exposure, look for the package name, the signing certificate and two private cache files Dark Atlas named as detection points, and audit accessibility services that might grant interface control.
- Affected enterprises and Redroid operators: check persistent Redroid data for signs of compromise and ensure ADB bindings are not reachable from untrusted networks; the July 2026 remediation cited by Dark Atlas shows that reconfiguration after infection is both costly and too late to prevent initial compromise.
- End users on Android devices: verify whether third‑party apps request protected settings permissions or accessibility privileges and be cautious about devices that expose debugging interfaces to untrusted networks.
Dark Atlas groups the samples under the cluster name Hagaseca — a label derived from shared namespace, certificate and class names — but describes Hagaseca as an artifact‑defined cluster and says the evidence does not establish a verified threat‑group identity. The researchers close with practical steps: remove public ADB exposure and review accessibility services and persistent Redroid data as immediate mitigation measures.
The combination of a packed loader, a modular second stage and an ADB‑focused worm ties a stealthy delivery mechanism directly to a broad, network‑level propagation method. That pairing — concealed local loading plus aggressive scanning and installation — explains why exposed ADB services and Redroid containers have repeatedly appeared in incident records from October 2024 through 2026 and why Dark Atlas emphasizes removal of public ADB exposure as a priority.
