RATHat is an Android banking trojan recently documented in public reporting, distinguished by an architecture in which the malicious application is only the entry point. Once granted the Accessibility Service, the application enables wireless debugging on its own, pairs with the device's ADB daemon to obtain a shell, and uses it to stage a native Go service and an FRP client that opens a reverse tunnel to the operator. The service runs outside the application's process and permission model, keeps its own channel to the C2, and survives the removal of the application until the next reboot. A shell that the malware grants itself, rather than a permission the user grants the application, is a model other families may adopt, and security controls should extend to this scope.
The operation's visible investment, however, lies in its infrastructure. Samples from late 2025, February 2026, and the current campaigns share the same implant design with limited changes, while the operator C2 panel was replaced entirely. Three generations were recovered, all written in Simplified Chinese and live between April and September 2026: an unversioned first release self-identifying as BlackCat, followed by Panda Workshop V5 and V6. V5 renamed the entire API surface, introduced two-factor authentication for operators, and added an AI balance-scoring widget; V6 obfuscated the whole frontend, added a phishing download-page builder, and consolidated its AI features on Gemini. The panel builds, packs, signs and publishes new samples without the operator leaving the console, and can regenerate its payload on a fixed schedule to defeat hash-based detection. Account caps and role-gated sections exist to constrain the panel's own users, and pivoting on its frontend artifacts resolves the three generations to nearly 100 separate deployments since April 2026, nearly half on a single Singapore ASN. That footprint, together with parallel campaigns across Europe, LATAM, and South-Eastern Asia, is consistent with a MaaS model.
AI appears on both sides of the operation. The malware calls Gemini models directly from the device, with an API key embedded in its configuration, to locate on-screen controls when its static automation fails on unknown OEM skins or languages. The panel uses an LLM to extract bank balances from the collected SMS messages and to score each device. The device-side use deserves attention beyond this campaign: an LLM that reads the interface and returns the next action makes a return of ATS, without the per-target engineering that made it expensive, a scenario worth preparing for rather than a speculative one.
RATHat was recently documented in public reporting as an Android banking trojan distributed through malvertising and smishing against victims in Europe, LATAM and South-Eastern Asia. What separates it from a conventional Android RAT is that the Android application is only the entry point. Once the Accessibility Service is granted, the application drives the device through its own settings to enable wireless debugging, reads the pairing code off the screen and pairs with the local ADB daemon, obtaining a shell on the phone. It uses that shell to deploy a native Go service, executed outside the application's own process, and to stage an FRP client that opens a reverse tunnel to the operator's infrastructure.
That architecture is not new to this campaign. The same design is present in samples distributed at the end of 2025 under a crypto trading bot decoy, and in a February 2026 campaign using a "StripChat" decoy against South-Eastern Asia. Comparing those samples with the current ones shows how little the implant itself moved over the period. However, the infrastructure behind it did not follow the same pattern. The early samples connect to a panel internally namedFisher, which no longer serves any of the deployments associated with the recent campaigns: between February and September 2026 the operator console was rebranded, re-namespaced, hardened and extended with new capabilities across three successive generations, while the malware it controls stayed broadly the same.
This article, therefore, focuses on what sits behind the implant: how the operator panels work, how they evolved across those three generations, and how each capability described above is activated and managed from the console.
Three panel generations were recovered, all living between April and September 2026, and all built from a common source tree. Each carries its own branding, APIs namespace and feature set, and this chapter tracks what changed between them.
Analysis of panel artifacts revealed three distinct generations derived from a single unified codebase: an unversioned first generation self-identifying as 黑猫远控管理 (BlackCat Remote Control Management), followed by two releases branded 熊猫工坊 (Panda Workshop), V5 and V6. The legacy “Fisher” panel, associated with the December 2025 campaigns, is excluded from this analysis because it shares no common codebase with subsequent versions.
Two indicators link the generations to a single codebase. The react-vendor and redux-vendor chunks, two artifacts of the frontend framework, are SHA256-identical between BlackCat and Panda Workshop V5, so both were built from the same source tree with the same dependency set. The second indicator reaches further back: V6 mirrors its navigation state to localStorage["fisher_current_page"], carrying the name of the panel used in the earlier campaigns, where BlackCat uses the neutral device_current_page. Against this moving frontend, the command set pushed to the device is broadly stable across all three generations.
The panel serves as far more than a standard C2 console, providing a complete, end-to-end APK production line that spans from payload compilation to final delivery.
Instead of relying on manual compilation or external scripts, the panel natively handles the entire build lifecycle directly from the GUI. It features an integrated packing subsystem, where the malicious payload is packed into a dropper application that acts as the decoy. The configuration allows operators to seamlessly define server URLs and the decoy page, as well as toggle required device permissions on or off with a single click.
Builds do not require an operator at the keyboard. The panel features an automatic build configuration that can be toggled on to schedule builds at a defined interval, such as every 1 hour. This allows an instance to regenerate its payload on a fixed cadence without manual interaction. Repackaging on a schedule is a direct answer to hash-based detection: each cycle produces a fresh artifact while the underlying implant is unchanged.
Publishing is handled by two independent paths, both configured and connectivity-tested from within the panel:
An operator therefore builds, signs, and publishes a new sample without leaving the console or directly touching the hosting infrastructure.
V6 extends the pipeline one step further by adding a download page section. Pages are created from a set of templates, including a “Google Store” layout. Operators can customize this landing page by populating fields such as application name, description, version, rating, download volume, etc. Which stage of the delivery chain these pages serve cannot be determined from the panel alone: they are consistent both with the landing page that distributes the first-stage dropper and with the page rendered at dropper execution to fetch the payload, and the panel does not carry enough context to separate the two.
Several controls in the panel exist for the benefit of whoever built it rather than whoever uses it. The number of concurrent accounts is capped by /api/license/max-users. Navigation is gated on role === 'superadmin'/'admin', hiding entire sections from ordinary operators. None of these features add a single capability against a victim. They exist to constrain and audit the panel's own users, which only makes sense when those users are customers who the developers do not fully trust and cannot otherwise observe.
The hypothesis is testable from outside. Pivoting on the panel titles and frontend artifacts resolves the three generations to nearly 100 unique deployments since April 2026. Three software releases spread across that many parallel deployments is not the footprint of one team's internal console: each customer runs their own instance, and the seat cap governs the operators inside a single instance rather than the operation as a whole.
Hosting concentrates on AS4907 (BGPNET PTE. LTD., Singapore), which carries nearly half of the observed IPV4 addresses. Naming is systematic enough to serve as a pivot in itself. Two subdomain roles recur, admin. for the operator frontend and, in V6 only, adminapi. for the API backend, frequently both on the same registrable domain. Labels rotate across the cheapest available TLDs (.best, .beer, .top, etc.), with the same label often appearing under multiple TLDs resolving to one address.
Everything described so far sits on the operator's side of that tunnel, this chapter crosses it. Each section takes a capability, sometimes a group of related ones, and follows it from the control the operator clicks in the panel down to the code that executes it on the infected device.
Once the Accessibility Service is granted, the malware automatically enables the wireless debugging pairing and the resulting connection runs as UID 2000, the shell user. The Go service is not deployed automatically at this point: the operator triggers it.
From the device view, the Accessibility tab (Figure 7) exposes the panel's full control set, and the 一键部署 (one-click deployment) group at the bottom of the command list. There are several options to enable the service: 部署服务 (deploy service) sends DEPLOY_LOCAL_SERVICE over the WebSocket channel, deploying the binary on a device that is already paired, while 完整部署 (full deployment) sends FULL_DEPLOY, which retries the wireless pairing before deploying and is the option used when the pairing did not complete on its own.
Upon receiving the command, the application copies the binary into /data/local/tmp and launches it detached. From that point, the service is independent of the application process: it runs its own setup, performs anti-analysis checks, and binds a local HTTP server on port 7912. That server backs the panel's ADB tab (Figure 7), which becomes usable only after deployment and groups its controls by function. Each button resolves to a bridge() call that carries the command over the WebSocket channel, falling back to the FRP tunnel when it fails.
The panel implements a mechanism to automatically or manually upload HTML templates for credential exfiltration. When the malware boots up, it retrieves the list of global templates through /api/injection/global-configs that are preloaded in the panel.
The WebSocket command that sends a template is SHOW_INJECTION. When the injection is active, every time a specific application is launched, the HTML template will be put on top of the screen, and every input string will be uploaded to the C2 with HTTP POST requests.
Around this sit the panel's per-device data views: the drawer exposes separate tabs for device logs, password records, SMS records, contacts, the photo gallery, file management and installed applications, giving the operator a browsable copy of the device's contents.
The collection does not follow a single pattern, and the differences reveal where the stolen data actually lives. The SMS view combines both channels: opening it issues a paginated HTTP call to /api/sms/notifications?deviceId=... that returns previously collected messages without involving the device, while the refresh button emits a WebSocket message of type SMS_READ with a limit of 9999, forcing the collection of the newer messages. While credential records have no equivalent refresh, the password tab loads its history from the APIs, with live records arriving through the WebSocket events password_detected, and there is no operator command to force a re-collection.
The two approaches of the malware are visible to the operator as a choice:
The trade-off between the two is visibility. MediaProjection requires the victim to approve a consent dialog and leaves a persistent recording indicator on screen for as long as the capture runs. The minicap path has no equivalent exposure: no dialog is shown, no recording indicator appears, and nothing in the Android permission model records that screen capture is taking place, because the capture runs as UID 2000 rather than as the application. Where minicap cannot be used, the service falls back to screencap, which delivers roughly five frames per second, enough for a fraud session.
The shell path carries its own costs. Neither tool works on Android 14 and above, so the newest devices are left with the MediaProjection and Accessibility combination and its consent prompt. Also, pulling the binaries from the C2 makes the capability dependent on a reachable server and leaves an artifact on disk, and their filenames are not obfuscated, so any scan of /data/local/tmp identifies them immediately.
Two distinct AI integrations appear in this operation, serving different purposes on opposite sides of the tunnel. They are described separately here, since conflating them would overstate what either artifact shows.
Panel side. The console uses a model to estimate a victim's balance from the SMS it has already collected. The pitch is stated in the interface itself: the panel analyses all SMS on all devices, extracts bank account balances and syncs the results back to the device list. Panda Workshop V6 gives this a dedicated page, backed by /api/ai/finance-balance-list, showing a scored inventory in which each device carries an AI rating, a total balance, a per-account breakdown holding the model's own observations as free text, and an analysis timestamp. Devices are aggregated into analysed, high-value and mid-value buckets, so an operator identifies the targets worth attacking without inspecting all the infected devices by hand. Panda Workshop V5 delivers the same capability one device at a time, as a floating widget that calls /api/ai/finance-analysis/<deviceId>, which scores whichever victim the operator is already looking at.
Device side. The implant uses an LLM to keep its own automation working. Every step of the ADB pairing chain depends on finding the right control on screen, and the static locator tables that drive it are built per OEM skin, per Android version and per language, so they fail on any device the developers did not anticipate. When that happens, the implant serializes the live AccessibilityNodeInfo tree to XML and asks the model where to tap, receiving the center coordinates of the named control as JSON, or asks it to read back the on-screen text of a node when a localised label needs resolving. The calls go directly to Gemini flash models from the device, using an API key stored in the malware's own configuration rather than proxied through the C2. The parameters are tuned for the task rather than for conversation, with temperature fixed at 0.1 and output capped at 256 tokens, since the expected answer is a coordinate pair or a short string. The panel exposes the same mechanism as an operator setting, labeled AI UI 适配功能 (AI UI adaptation function), which invokes Gemini to locate UI elements when text matching fails on unfamiliar ROM versions and in multi-language environments, with a second toggle for a forced AI mode marked as test-only.
The integrations evolved over time. Panel-side AI began provider-agnostic: BlackCat exposed a service selector offering different providers (Alibaba, Anthropic, DeepSeek, Google, OpenAI and Z.ai), each configured through /api/ai/config with its own key. By V6, that selector is gone, and the configuration is Gemini-specific, offering 1.5-flash and pro, 2.0-flash and flash-lite. Both sides of the operation therefore converged on one vendor, and the interface points the operator at Google AI Studio to obtain a key, which is consistent with the free tier being sufficient for the volume involved.
One capability from BlackCat is worth noting because it shows what the scoring was for. The Telegram integration, configured alongside the AI settings, allows the operator to receive alerts for devices whose AI score exceeds a threshold: the model is not performing fraud, it is deciding which victims are worth an operator's time.
RATHat is not the first Android malware to abuse wireless debugging to obtain a shell on the device it infects, but it is one of the most complete implementations of the technique observed so far. What earlier families used as a narrow privilege escalation has matured here into an operational layer: a native Go service, staged outside the application's lifecycle, reachable through its own reverse tunnel and deployed by the operator with a single button. The approach still carries real constraints, from the pairing chain's dependence on a successful Accessibility grant to the shell-side tools that stop working on Android 14 and above. A shell that the malware grants itself, rather than a permission the user grants the application, is a model that other families might decide to adopt, and security measures should monitor what is being executed with UID 2000.
The second development is smaller in scope but potentially more consequential. The implant is among the first to hand control of On-Device actions to an LLM, serializing the live interface and asking the model where to tap. In this campaign, that capability is confined to a single problem, keeping the wireless pairing chain working on devices that the static locator tables do not cover, but the same mechanism generalizes well beyond it.
ATS has historically been limited by maintenance cost, since every target banking application and every new version of it required a dedicated routine describing the exact sequence of screens, fields and buttons needed to complete a payment. A model that reads the accessibility tree and returns the next action removes that constraint, replacing a library of per-application scripts with a single generic loop. Nothing in the analyzed samples performs a fraudulent transfer this way, and the step from locating a toggle to completing a payment is not trivial. But the building blocks are already present and working in a live operation, which makes a return of ATS, this time without the per-target engineering that made it expensive, a scenario worth preparing for rather than a speculative one.
Be among the first people worldwide to receive comprehensive technical reports on newly uncovered threats.
Subscribe now
.jpg)