RatHat: malware that asks an AI to drive the screen
On 16 September Zimperium's zLabs published RatHat: an Android banking trojan that serializes the live accessibility tree to XML, sends it to a popular generative AI assistant, and taps whatever the model returns. The AI drives the screen; overlays and input monitoring do the stealing. The part developers should study is the breakout: the trojan pairs itself to the phone's own wireless debugging, no computer needed.
What makes RatHat different?#
The stealing toolkit is not new. Overlay injection into banking apps, OTP interception through SMS and notification listeners, screen streaming, lock-screen capture: all of that existed before, and BleepingComputer's write-up lists the same catalogue for RatHat as for its predecessors.
Two things are new, and they arrive in combination. First, the UI pilot is a generative model instead of a recorded script, which Zimperium describes as the shift from "static, easily disrupted automation" to "adaptive, AI-assisted execution chains". Second, the whole stack escapes the app sandbox by itself, through the phone's own developer tooling. The ADB breakout has close cousins; BleepingComputer compares the mechanism to ToxicPanda and RedHook. The AI pilot is what that comparison list lacks. Zimperium links the operators to China, partly on the language in the AI prompts.
The chain, end to end#
The pipeline has six stages, from lure to persistence. Only one of them involves the AI; the table shows which.
| Stage | What RatHat does | What it relies on |
|---|---|---|
| Delivery | Smishing, malvertising, fake download portals; the victim installs the APK by hand | Social engineering, plus a dropper with four anti-analysis layers, among them a 61 MB manifest bomb |
| Consent | A localized HTML lure ("permission needed due to network restrictions") walks the user into granting Accessibility | The single consent everything else consumes |
| Screen control | Serializes the live accessibility tree to XML, sends it to a generative AI, applies the returned coordinates, text, and scroll commands as synthetic taps | The accessibility service the user just approved |
| Escalation | Taps "Build number" seven times to unlock Developer Options, enables Wireless Debugging, reads the 6-digit pairing code and dynamic port from the dialog, authenticates with an embedded ADB library | Android trusting its own UI, which the malware now drives |
| Persistence | Stages a Go agent and an frpc reverse-proxy client in /data/local/tmp; Doze whitelist, active standby bucket, granted permissions; survives uninstall and reinstalls itself | Shell access from the ADB daemon, outside the app lifecycle |
| Theft | WebView overlays for banking logins, SMS and notification listeners for OTP codes, MediaProjection streaming, PIN and pattern reconstruction from raw touch input | None of this involves the AI |
The AI part, precisely#
The model receives the accessibility tree as XML. It returns three kinds of answers: the center coordinates of a named element as JSON, the element's actual on-screen text, and navigation commands like SCROLL_DOWN. The malware converts the first kind into synthetic taps.
Zimperium is explicit that the AI is used "for non-malicious actions": navigation, target resolution, scrolling. It does not choose victims, compose the overlays, or interpret stolen credentials. The report names no vendor either, only "one of the world's most popular generative AI assistants"; the published prompt screenshots carry whatever attribution that supports.
The reason it matters anyway is maintenance cost, in both directions. A recorded UI walk breaks the moment an app changes a button. A model reading the screen adapts, which makes the automation resilient and the detection harder: there is no fixed gesture sequence left to signature. That is the actual innovation here, and it is a plumbing decision, not a research breakthrough.
Wireless debugging is the ignored hole#
Every security boundary in the escalation stage is a dialog box. The pairing code is six digits shown on screen; the port is a label in the same dialog; Developer Options sit behind seven taps. Accessibility services produce taps and read screens by design, so once the user grants that one permission, the rest of the chain runs unattended against UI that Android presents as trusted.
The end state deserves a slow read. The trojan uploads its ADB key and the live port to the C2 server, and an frpc tunnel makes the port reachable from outside. A developer feature turns into a permanent remote road in, and it survives uninstall, because the Go agent lives in /data/local/tmp, outside the package lifecycle, and reinstalls the app with all permissions re-granted by two settings commands.
For people, the list stays boring: no sideloading from download portals, a periodic look at Settings, Accessibility, and the Wireless debugging switch, which ships off and has no business being on a daily phone. For device fleets, both states are reportable, and RatHat is the report that justifies turning the checks on.
If you build payment flows#
The readers of this site ship things like a Telegram shop bot with Stripe checkout, so the target profile matters. The OTP your users type is exactly what RatHat's listeners harvest, and the login form is what its overlays clone. Nothing about that changes the server side of the shop demo: amounts stay server facts, client-sent numbers stay suggestions, and device trust belongs behind attestation and anomaly checks on OTP velocity, not inside the app.
AI on both sides of the glass#
The same week produced both stories: OpenAI disclosing six incidents of models concealing mistakes from their trainers, and Zimperium publishing a trojan whose pilot is a generative AI reading screens for criminals. The convergence is not deep. Both cases reward the same boring discipline: least privilege at every boundary, validation of everything that crosses one, and logs of what the automation actually did. The labs get that report card now. RatHat shows the same report being written about us.