Security1 publisher3 min readPublished
RatHat self-pairs Android's debug bridge to survive its own uninstall
Zimperium says RatHat uses an accessibility grant to switch on Wireless Debugging and read its own 6-digit pairing code, leaving native daemons at shell privilege that keep answering after the app is removed.
The Watch · Security desk
What happened
- Zimperium says RatHat spreads through targeted smishing and malvertising that push users to deceptive third-party download portals serving malware-laced APKs, which drop the main payload.
- Once the victim grants accessibility services, the app drives the settings itself: Developer Options unlocked, Wireless Debugging enabled, and the device's 6-digit ADB pairing code extracted.
- Zimperium says the operator keeps shell access even after the victim uninstalls the app, and can use the local service to check whether the malware is present and reinstall it.
- On-device features include credential overlays on named apps, screen recording via MediaProjection, SMS interception, and a fake Play Store failure overlay that blocks installation attempts.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- constraint Mobile response playbooks that end at removing the offending APK now close the ticket while the operator still holds a shell and a reinstaller.
- capability A reverse tunnel into the ADB daemon means operator capability is no longer bounded by the build that landed on the phone. Detections written against RatHat's own command set go stale without a new sample.
- exposure Every account whose password was typed on the handset, and the screen lock itself, has to be treated as known before the device is trusted again.
- decision With no fix to deploy, the lever is device policy: whether Developer Options and Wireless Debugging are reachable at all on a managed phone.
Nothing in the chain is a vulnerability. Accessibility services, Developer Options, Wireless Debugging and local ADB pairing are shipped Android features, used in the order the platform documents, so there is no CVE to track and no patch date to wait for [17]. That leaves the accessibility prompt as the last place a user can stop it.
Zimperium's researchers describe the result directly. "Once deployed, it pairs Accessibility abuse with autonomous local ADB (Android Debug Bridge) self-pairing to break out of the standard Android application sandbox," they said, "staging independent native daemons that execute with shell-level privileges" [2].
The app is one of three components, alongside a Go agent and an FRP reverse-proxy client [5]. The Go agent hides as liblocal-service.so, runs commands through the shell it acquired from the local ADB daemon, and applies power management exemptions so it keeps running [7]. Removing the app takes out the component with an icon and leaves the two shell-side pieces in place [18].
The Go agent pulls its FRP configuration from the command-and-control server, and the client opens a persistent reverse tunnel back to the operator [8]. "This connection is used by attackers to have access to the ADB daemon," the researchers said. "It's a general-purpose road into the device that carries whatever the operator wants, independent of the malware's own feature set" [9].
There is an AI component. "The malware serializes the device's live Accessibility tree to XML and communicates with one of the world's most popular Generative AI assistants," Zimperium said [10]. The report does not name the assistant. According to the company, the assistant resolves a named target's centre coordinates as JSON so the malware can direct synthetic clicks, and returns a target's actual on-screen text from the XML. It also signals navigation commands such as SCROLL_DOWN. Zimperium classes all of those as non-malicious requests in themselves [11].
Sample triage is made expensive on purpose. Container tampering declares some files as directories or sets the ZIP general-purpose encryption bit, so Android's libziparchive skips them while unzip and apktool do not [14]. A manifest bomb plants undocumented 0x9999 chunk headers in AndroidManifest.xml, which the native runtime ignores and automated pipelines crash or time out on [15]. DEX pseudo-instructions carry an invalid element_width to break disassembly, and strings are encrypted twice [16].
Attribution to China-based operators is Zimperium's assessment [1]. The published findings give no victim counts, affected countries or dates. What the C2 can ask for is enumerated: SMS, credentials, files, the lock screen PIN, pattern or password, screen captures, keystrokes including URLs typed into browser address bars, and the installed application list. There is also a hardware-level keylogger, run by the Go agent, that records finger presses on the screen [12].
What to watch
- Whether Google constrains the accessibility-to-Wireless-Debugging path in a platform or Play Protect update.
- Whether Zimperium or others publish hashes, C2 infrastructure, or the identity of the generative AI assistant being queried.
- Whether local ADB self-pairing turns up in unrelated Android families, which would make it shared tooling rather than one crew's technique.