“RatHat’s multi-tiered architecture, reliance on out-of-lifecycle daemons, and use of real-time GenAI decision loops illustrate why traditional, signature-based mobile security controls are insufficient,” Zimperium’s zLabs team wrote in a malware analysis published on September 16.
Delivery: smishing, malvertising and deceptive APKs
Zimperium’s zLabs traced RatHat distribution to a blend of deceptive phishing sites promoted through malvertising, SMS phishing (smishing) campaigns and posts on third‑party forums. The operators use those channels to coax victims into manually downloading Android package kits (APKs) that appear to be legitimate applications. The malicious APKs include a dropper that carries the RatHat payload in two encrypted assets and then leverages native SessionInstaller APIs to bypass Android’s restricted settings and Accessibility Service protections, enabling installation of the hidden payload after the user installs the deceptive app.
Architecture: malicious app, Go agent (liblocal-service.so), and FRP client (libmedia_codec.so)
Zimperium breaks RatHat into three operational parts. First, a malicious Android application acts as the user-facing installer, gains critical system permissions and boots the infection chain. The app contains spyware capabilities capable of harvesting banking credentials, notifications, two‑factor authentication (2FA) and one‑time password (OTP) keys, and of capturing screen content and input.
The second layer is a Go agent delivered as liblocal-service.so. That component functions as a privileged command‑and‑control executor and runs commands through a local ADB shell context to evade app‑level restrictions. In the samples Zimperium examined, the Go agent handled tasks such as exempting the app from battery optimization/Doze mode, prioritizing its background execution and disabling or uninstalling other installed packages, including security applications, while retrieving the FRP client configuration from the C2 server.
The third layer is an FRP client embedded as libmedia_codec.so. Its purpose is to create a persistent, secure reverse tunnel from the infected device back to the attacker’s command‑and‑control server, providing remote access to the device’s ADB daemon. Zimperium describes this FRP client as a general‑purpose backdoor that can carry arbitrary commands independent of RatHat’s built‑in features.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleGenerative AI UI‑automation: serializing Accessibility trees and directing clicks
One of the sample’s most novel elements is a generative AI user interface‑automation engine inside the malicious app. RatHat serializes the device’s live Accessibility tree to XML and communicates in Mandarin with “one of the world’s most popular generative AI assistants,” zLabs reported. The researchers noted that the AI is used for non‑malicious‑sounding subroutines that directly support the attack, for example:
- Resolving a named target's centre coordinates on the screen as JSON to direct synthetic clicks;
- Resolving a target's actual on‑screen text from the XML (without translating);
- Signaling automatic navigation commands such as SCROLL_DOWN.
Zimperium did not specify the AI tool by name but provided a graph suggesting the threat actors used Google’s Gemini AI models; the report also highlighted that the prompts used by RatHat operators were the main indicator pointing to potential China‑based operators.
Persistence, anti‑analysis and out‑of‑lifecycle daemons
The dropper contains multiple anti‑defense features: four anti‑analysis layers and one anti‑debug layer designed to bypass Android security controls. The Go agent’s use of a local ADB context, together with the FRP client’s persistent reverse tunnel, gives the operators control mechanisms that run outside normal app lifecycles — what zLabs characterizes as “out‑of‑lifecycle daemons.” Those traits allow RatHat to prioritize background execution, resist battery‑management shutdowns, and remove or disable competing apps, including security tools.
What this means for security teams, enterprises, and end users
- Security teams and technologists — Monitor for nonstandard binaries with names like liblocal-service.so and libmedia_codec.so, unusual ADB activity or reverse‑tunnel endpoints, and changes to battery optimization exemptions or mass uninstalls of packages. Zimperium’s analysis highlights that signature‑based detection alone may miss adversaries that use multi‑tiered daemons and AI‑driven UI automation.
- Enterprises and procurement leaders — Be alert to threats delivered through malvertising and third‑party forums that push sideloaded APKs. The FRP client’s capacity to give persistent remote ADB access means compromised devices could be used as long‑running footholds independent of the original app’s capabilities.
- End users — The campaign relies on victims manually installing APKs from deceptive sites and responding to smishing messages. Zimperium’s findings show attackers couple social engineering with capabilities to capture credentials, notifications and authentication tokens once the app is installed.
RatHat combines social engineering, novel persistence techniques and an AI‑guided automation loop to turn a compromised Android device into a long‑lived platform for credential harvesting and remote control. Zimperium’s September 16 analysis frames a clear technical challenge: when UI actions are decided in real time by an external AI and control is maintained through out‑of‑lifecycle daemons and reverse tunnels, defenders cannot rely solely on conventional, signature‑driven controls to detect and interrupt the chain. How defenders and device platforms will adapt to the combination of generative AI decision loops and persistent FRP tunnels is the immediate question raised by these findings.
Source: Infosecurity Magazine — Zimperium zLabs analysis (September 16)
