Panel generations recovered: 3 in six months (Source: Cleafy (September 28, 2026))
Cleafy's new research on RATHat, an Android banking trojan, shows where its operators put their effort. The malware on the phone stayed largely the same from late 2025 to September 2026. The control panel behind it was replaced entirely.
The lesson here is that this looks like a factory, and, by Cleafy's inference, a licensed service. Hash-based defences and tools that watch only the app can miss two things: the repackaged files and the shell-level service that runs outside the app. Cleafy points instead to behavioural signals, such as activity under UID 2000 and files in /data/local/tmp.
What Cleafy found
The researchers pulled three successive versions of the criminals' console from the wild. Each is written in Simplified Chinese, and together they were active from April through September 2026. The first called itself BlackCat. The next two were branded Panda Workshop V5 and V6.
V5 added two-factor login for operators and an AI widget that scores victims. V6 obfuscated the whole frontend and added a builder for fake app-store download pages. The panel can build, sign and publish new malware samples without the operator leaving the console.
How the phone is taken over
RATHat reaches victims through malvertising and smishing, meaning malicious ads and text messages. Cleafy reports victims in Europe, Latin America and South-Eastern Asia.
Once the victim grants the app Android's Accessibility Service, the malware operates the phone's own settings. It switches on wireless debugging and copies the pairing code shown on screen. It then uses that code to connect to ADB, Android's built-in developer service. The result is a shell, meaning a command line on the device.
The operator then deploys a native Go service with one click. It runs outside the app's own process and permissions. It keeps a reverse tunnel to the operator and survives removal of the app until the next reboot.
The shell runs as UID 2000, the Android shell user. The malware grants itself this access instead of asking the user to approve a permission. Cleafy says other malware families may adopt the same model. Its advice is to monitor what executes under that user.
The approach has limits. Its screen-capture tools do not work on Android 14 and above. Those phones fall back to a method that shows the victim a consent prompt. Defenders also get one easy break. The capture tools sit under plain names in the /data/local/tmp folder, so a scan of that folder reveals them, the report says.
A product, by Cleafy's reading
Some panel controls do nothing against victims. They cap the number of accounts and hide sections from ordinary operators. Cleafy reads these as controls for a developer who does not fully trust its own customers.
Pivoting on the panel's frontend files, the researchers found nearly 100 separate deployments since April 2026. Cleafy calls that footprint consistent with malware-as-a-service, where each customer runs an instance. This is the researchers' inference. It is not a confirmed sales model.
Think of a franchise. The recipe stays fixed, while the storefront is rebranded, hardened and extended. The panel can also rebuild samples on a fixed schedule, for example every hour. Each file then looks new to hash-based detection while the implant underneath is unchanged.
AI as a triage clerk
AI appears on both sides. On the phone, the malware sends the on-screen layout to a Gemini model, using a key stored in its own configuration. It asks where to tap when its fixed scripts fail on an unfamiliar phone brand or language.
Inside the console, a model goes through SMS texts the malware has already harvested and pulls out bank balances. It then places each phone in a high-value or mid-value bucket. The operator still chooses whom to attack. Cleafy stressed this is prioritisation, not fraud. Operators can skip hand-checking each infected phone.
Cleafy also says nothing in the samples performs a fraudulent transfer with AI. It does warn that the on-phone technique could bring back automated transfer systems, which have been held back by the effort of scripting every banking app separately. Cleafy calls that a scenario worth preparing for.
What leaders should ask
First, ask your fraud team whether detection depends on file hashes. Samples regenerated on a schedule defeat that approach by design.
Second, ask whether mobile defences cover the shell layer. Cleafy points to activity under UID 2000 and to files in /data/local/tmp as places to look.
Third, ask how your bank or payments partners detect a remote session on a customer's phone. On the capture-tool route Cleafy describes, no recording indicator appears.
Fourth, ask whether your fraud models rely on scripted app flows being hard to build. If a model can read a screen and choose the next tap, that cost barrier weakens.
The malware is the stable part of this story. The infrastructure around it is where the change is happening.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cleafy.
