Reported ADB Incidents and Device Impact Device Impact Reported by Users Reported Blank Notification
Device Impact Reported by Users
Reported Blank Notification
Loader Execution Chain
Cryptographic and Staging Protocol
Command and Control Infrastructure
Execution Architecture Component Roles and Triggers
Component Roles and Triggers
ADB Propagation and Remote Installation ADB Privileges and Infrastructure History Device Profiling and File Transfer
ADB Privileges and Infrastructure History
Device Profiling and File Transfer
Technical Analysis Loader and Command Channels Accessibility-Based Device Control Defense Evasion Persistence Device Profiling and Arbitrary Shell Execution Capabilities of the tc9 RAT Stage
Loader and Command Channels
Accessibility-Based Device Control
Device Profiling and Arbitrary Shell Execution
Capabilities of the tc9 RAT Stage
Detection and Indicators of Compromise File-Based Indicators Device and Runtime Indicators Network Indicators Recommended Response Actions
File-Based Indicators
Device and Runtime Indicators
Recommended Response Actions
FAQ What is Hagaseca THost9? Does THost9 spread like a worm? What does tc9.dex add? How does THost9 persist? What are the strongest detection signals?
Does THost9 spread like a worm?
What does tc9.dex add?
How does THost9 persist?
What are the strongest detection signals?
Hagaseca is an Android malware cluster associated with exposed Android Debug Bridge (ADB) services. This analysis examines the Hagaseca Android RAT loader known as THost9. RAT stands for remote access trojan. A RAT can let an attacker control an infected device remotely.
The loader hides executable code inside an Android application package (APK). It then loads tc9.dex, a separate stage with shell access, file transfer, and ADB propagation capabilities.
Public incident reports link THost4 and THost9 to exposed Android and Redroid systems. Redroid runs Android in containers. The recovered code helps explain those reports, but scanning an ADB service does not automatically grant access.
Hagaseca is an artifact-based cluster name. The available evidence does not establish a verified threat-group identity.
Packed loader: THost9 decodes an embedded asset and loads Android bytecode, known as DEX.
Remote control: The recovered tc9.dex stage supports shell commands, file transfer, tunneling, and additional modules.
ADB propagation: The stage discovers and scans ADB endpoints. Installation depends on usable access and the available privileges.
Device control: The loader uses foreground services and Android accessibility features. In one tested build, a reachable local socket accepted commands without authentication.
Detection opportunities: Package names, signing information, stage files, and network markers help identify the examined samples.
Hagaseca and THost9 refer to different levels of the same investigation.
Hagaseca cluster means the wider artifact-defined set connected through namespaces, infrastructure, signing identity, and repeated implementation choices.
THost9 means the Android chain using package com.hagaseca.thost9 and downstream class com.hagaseca.tc9.Main .
THost9 implementations means the verified loader builds, their embedded DEX files, and the recovered tc9.dex stage used here to document the family’s design.
The component boundary matters. The APK loader implements packing, concealment, accessibility control, foreground persistence, and stage loading. tc9.dex implements the remote RAT channel, ADB worm, installer, and downloadable-module system.
The family name is unusually explicit. The builds use the Hagaseca namespace, the certificate common name is hagaseca , the manifests contain [email protected] , and the recovered stage defines com.hagaseca.tc9.Main . Together, these identifiers establish a consistent family label across the recovered chain.
Hagaseca Timeline: THost4 to THost9
The located public record spans THost4 submissions in 2024 and THost9 artifacts and incident reports in 2025–2026. The timeline below distinguishes registration, submission, certificate, and incident dates. A domain registration or certificate validity date does not establish when an attack began. Registration of a parent domain also does not prove when its Hagaseca subdomain was created.
THost4 is the earliest Hagaseca-named THost artifact located, followed by signed THost9 artifacts and exposed-ADB incidents documented through 2026.
Reported ADB Incidents and Device Impact
Public ADB exposure is the distribution pattern established by the recovered code and multiple incident records.
The redroid-doc incident thread first identifies THost4 in a compromised persistent /data volume. Later reports describe THost9 on a phone with public ADB over Wi-Fi and in Redroid environments whose Docker ADB ports were exposed. A July remediation commit changes the mapping from 0.0.0.0:5555 to 127.0.0.1:5555 after a documented infection.
The recovered tc9.dex confirms opportunistic scanning and installation through unsecured or previously authorized ADB. It discovers _adb-tls-connect._tcp , _adb-tls-pairing._tcp , and _adb._tcp , expands an operator-selected address to a /16 , probes 65,025 hosts, authenticates with prepared ADB key material, retrieves thost9.apk , and runs its embedded installer. The same stage can set service.adb.tcp.port to 5554 and toggle Android’s ADB settings.
Device Impact Reported by Users
The targeting rule is exposure driven: the recovered scanner expands a selected address to a /16 and tests every generated host on the chosen ADB port.
Reported Blank Notification
An archived post dated 9 March 2026 names com.hagaseca.thost9 and describes a blank notification. That symptom is consistent with the loader’s nearly empty foreground-service notification.
A blank notification alone does not identify THost9. Confirm the package, signer, and related artifacts before drawing that conclusion.
Loader Execution Chain
The recovered execution chain has twelve major steps:
Android instantiates com.hagaseca.loader.Main as the application object.
The outer loader reads assets/hg and treats its first byte as a one-byte XOR key.
XOR decoding reveals a gzip stream that expands to a valid DEX payload.
The original wrapper is cached privately as .hg.db .
The loader injects the recovered DEX at the front of the application class path.
The payload removes its task from Recents, moves the activity behind the current UI, and starts background components.
A foreground service posts a visually blank notification and enters a staging loop.
If protected secure-settings access already exists, the payload enables com.hagaseca.thost9/.AS as an accessibility service.
The loader requests tc9.dex from , caches a valid stage as .tc9 , and invokes com.hagaseca.tc9.Main.main(String[]) .
The stage establishes its own C2 session and exposes shell, file-transfer, tunnel, reverse-shell, settings/ADB, and module commands.
Its worm worker discovers or scans ADB endpoints, authenticates, downloads thost9.apk , and runs the installer.
A boot receiver, service self-recovery, and a stage alarm maintain execution.
The component boundary is clear: the APK loader implements packing, concealment, accessibility, and stage loading; tc9.dex implements the remote RAT channel, ADB worm, and installer.
Cryptographic and Staging Protocol
THost9 uses two different mechanisms: packing to conceal embedded code, and an encrypted stream to exchange stage data. XOR and gzip form the packing layer; they should not be described as strong encryption.
The stage channel reads a 16-byte value and uses it as both the AES key and counter-mode initialization vector (IV). It then reads length-prefixed data and checks the expected stage hash.
The inner stream has no message authentication code (MAC). It lacks independent protection against modification if the outer TLS protection is defeated. A stage-hash check is not equivalent to authenticating the channel. These design weaknesses do not, by themselves, prove interception occurred.
The following representative loader implementations show the version-level differences used throughout this analysis.
The examined builds use v1, v2, and v3 signing with the same self-signed 256-bit EC certificate. Its SHA-256 fingerprint is:
b32bfa02834d43f04b78854e6cc417da2d45a2ca6d2908f33c06dc97c7cc0389
The certificate subject and issuer are both CN=hagaseca .
The recovered tc9.dex is a 127,108-byte DEX 037 file with SHA-256 54d4ee85175a249dcb576716edf491d09fa05dfdfc492ff710a0cb711f9a35ab , SHA-1 c6ee3d72053772bdce063c5b98afe32e739e918e , and MD5 bdca0eb738faaccb5b992d0f393b9d9f . It defines 68 classes and the exact entry point selected by the verified loader implementations.
Command and Control Infrastructure
The following identifiers connect the examined loader and stage. Command and control (C2) is the communication channel used to receive instructions or retrieve additional code.
The manifest email is an embedded string, not a verified operator . The wildcard socket was observed in contained S1 testing; binding to all interfaces does not prove it was reachable from the public internet.
Execution Architecture
THost9 separates a small stable loader from an expandable RAT/worm stage. The loader establishes persistence, starts the foreground service, profiles the device, exposes accessibility control, and launches tc9.dex ; the stage adds remote administration, ADB propagation, installation, and another downloadable-module layer.
Component Roles and Triggers
This architecture gives defenders two different opportunities. The package and embedded loader offer durable static identifiers, while the accessibility service, persistent notification, local socket, and repeated C2 retries provide behavioral signals.
ADB Propagation and Remote Installation
THost9 contains an ADB propagation chain:
tc9.dex discovers ADB through mDNS or accepts an operator-selected IP:port .
Remote-scan mode expands the target to a /16 and probes 65,025 addresses with 50 workers.
A second pass sends a raw ADB CNXN frame and selects AUTH or CNXN responders.
The raw client authenticates using prepared Hagaseca ADB key material and opens a remote shell.
The stage downloads thost9.apk from its active C2.
The embedded installer performs a streamed replacement install and configures permissions, accessibility, services, and privileged persistence when available.
The installed APK unpacks its embedded payload, starts .Fore , and loads tc9.dex , allowing the cycle to continue against additional reachable ADB endpoints.
ADB Privileges and Infrastructure History
The installer uses direct root or su 0 when the remote ADB context provides privileged execution. The stage can set service.adb.tcp.port to 5554, invoke tcpip , toggle adb_enabled and adb_wifi_enabled , open Wireless Debugging settings, and relay local ADB.
The infrastructure sequence moves from a THost4 Hagaseca subdomain on pleasedonthackmyserver.com to the dedicated hagaseca.com domain used by THost9.
A minimal analyst-side check on 3 September returned HTTP 101 after an empty WebSocket-style upgrade, confirming that the endpoint accepted the upgrade sequence used by the loader.
Device Profiling and File Transfer
The loader’s h109 and stage’s c210 profiles send Android version, CPU/ABI, memory, brand/product/model, an Android-ID prefix, ADB state/port, and network context in the user-agent header. The stage also implements pull:: to read an operator-selected file and transmit it over the active encrypted session, while push:: writes operator-supplied data to a selected path.
Loader and Command Channels
The outer loader is intentionally small. It extracts the XOR key from the first asset byte, decodes the remainder, inflates the gzip stream, and prepends the resulting DEX to the class path during application startup.
The remote stage channel is separate from the local accessibility controller:
Build GET /ws HTTP/1.0 for .
Add Connection: upgrade , Upgrade: websocket , and hg-token .
Add hg-type: kita for stage-hash queries and, in S2, the device profile as user-agent .
Require HTTP status 101.
Read 16 bytes and reuse the value as the AES-128 key and CTR IV.
Read a four-byte big-endian signed frame length.
Decode the body, validate the expected stage hash, cache .tc9 , and invoke com.hagaseca.tc9.Main.main(String[]) .
Accessibility-Based Device Control
The local controller belongs to the accessibility service. It opens a wildcard ServerSocket , begins at TCP 64737, and decrements the port if binding fails. S1 returned hg_as > immediately and answered harmless test input analysis with invalid cmd: analysis .
Why this matters: The local listener can provide immediate UI control without authentication if another process or reachable peer can access the bound port. The remote channel is modular, but its domain, stage names, custom headers, framing, and weak inner key construction provide strong hunting opportunities.
The examined implementations suppress ordinary launcher visibility. They use a blank label, provide no launcher intent, exclude the activity from Recents, move the task behind the current UI, and populate the foreground notification with spaces.
The real code is hidden inside assets/hg behind XOR and gzip. The loaders cache the original wrapper as .hg.db , inject the recovered DEX dynamically, encode strings as byte arrays, and rely heavily on reflection.
S2 adds a live anti-instrumentation guard. A thread scans /proc/self/maps for the byte string frida . If found, it prints HAGASECA: GOODNIGHT and calls Runtime.exit(0) .
Why this matters: The embedded payload implementations were extracted completely and passed DEX checksum and SHA-1 integrity validation. The literal /proc/self/maps , exit marker, packed asset, and private cache names provide observable detection points.
The examined manifests register com.hagaseca.thost9.Boot for BOOT_COMPLETED . The receiver starts or binds .Fore , which promotes itself to a foreground service with the nearly blank notification.
S2 adds Keeper, Stager, monitor, guard, and accessibility-monitor threads. When .Fore was explicitly stopped during contained Android 9 testing, logcat recorded destruction, rebinding, recreation, and a new start command. The foreground service returned and resumed its contained C2 retry loop in two seconds.
Android protects WRITE_SECURE_SETTINGS from ordinary third-party applications. During contained testing, accessibility activated after the analyst supplied the grant through ADB. The recovered installer includes a permission-grant path for execution from a privileged ADB shell.
Why this matters: THost9 recovers from ordinary service interruption once active, while unexpected accessibility enablement remains a high-value detection signal.
Device Profiling and Arbitrary Shell Execution
The loader’s shell helper executes sh -c . Its built-in callers collect OS, CPU, process-count, and memory values for the h109 profile. The tc9 dispatcher exposes the same primitive as an operator command, while the c210 profile adds Android version, ABI, memory, brand, product, model, an Android-ID prefix, ADB state and port, and network context
Capabilities of the tc9 RAT Stage
The supplied 127,108-byte DEX 037 file satisfies the exact stage contract implemented by the verified loaders. Its SHA-256 is 54d4ee85175a249dcb576716edf491d09fa05dfdfc492ff710a0cb711f9a35ab . It defines com.hagaseca.tc9.Main.main(String[]) , and that method passes the loader-supplied C2 URL directly into the stage session controller.
The worm path discovers ADB through mDNS or scans an operator-selected /16 . It uses 50 workers, a 500 ms connection pass, a 1,000 ms ADB probe pass, and the raw CNXN frame 434e584e01000001000010000600000032020000bcb1a7b1686f73743a3a . AUTH or CNXN responders are passed to a raw ADB client that implements CNXN , AUTH , STLS , OPEN , OKAY , WRTE , and CLSE .
The stage downloads thost9.apk , then executes a 1,843-byte embedded installer. That installer performs a streamed package install and, when privileged, writes /data/.hg/com.hagaseca.thost9/com.hagaseca.thost9.apk , links it into /system/app , grants the RAT’s required permissions, enables com.hagaseca.thost9/.AS , and starts .Fore .
The stage also schedules .Fore every 15 minutes, tracks active workers, persists module state under .mods , and profiles the host with marker c210 .
It is a multi-version cluster. Public THost4 and THost9 artifacts span October 2024 through 2026, and a third THost9 sample matches the local signer.
The access route is preventable. Incident records and the recovered scanner directly connect infections with public ADB or Redroid exposure.
The RAT is modular. tc9.dex adds a second layer of downloadable DEX/JAR modules without rebuilding the visible APK.
ADB propagation is built into the stage. It discovers, scans, authenticates, downloads thost9.apk , and runs its installer.
UI control is interactive. Once accessibility is active, the payload can inspect windows and inject , taps, focus, clicks, and scrolling.
Execution is deliberately unobtrusive. The blank label, hidden task, and nearly empty notification reduce casual discovery.
S2 self-recovers. Its foreground service returned roughly two seconds after an explicit stop.
The local controller is unauthenticated. S1 accepted commands through a wildcard TCP listener without a password or token.
The protocol exposes durable signatures. The domain, stage name, custom headers, h109 / c210 profiles, ADB probe, and cache filenames survive implementation changes.
Detection and Indicators of Compromise
Indicators of compromise (IOCs) help connect a suspected device to the examined samples. Use exact artifact matches and correlated behavior together; several network and file indicators also occur in legitimate activity.
File-Based Indicators
The following hashes identify files and signing material described in the supplied analysis. A matching file hash identifies that artifact; absence of a match does not exclude other builds.
Device and Runtime Indicators
Look for these artifacts in the context of the Hagaseca package or related activity. Short filenames such as .logs and .1, and standard ADB mDNS names, are not unique to this malware.
Remove public ADB exposure. Bind Redroid publishing to localhost and require an authenticated tunnel for remote access.
Isolate devices containing com.hagaseca.thost9 and preserve package, signer, logcat, notification, socket, accessibility, ADB-property, and install-timeline evidence before removal.
Preserve persistent Redroid /data volumes, .tc9 , .mods , .logs , .1 , /data/.hg , ADB keys, and install history.
Block the listed examined-file hashes and the shared certificate fingerprint in mobile application-vetting and MDM controls.
Monitor and deny the hardcoded C2 while treating its IP as time-sensitive shared-hosting infrastructure.
Hunt historical telemetry for the THost4 hostname and /hagaseca/gta path.
Alert on hidden or blank-label packages that start persistent foreground services and request all accessibility event types with window-content access.
Audit enabled_accessibility_services for com.hagaseca.thost9/.AS and do not grant WRITE_SECURE_SETTINGS to untrusted packages.
Hunt for .hg.db , .tc9 , .mods , .logs , .1 , start_as , as_port , TCP 64737, /proc/self/maps reads, and HAGASECA: GOODNIGHT .
Detect ADB mDNS discovery, /16 bursts to a common ADB port, the raw CNXN probe, unexpected service.adb.tcp.port=5554 , and ADB keys carrying the hagaseca .
Re-provision the device or persistent container data when privileged integrity cannot be re-established.
The original rules below target the described APK structure and recovered DEX stage. Their logic and author metadata are retained unchanged.
Test them against the supplied samples and a representative clean-file set before operational deployment. This editorial review did not execute the rules. The APK rule requires a specific combination of archive strings; repacking or structural changes can cause misses. The stage rule explicitly checks DEX 037 and is not a universal rule for all DEX versions.
THost9 is a packed, multi-stage Android RAT and ADB worm using package com.hagaseca.thost9 . Its APK conceals execution, maintains a foreground service, exposes accessibility-based UI control, and loads tc9.dex . The recovered stage supplies remote administration, modular code loading, ADB scanning/authentication, and installation.
Does THost9 spread like a worm?
Yes. The recovered stage discovers or scans ADB services, probes candidate endpoints, authenticates with prepared key material, downloads thost9.apk , and runs its installer. Its /16 expansion makes the behavior worm-like.
What does tc9.dex add?
The stage adds the remote RAT command surface, arbitrary shell execution, file transfer, TCP relay, reverse shell, downloadable modules, detailed device profiling, ADB discovery and scanning, raw ADB authentication, APK retrieval, and remote installation.
How does THost9 persist?
The APK registers a boot receiver, keeps .Fore as a foreground service, and restarts that service after destruction. The stage reinforces execution with a 15-minute alarm, while a privileged installer can enable the accessibility service and place the APK under /system/app .
What are the strongest detection signals?
The strongest static combination is the package, shared signing certificate, assets/hg , tc9.dex hash/class descriptors, private paths, and C2 markers. The strongest behavioral combination is a hidden package with a blank foreground notification, unexpected accessibility enablement, a wildcard listener near TCP 64737, ADB mDNS or /16 scan activity, the raw CNXN probe, ADB property changes, and repeated C2 attempts.
THost9 is a packed, multi-stage Android RAT and ADB worm. Its package namespace, signing certificate, service names, embedded stage contract, custom protocol markers, and infrastructure form a durable Hagaseca cluster signature.
THost4 is the earliest located Hagaseca-named THost artifact, followed by signed THost9 artifacts and exposed-ADB incidents through 2026. Multiple incident records directly connect the cluster with exposed ADB and Redroid systems, and the recovered stage implements the matching scan, authentication, installation, and ADB-property control paths.
At binary level, THost9 is a packed and recoverable multi-stage RAT. Its APK implementations combine hidden foreground execution, boot persistence, accessibility control, an unauthenticated local socket, custom encrypted staging, and anti-Frida behavior in a newer build. The recovered tc9.dex supplies arbitrary shell execution, file transfer, TCP relay, reverse shell, downloaded modules, ADB discovery and /16 scanning, raw ADB authentication, APK retrieval, installation, ADB property control, and an additional alarm-based persistence layer.
The response priorities are clear: close and audit exposed ADB; identify and isolate THost9 through its package, signer, hashes, accessibility behavior, service state, stage files, scan pattern, and C2 markers; and preserve /data , .tc9 , .mods , ADB keys, network captures, and install provenance before remediation.
The recovered stage aligns the public incident record with code and gives defenders stable opportunities across the APK, signer, services, files, accessibility state, C2 protocol, ADB scan pattern, and installer behavior.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
