RatHat malware drives your stolen Android with an AI
Zimperium's zLabs has documented RatHat, an Android trojan that switches on Wireless Debugging, escapes the app sandbox to gain a shell, and asks a chatbot where to tap next.

Android malware has spent a decade doing the same handful of things in the same handful of ways, which is why defenders can spot it. RatHat is a new strain that changes the recipe in one specific and rather clever way: instead of shipping a script that knows which buttons to press, it asks a chatbot.
The trojan was documented by zLabs, the research arm of the mobile security firm Zimperium, which links it to threat actors that appear to be operating in China. The attribution rests partly on the prompts it sends to that chatbot, which are written in Chinese.
How RatHat gets in
Delivery is conventional enough to be depressing. RatHat arrives through targeted smishing, through malvertising that funnels victims to convincing download pages, and through third-party app forums, with victims talked into sideloading an APK that is not what it claims to be. One build is configured to pose as a well-known streaming app, borrowing its icon and its label. The package also carries the option to restyle its launcher icon later by switching on a different activity alias, one of which is labelled Chrome.
Turning the phone against its owner
The part that matters starts with the Accessibility Service, the permission Android grants to apps that help people who cannot easily use a touchscreen. With it, RatHat does not need a victim to do anything clever. The service taps the Build Number seven times to unlock Developer Options, switches on Wireless Debugging, then reads the six-digit ADB pairing code and the dynamic port straight off the pairing dialog. From there the trojan authenticates against the phone's own ADB daemon and lands shell access in /data/local/tmp.
That shell is used to stage two binaries disguised as native libraries: a Go agent named liblocal-service.so and a reverse-proxy client built from the open-source frp project, shipped as libmedia_codec.so. The agent whitelists the app against Doze, pushes it into Android's active standby bucket, and can disable or uninstall other packages. The proxy client opens a persistent tunnel back to the attacker's server, which hands the operator a general-purpose road into the device rather than a fixed set of stolen features.
What it takes once it is in reads like a checklist of everything a banking app is supposed to be protected against: a WebView overlay engine that impersonates banking and payment apps to lift credentials, an SMS receiver and notification listener that intercept 2FA and one-time codes, screen streaming through MediaProjection, and touch monitoring at the hardware level detailed enough to reconstruct PINs, passwords and unlock patterns from finger movement.
The chatbot does the tapping
The genuinely novel bit is the automation layer. RatHat serialises the live accessibility tree of the device into XML and sends it to a mainstream generative AI assistant, asking it to return the centre coordinates of a named target as JSON so the trojan can fire a synthetic click, to read out the actual on-screen text, and to issue navigation commands such as scrolling down. Anyone who has watched a scripted bot fail the moment an app moves a button will see the appeal: an assistant that reads the screen fresh each time does not care where the button used to be, and its actions do not look like the metronome of a recording.
RatHat highlights a distinct paradigm shift in the mobile threat landscape: moving away from static, easily disrupted automation toward adaptive, AI-assisted execution chains that operate outside the constraints of traditional mobile app sandboxes.— Zimperium zLabs
Getting rid of it is not meant to be easy
Removal is a fight. The malware intercepts the uninstall confirmation dialog and paints over it with a fake Google Play failure message, cancelling the uninstall. Even if the app does go, a hidden background service survives and silently reinstalls it and its permissions. And because RatHat can request Device Admin rights, it can wipe the device when it sees an uninstall attempt coming.
Our opinion
The AI angle here is being reported as though a model has been weaponised, and that overstates it. RatHat is not clever because it has a language model in the loop; it is clever because it found a legitimate debugging feature, Wireless Debugging, that will happily pair a computer with a phone and hand it a shell, and then automated the process of turning it on. The chatbot is a convenience bolted onto the end of a much older trick, and zLabs is refreshingly honest that the hard work is done by the accessibility abuse and the ADB pairing code, not by the assistant.
That said, the practical consequence of putting a model in the operator's chair is a detection problem that gets measurably worse. Signature-based defences have always been able to lean on the fact that malware repeats itself exactly; adaptive automation removes that handle, and the tell in this case is not the tap but the prompt. Whoever is guarding a phone estate should be asking harder questions about Accessibility Service grants and developer settings than about the newest strain's name.
The advice for normal people is boring and it has not changed. Sideloading an APK from a page an SMS told you to visit is still the single most expensive favour you can do a stranger. RatHat simply makes the cost of that favour higher than it used to be.
- zLabs, Zimperium's research team, documented RatHat and links it to threat actors that appear to be operating in China
- It abuses Accessibility permissions, Developer Options and Wireless Debugging to pair with the phone's own ADB daemon and gain shell access
- A generative AI assistant is fed the device's accessibility tree to work out where to tap, which defeats scripted-automation detection