RatHat pairs with its own Android Debug Bridge. Uninstalling the APK can leave the shell behind

The persistence boundary is Android debugging, not the APK

Zimperium's zLabs team has documented RatHat, an Android remote-access trojan distributed through targeted text phishing, malicious advertising and deceptive third-party download portals. The victim must install an APK outside the normal trusted-store path and grant powerful permissions, including Accessibility.

The important innovation is a chain of legitimate Android features. Accessibility gives the app visibility into the interface and the ability to generate gestures. RatHat uses that access to open Developer Options and Wireless Debugging, read the pairing code and port from the screen, and authenticate to the phone's own Android Debug Bridge using an embedded ADB library. That local ADB session runs with the Android shell identity, which has capabilities unavailable to an ordinary app.

RatHat then stages a Go service and a reverse-proxy client in /data/local/tmp. These processes sit outside the APK's normal lifecycle. Removing the app therefore does not necessarily remove the shell-side service. Zimperium observed the service checking whether the package remained installed and using Android package-manager commands to reinstall it, grant runtime permissions and re-enable its Accessibility service.

The attack path

The chain has two heartbeats. While the APK is present, it can redeploy the local service if that process stops. While the local service is present, it can reinstall the APK if the user removes it. A reverse proxy derived from FRP exposes the local service through an outbound tunnel, giving the operator a route into device interfaces despite NAT and firewall boundaries.

This explains why deleting the visible app is an incomplete response. The package is only one component. The live debugging session, files under /data/local/tmp, shell processes, altered secure settings and outbound tunnel also need to be removed.

Where generative AI fits, and where it does not

RatHat serialises the current Accessibility tree as XML and sends it to a popular generative AI assistant. The model returns coordinates and navigation steps that help it operate interfaces whose layout or wording may change. Zimperium's examples include resolving on-screen text and choosing actions such as scrolling.

That is adaptive user-interface automation. It can make a fixed attack script more resilient across devices, languages and software versions. It is not the source of shell privilege or persistence. Those come from local ADB pairing, the shell context and native services. Calling the malware simply “AI-powered” can hide the control that defenders most need to address.

Capability and enabling control

Observed capability	Mechanism	Defensive focus
Adapt to changing screens	AI interprets the Accessibility tree and suggests actions	Restrict unapproved Accessibility services and detect automated navigation
Gain shell context	The app self-pairs with local wireless ADB	Disable debugging on managed devices and alert on unexpected pairing
Persist beyond uninstall	Native service remains under `/data/local/tmp`	Inspect shell processes and perform full remediation, not package removal alone
Maintain remote access	FRP client creates an outbound reverse tunnel	Block and investigate anomalous persistent egress
Steal credentials	Overlays, Accessibility events and raw touch coordinates	Protect enrolment, monitor overlays and reset exposed credentials

Why shell access changes the credential threat

Zimperium found several collection paths. Fake banking and payment interfaces capture credentials and one-time codes. Accessibility events reconstruct text entered into fields. The Go service can also run Android's getevent tool as shell UID 2000 and read raw touch coordinates from /dev/input. RatHat combines those coordinates with device-specific keypad layouts to infer PIN digits and unlock patterns.

Raw coordinates do not contain the character by themselves. The inference becomes possible when the malware knows which keypad is displayed and where each key sits. This path can continue where screenshot protections or inaccessible custom keyboards frustrate simpler collection methods. The report also describes browser address-bar harvesting, SMS collection, file transfer, screen monitoring and task queues shared between the app and native agent.

Response must remove the bridge and assume credentials are exposed

Key facts