RatHat: the Android banking trojan whose control panel asks Gemini which victims are worth robbing

On September 28, 2026, Italian fraud-detection firm Cleafy Labs published an analysis of the operator console behind RATHat, an Android banking trojan, and found that its newest version calls Google's Gemini models to estimate each victim's bank balance from stolen text messages and sort infected phones into "high-value" and "mid-value" groups. Cleafy tracked nearly 100 separate deployments of that console since April 2026, running campaigns in Europe, Latin America and South-Eastern Asia. Nothing here requires a patch: the practical response is mobile hygiene — block sideloading, restrict which apps may hold Android's Accessibility permission, and make sure developer options and wireless debugging are off on managed phones.

What happened, in plain English

RATHat (also written RatHat) is a remote access trojan for Android phones. It is sold and rented rather than run by a single gang — a Malware-as-a-Service model, where a developer maintains the product and paying criminals ("operators") get their own instance to run campaigns. Victims are reached by smishing (phishing by SMS), malvertising (ads that lead to a fake download page) and third-party sites offering tampered copies of real apps, according to reports from Cleafy Labs and from Zimperium's zLabs team, which published its own analysis of the malware itself on September 16, 2026.

Cleafy's new work is about the other side of the operation: the web panel operators log into. It traced three generations of that panel back to one shared codebase — "BlackCat Remote Control Management," first seen online in April 2026, then "Panda Workshop V5," and "Panda Workshop V6," which Cleafy describes as the largest and only hardened build and which was live in September 2026.

The AI part appears in two places. On the panel, Cleafy writes that "the console uses a model to estimate a victim's balance from the SMS it has already collected." V5 showed this as a floating widget that scored a victim's total bank balance; V6 gives it a dedicated page that files devices into analysed, high-value and mid-value buckets. On the phone, the implant serializes the screen's accessibility tree — the structured description of on-screen elements that Android builds for screen readers — and asks a model where to tap when its hard-coded automation fails on an unfamiliar phone skin or language. Those calls go "directly to Gemini flash models from the device, using an API key stored in the malware's own configuration."

An analogy: the malware has always been able to break into the house. What is new is a clerk in the back office reading the mail it steals and telling the burglars which houses to visit first.

Are you affected? What to do now

This is consumer-grade mobile crime, so most organisations have nothing to patch. But if you manage Android devices, or your company's customers bank on their phones, there are concrete things to check.

For IT and mobile fleet owners:

• Confirm your mobile management policy blocks installation from unknown sources (sideloading) and keeps Google Play Protect enabled. RATHat's entire delivery chain depends on users installing an APK from outside the Play Store.
• Disable developer options and wireless debugging on managed devices, and alert if they are turned on. Zimperium's report describes the malware turning developer options and wireless debugging on by itself through the Accessibility Service, reading the pairing code out of the dialog, and pairing with the phone's own debug daemon to get a shell. A device that suddenly has debugging enabled is worth investigating.
• Audit which apps hold the Accessibility permission. It is a legitimate, powerful permission — genuine screen readers need it — which is exactly why it is abused. Very few apps on a corporate phone should have it.
• Treat SMS as an untrusted channel for one-time codes. Zimperium documents interception of SMS, notifications and one-time passwords. Where you can, move staff and customers to app-based or hardware authenticators.
• Feed the published indicators into your DNS and proxy logs. Cleafy lists the September 2026 command-and-control host admin.chunhuating[.]best, the August 2026 host admin.xiongmaocs[.]pics, delivery URL https://dramaspoolcoa[.]com/en.html and sample MD5 116346cace7f00ba557034b534d40791, among older entries. Zimperium publishes its indicators in its public IOC repository. Corporate networks are not the target here, but a hit is still worth chasing.
• Awareness training point: the newest panel includes a phishing download-page builder with a fake app-store template where operators fill in the app name, description, version, rating and download count. "It looked like a real store page" is no longer a reason to trust a download.

For fraud and anti-fraud teams: the victim-scoring feature means the gap between infection and the first fraudulent transaction is likely to shrink for high-balance accounts and lengthen for everyone else. If you baseline time-to-fraud, expect that distribution to change shape rather than shift uniformly.

For everyone else: install Android apps only from the Play Store or your organisation's managed store, and be suspicious of any app that asks for accessibility access it has no obvious reason to need.

The expert view

Two things are worth separating here, because only one of them is genuinely new.

The device-side use of a language model is the more interesting half. Overlay-and-accessibility trojans have always had a brittleness problem: automation written against one bank app's layout breaks on the next OEM skin, the next locale, the next app update. Historically, solving that meant Automated Transfer Systems — per-target scripts, hand-built and maintained, which is real engineering cost and a natural brake on scale. Cleafy's framing is direct: this points at a "return of ATS, this time without the per-target engineering," and the firm calls it "a scenario worth preparing for rather than a speculative one." A model that can be handed a serialized accessibility tree and asked which node is the confirm button turns a per-target engineering problem into a per-request inference cost. That is a structural change in the economics, not a new capability in the malware.

The panel-side balance scoring is less technically novel but says more about where AI actually lands in criminal operations. Reading a pile of bank SMS notifications and producing an estimated balance is unglamorous text extraction — the sort of thing a regular expression did badly and a model does adequately with no tuning. Its value is triage. A Malware-as-a-Service platform's scarce resource is operator attention, and the panel is now spending it on the most profitable devices first. This is the same pattern visible across recent reporting: AI is not making attacks cleverer so much as making the back office of crime cheaper to run.

Two details deserve a defender's attention. First, the embedded API key. Calling a commercial model from inside malware, with a credential compiled into the configuration, is a real operational-security weakness: it is billable, revocable and attributable, and it puts the abuse squarely inside a provider's telemetry. Neither report includes a statement from Google, and we do not know whether these keys have been revoked or what the provider has observed. Second, the concentration of infrastructure: Cleafy found nearly half of the roughly 100 deployments hosted on AS4907 (BGPNET PTE. LTD., Singapore), and V5 added operator-facing TOTP two-factor authentication — a service maturing and defending its own customers.

On attribution, be careful. Zimperium links RatHat to threat actors operating in China, citing the AI prompts found in the malware and its targeting of Chinese payment apps including WeChat and Alipay; Infosecurity Magazine reported those prompts as being written in Mandarin. Cleafy's panel analysis offers no attribution statement, and its observed campaigns are in Europe, Latin America and South-Eastern Asia. Those are compatible — a China-based developer selling to operators elsewhere would produce exactly this picture — but it is an inference, not a finding, and no government or law-enforcement body has attributed this activity.

What remains unknown is the scale that matters most: neither report quantifies infected devices. Nearly 100 console deployments tells us how many criminal tenants the platform has, not how many phones they hold. Until someone publishes victim numbers, treat RATHat as a well-engineered and commercially successful product of unknown reach.

Official sources

• From BlackCat to Panda Workshop: Inside the Evolving C2 Panel Behind RATHat — Cleafy Labs, September 28, 2026 (primary: panel analysis, deployment counts, Gemini usage, indicators)
• RatHat: AI-Powered Mobile Threat is Here for Your Credentials & Bank Accounts — Zimperium zLabs, September 16, 2026 (primary: malware analysis, accessibility and debugging abuse, attribution)
• Zimperium RatHat indicators of compromise — Zimperium, published IOC repository
• Coverage: RatHat Android Malware Console Uses Gemini to Identify Higher-Value Victims — The Hacker News, September 28, 2026
• Coverage: New 'RatHat' Android Malware Leverages AI to Steal Financial Data — Infosecurity Magazine, September 17, 2026