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.
Why it matters
- What it limits 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.
- What's now possible 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.
- Who's exposed 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.
- Who has to decide 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.
Next story · Product · 2d ago
Google's opt-in Messages setting has Gemini judge what unknown senders wantConfirmed6 publishers
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 [16].
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 [19].
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.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption
- Not scored
- Hype gap+25
- Incentives55
- Confidence66
Perspective Coverage
6 publishers- Builder
- Builder 32%
- Operator
- Operator 63%
- Investor
- Investor 5%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
RatHat is a new Android malware assessed to be operated by China-based threat actors, with an AI-powered system to navigate and control compromised devices, per Zimperium research reported by The Hacker News.
- [2]
"Once deployed, it pairs Accessibility abuse with autonomous local ADB (Android Debug Bridge) self-pairing to break out of the standard Android application sandbox, staging independent native daemons that execute with shell-level privileges."
- [3]
RatHat is distributed primarily via targeted smishing and malvertising campaigns leading to deceptive third-party download portals, plus third-party forums, tricking users into installing malware-laced APKs that act as a dropper for the main payload and include anti-analysis and anti-debug checks.
- [4]
The Android app obtains accessibility services permission and then abuses it to unlock Developer Options, enable Wireless Debugging, and extract the 6-digit ADB pairing code.
- [5]
RatHat's architecture consists of three main components: the malicious Android application, a Go agent, and an FRP reverse-proxy client.
- [6]
Even if the victim uninstalls the app, the attacker still retains shell access on the device, and can weaponize the local service to check whether the malware is installed and re-install it if not found.
- [7]
The Go agent masquerades as a native library named liblocal-service.so and uses the shell access acquired via the local ADB daemon to execute commands, establish persistence and apply power management exemptions.
- [8]
"The Go Agent retrieves the FRP tunnel configuration from the C2 server, enabling the FRP Client to establish a persistent, active reverse tunnel to the operator."
- [9]
"This connection is used by attackers to have access to the ADB daemon: it's a general-purpose road into the device that carries whatever the operator wants, independent of the malware's own feature set."
- [10]
"The malware serializes the device's live Accessibility tree to XML and communicates with one of the world's most popular Generative AI assistants."
- [11]
Zimperium says the AI is used for non-malicious actions including resolving a named target's centre coordinates on screen as JSON to direct synthetic clicks, resolving a target's actual on-screen text from the XML, and signaling automatic navigation commands such as SCROLL_DOWN.
- [12]
C2 commands allow collection of SMS messages, credentials, files, the lock screen PIN, pattern or password, screen captures, keystrokes including URLs entered in browser address bars, and a list of installed applications; RatHat also includes a hardware-level keylogger, executed by the Go agent, capable of recording finger presses on screen.
- [13]
RatHat serves overlays atop specific apps to harvest credentials, records the screen using Android's MediaProjection API, intercepts SMS messages, and overrides installation attempts by serving a fake failure overlay impersonating the Google Play Store.
- [14]
Container tampering declares certain files as directories in the package or sets the ZIP general-purpose encryption bit flag on some files so they are ignored by Android's libziparchive library but not by tools such as unzip and apktool.
- [15]
A manifest bomb places undocumented 0x9999 chunk headers in AndroidManifest.xml, which the Android native runtime skips, causing automated analysis pipelines to crash or time out.
- [16]
Uninstalling the app removes one of RatHat's three components; the Go agent and FRP client run outside the app sandbox at shell privilege and remain.
- [17]
The escape chain uses documented Android functionality at every step, so no vulnerability identifier or patch is involved in the sandbox escape.
- [18]
Because shell-privilege components persist after uninstall and can reinstall the app, removing the APK does not end operator access; the device requires reimaging and rotation of credentials entered on it.
- [19]
DEX bytecode poisoning uses pseudo-instructions with an invalid element_width attribute to make disassembly fail, and strings are double-encrypted using a scheme Zimperium calls StringCrypto: Base64.
Sources
6 independent publishers whose own reporting we read for this story.
- bleepingcomputer.comNew RatHat Android malware uses AI to automate device control
1 article · September 17, 2026
- infosecurity-magazine.comNew Chinese-Made ‘RatHat’ Android Malware Leverages AI to Steal Financial Data
1 article · September 17, 2026
- malwarebytes.comNew Android malware uses AI to steal bank logins and PINs
1 article · September 18, 2026
- securityaffairs.comRatHat Turns Android Accessibility Into an Attack Weapon
1 article · September 18, 2026
- securityweek.comRatHat Android Trojan Uses AI for Automation
1 article · September 21, 2026
- thehackernews.comRatHat Android Malware Abuses ADB to Retain Shell Access After Uninstall
2 articles · September 18, 2026