THost9 Android RAT Uses Packed Loader and ADB Worm to Spread

The THost9 Android RAT combines a concealed loader with an ADB worm that scans for exposed Android Debug Bridge services and installs the malware on reachable devices.

THost9 Android RAT Uses Packed Loader and ADB Worm to Spread

A packed Android remote access trojan (RAT) has combined a concealed loader with a worm that scans for exposed Android Debug Bridge (ADB) services and installs itself on reachable devices.

Dark Atlas said in research published on September 8 that the malware, which it tracks as THost9, concealed executable code inside an Android application package before loading a second-stage payload named tc9.dex .

The researchers named the broader cluster Hagaseca after the namespace, certificate and class names shared by the samples.

Packed Loader Conceals the Android RAT

The packed loader used an embedded asset to hide its executable code. Dark Atlas found that the asset was decoded with a single-byte XOR operation and then decompressed with gzip. The recovered payload was subsequently loaded dynamically.

The loader started a foreground service, removed its activity from Android’s Recents view and displayed an almost blank notification. It could also enable an accessibility service, giving the malware control over the device interface when the protected settings permission had already been granted.

The second stage introduced shell execution, file transfers, tunneling, reverse-shell access and downloadable modules. Dark Atlas also identified a local controller that accepted commands without authentication in one tested build. However, the researchers noted that binding to all interfaces did not prove the socket could be reached from the internet.

The researchers resolved the malware’s command-and-control (C2) host on September 4. They said an analyst check performed the day found that the endpoint was still accepting the connection sequence used by the loader.

A newer build added an anti-analysis check for Frida, an instrumentation framework commonly used by security researchers. If the marker was detected, the sample exited.

ADB Worm Targets Exposed Android Devices

The most notable propagation capability was the ADB worm built into the second stage. Dark Atlas said the worm could discover ADB services through Android’s local service-discovery mechanisms or use targets selected by the operator. It could then expand a single address into a 65,025-host range and probe that range with 50 workers.

The worm authenticated with prepared ADB key material, retrieved the installer package and executed it. If the remote session was privileged, it could modify ADB settings and ports and copy itself into a system directory.

Public incident reports linked THost9 and the earlier THost4 to Android phones and Redroid containers with exposed ADB. The reports covered incidents from the first located THost4 sample in October 2024 through 2026. In one July 2026 remediation, a Redroid deployment was rebound to localhost only after an infection had occurred.

Dark Atlas cautioned that scanning an ADB service does not automatically provide access. However, it said incident records and the recovered scanner directly connected infections with public ADB or Redroid exposure.

The researchers identified the malware package, its signing certificate and two private cache files as detection points. They also urged administrators to remove public ADB exposure and review accessibility services and persistent Redroid data.

Dark Atlas described Hagaseca as an artifact-defined cluster and said the available evidence did not establish a verified threat-group identity.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.