Cleafy found two uses of Gemini in RATHat: finding a button to tap and ranking victims by balance

221 days between two reports of the same trick

On 19 February 2026, ESET described PromptSpy, which it called the first known Android malware to abuse generative AI in its execution flow. The malware sent Gemini a dump of the screen and did what the model said: tap here. Cleafy's report on the RATHat Android trojan is dated 28 September 2026. That is 221 days later (derived: 19 February to 28 September), and the job the model does on the infected phone is the same kind of job. Given the layout of a screen, say where a control is.

That count does not establish that RATHat copied PromptSpy, or that either family is widespread. ESET said it had not seen PromptSpy in its own telemetry and called it a possible proof of concept. It also does not establish that the AI is what makes RATHat dangerous. Cleafy's own summary is narrower than the headlines: "the model is not performing fraud, it is deciding which victims are worth an operator's time."

What Cleafy did add is the console. Its analysts recovered three generations of the operator panel behind RATHat and found a model doing a second job there: reading text messages the malware had already stolen, and sorting phones into high-value and mid-value groups. This briefing separates what Cleafy observed from what the headlines and vendor titles imply, sets out what the reports leave unsaid, and ends with what a UK security team should check. It stays at defender level: detection and hardening, with no capability detail beyond a line.

What Cleafy published, and what it did not

The primary source is Cleafy's report, "From BlackCat to Panda Workshop: Inside the Evolving C2 Panel Behind RATHat", published on 28 September 2026 and credited to threat intelligence analysts Simone Mattia and Alberto Giust. It builds on Zimperium's earlier report of 16 September 2026, which reported the malware as RatHat and described its behaviour on the phone. The Hacker News article of 28 September is used here only as a pointer: every statement below was checked against the two reports. Note that "BlackCat" is the console's own branding. Neither report connects it to any other group that uses the name.

Both vendors sell products aimed at the problem they describe: Cleafy sells fraud detection, and Zimperium sells mobile threat defence. That is a reason to treat their forecasts as forecasts. It is not a reason to doubt the observations, which the two reports largely share.

What is on the record, in Cleafy's words or close to them:

• The Android implant "remained largely static from late 2025 to September 2026", while the operator console was replaced and went through three generations, BlackCat and then Panda Workshop V5 and V6, all live between April and September 2026.
• The console builds, signs and publishes new samples, and can rebuild the payload on a schedule, such as every hour. Cleafy calls that "a direct answer to hash-based detection".
• Cleafy counts nearly 100 separate deployments since April 2026, with nearly half of the observed IPv4 addresses on one Singapore-registered network, AS4907. It reads that as consistent with malware-as-a-service, where each customer runs a dedicated instance.
• Two AI integrations appear, and Cleafy describes them separately because "conflating them would overstate what either artifact shows".

Table 1. What the reports establish and what they do not. Sources: Cleafy report of 28 September 2026; Zimperium report of 16 September 2026; the Hacker News article for Google's silence.

Topic	On the record	Not established
Scale	Nearly 100 separate console deployments since April 2026, found by pivoting on panel titles and frontend artefacts.	Phones infected, deployments active at once, or victims scored. Neither report gives a victim count.
Who	Panels written in Simplified Chinese. Zimperium says the prompts suggest actors who "appear to be operating in China".	A named group or customer. Interface language shows what the developers write in, not where the customers are.
Phone-side call	A key stored in the malware's own settings. Calls go straight from the phone to Gemini flash models. Output capped at 256 tokens, temperature 0.1.	Whose key it is, whether Google was told, whether it was revoked. Whether an image is ever sent: the prompt Cleafy shows mentions a screenshot, the text describes an XML tree.
Console-side call	Estimates bank balances from collected texts and sorts phones into analysed, high-value and mid-value groups.	Accuracy, or that any operator acts on the scores. Cleafy's V6 screen carries a banner saying no Gemini key is configured, so it shows the feature, not its output.
Fraud	"Nothing in the analyzed samples performs a fraudulent transfer this way."	That no operator will. Cleafy calls a return of automated transfer fraud "a scenario worth preparing for".
Google's response	No Google statement appears in either report or in the Hacker News article.	Any action, statement or key revocation by Google.

Where the model sits, and what it is fed

On the phone. When the malware's own tap tables fail on an unfamiliar phone brand, Android version or language, it turns the live screen structure into XML, asks the model where to tap, and gets coordinates back as JSON. Cleafy says the calls go from the phone to Gemini flash models, with the key in the malware's own configuration rather than proxied through the operator's server. It also says this use is "confined to a single problem": keeping the wireless pairing chain working, the sequence that gives the malware a shell on the phone. One line is enough on that chain here.

In the console. The panel takes text messages the malware has already collected and asks the model to extract bank balances. It then lists devices with a rating, a total and the model's own free-text notes, bucketed as analysed, high-value and mid-value. The first console generation could also alert an operator on Telegram when a device's score passed a threshold, which is how Cleafy shows what the scoring is for.

What goes where. Two kinds of data are described: the structure of an on-screen settings flow, from the phone, and the text of stolen messages, from the console. The console also stores passwords typed into fake overlay screens, but Cleafy describes only the messages as the model's input. Where the console's own call originates is not stated. If it runs from a server to Google's API, then Google's systems received victims' message text. Google's abuse-monitoring page says it keeps prompts, context and outputs for 55 days to detect policy violations. Whether that applies to this traffic is not stated. Inference: for anyone assessing an affected customer's or employee's data, the messages may have been processed by a third party as well as read by the thieves, and that question is fair even though the reports do not answer it.

The headline, the vendor title and the report

Table 2. Wording against record. Sources: Hacker News headline of 28 September 2026; Zimperium report of 16 September 2026; Cleafy report of 28 September 2026.

Wording	Where	What the reports show
Uses Gemini to identify higher-value victims	Hacker News headline	True of the latest console: it sorts scored phones into high-value and mid-value. The model is one component of what Cleafy calls a "complete malware factory".
AI-Powered Mobile Threat is Here	Zimperium title	The report's own text lists the model's uses as three lookups on the screen and calls them "non-malicious actions". Neither report describes a model in the overlay, message interception, remote control or shell steps.
harder for security software to detect than traditional, scripted automation	Zimperium summary	An assertion. The report gives no detection data for it. The documented evasion feature is the scheduled rebuild, and that involves no model.
a return of ATS, a scenario worth preparing for	Cleafy conclusion	A forecast from a fraud-detection vendor, with its own limit attached: nothing in the samples does this, and the step from locating a toggle to completing a payment "is not trivial". ATS here means automated transfer routines that drive a banking app to complete a payment.

The label is not the risk. "AI-powered" says nothing about which step the model performs, and the steps differ. Here the model looks up a button when a lookup table fails, and does a clerical extraction over messages that were already stolen. What it changes is cost and reach: a phone the developers never scripted no longer stops the pairing chain, and a person no longer reads every stolen inbox to find the ones worth working. Those are labour savings, not a new way to steal. The mislabel runs the other way too: "console" undersells a panel that builds, signs, publishes and rebuilds the malware on a timer.

A prohibited-use policy is not a control. Google's Generative AI Prohibited Use Policy names malware, fraud and the use of personal data without consent. The Gemini API's abuse-monitoring page describes escalation from an email, to rate limits, to temporary suspension, to permanent closure. But it describes automated scanning "for violations of our Prohibited Use Policy, such as hate speech, harassment, sexually explicit content, and dangerous content", with manual review of projects that consistently look suspicious. A request that says here is an Android screen structure, return the centre of the button called X, is what a legitimate test-automation tool sends. A request to pull balances from a batch of texts is what a legitimate document extractor sends. Nothing in a single request marks it as theft. That is inference. The reports say nothing about whether any request was flagged, and the lever that exists, closing a project or a key, is Google's to pull, not a defender's.

Malware leaning on commercial model APIs is not new on this site. CLOSEDQUORUM asks four commercial models what to do next and obeys the majority, and the Docker botnet installs an open-source agent whose first priority is AI API keys. RATHat is a third arrangement: the model is a helper for a button and a ranking, and the console asks the operator to bring the key.

The implant held still, and the console changed three times

The mismatch of pace is what matters most for how to read the AI angle. The implant design is the same in samples from late 2025, February 2026 and September 2026, according to Cleafy. The console was replaced: an earlier panel called Fisher, then BlackCat, then Panda Workshop V5 and V6. The AI settings are already on the April 2026 BlackCat screen that Cleafy reproduces, with a Telegram alert setting, an AI analysis configuration and a device-side AI setting. So the headline describes the newest console, but the behaviour is at least as old as the first one Cleafy saw.

Six providers to one. BlackCat's AI selector offered Alibaba, Anthropic, DeepSeek, Google, OpenAI and Z.ai, each configured with its own key. In the screenshot Cleafy reproduces, the selector reads OpenAI (GPT-4o-mini). Cleafy does not say which provider any deployment used, and nothing in either report says an Anthropic model was called. By V6 the choice was gone: the panel is Gemini-only and points the operator at Google AI Studio for a key, which Cleafy calls consistent with the free tier being enough for the volume involved. Inference: a component that goes from six suppliers to one in three releases is a commodity to the operator. Revoking one supplier's keys removes one supplier, not the function, and the operator has shown it can ship a new console release within months.

The model names look stale. Cleafy says the V6 configuration offers Gemini 1.5 and 2.0 names: 1.5 flash and pro, 2.0 flash and flash-lite. Google's deprecations page, in an Internet Archive capture of 26 September 2026, lists gemini-2.0-flash and gemini-2.0-flash-lite with a shutdown date of 1 June 2026, shaded as already shut down. That is 119 days (derived) before Cleafy published. The page says a shut-down model is completely turned off and its endpoint is no longer available. It does not list the 1.5 names, so it says nothing about them. Treat this as a question, not a conclusion: a dropdown label may not be what a request carries, the page says its dates are the earliest possible, and Cleafy does not say it tested the feature. But it means "the console uses Gemini" should not be read as "the scoring works today".

What changes for a defender, and what does not

What does not change. The theft: overlays, message interception, remote control and the shell run without a model in every description the two reports give, so a control that caught them last month catches them this month. And the evasion problem, which is the rebuild timer rather than the AI: file-hash blocking is what a scheduled rebuild is built to defeat. The sample hashes in Cleafy's appendix are for looking back, not for blocking forward.

What plausibly changes. Both are inference. First, adaptability: an unfamiliar phone no longer necessarily stops the pairing chain, so a defence that relied on the chain failing on your fleet's phone model or language is weaker. Second, triage: if operators sort by estimated balance, the highest-value customers' phones are likely to be worked first. For banks and wealth firms that is a reason to look hardest at remote-control and overlay signals on those sessions.

What the reports give a defender. Cleafy says security tools should monitor what runs as the shell user, UID 2000, and that the screen-capture tools the native service fetches keep their real filenames, so "any scan of /data/local/tmp identifies them immediately". It also reports that those capture tools do not work on Android 14 and later, which leaves newer phones with the app's own screen capture, its consent prompt and its recording indicator. Zimperium describes the behaviours its product watches for: an app that switches on developer options and wireless debugging by itself, and pairs with the phone's own debug service. On removal, Cleafy says the native service outlives the app until a reboot, and Zimperium says it can reinstall the app and restore its Accessibility access. Neither publishes removal steps.

Checks, in the order worth doing

The question that exposes the gap

Every step in the reports that harms a victim runs without a model. The model finds a button and ranks a list, and Cleafy has not said whose key it used, whether Google knew, or whether the scoring produced anything worth acting on. The exposing question follows from that.

Which of your mobile controls would still fire if RATHat stopped calling any model tomorrow, and if the honest answer is none, what did the AI label add to your risk assessment?