ThreatFabric's Mobile Threat Intelligence team has identified a new Android banking remote access trojan we track as Hirudo. Hirudo combines on-device credential theft with live remote control of the same phone, and it is delivered by shopping and entertainment apps that carry the trojan as a separate installation package. On their own, those traits place Hirudo alongside the current generation of Accessibility-driven Android bankers. What sets it apart is the lengths its operators go to once a bank is in their sights: rather than overlaying a fake screen on top of the genuine banking app, Hirudo attempts to replace the banking app itself with a modified copy that quietly disables the bank's own security checks from the inside.

In this article we focus on four things: how the banking apps are patched, how the campaign is distributed, who it targets, and the fraud it is built to commit.

Key takeaways

• A new Android banking RAT, Hirudo, blends credential phishing, device takeover, screen and camera capture and SMS theft, tying every stolen value to a device and a target app.
• It replaces banking apps with patched copies. Eight Indonesian banking apps, covering seven banks, have purpose-built replacements that embed a hooking engine to blind signature, Accessibility, screen-capture and Play Integrity checks from within the app.
• A two-app design. A branded lure (shopping, adult video or short drama) carries the RAT as a separate APK and drops it behind a fake in-app "update."
• Distributed with real ad infrastructure. Lures are served from Amazon CloudFront and tied to campaigns through OpenInstall attribution and Meta Pixel IDs; some download routes were still live in October 2026.
• Targeting reaches well beyond Indonesia. Credential targets named in code span Indonesia, China, India, Mexico, Morocco and Thailand, and the bundled fake checkout carries Malaysian bank and wallet branding.
• A mature back office. Backend data captured in August 2026 exposed thousands of credential and device records, lock-screen history and financial profiles.

A two-stage design: dropper and payload

Hirudo ships in two parts. The app the victim installs first is a dropper, wrapped in a convincing lure: a shopping app (Shopora), an adult-video app (1V1 X), or a short-drama app (ZoyaTV / KoiShort). The lure is functional, loading real content in a WebView, a storefront, a video catalogue or short dramas, so the experience looks legitimate. Behind that content the dropper runs a fixed startup routine: it collects promotion-tracking data, fetches its campaign configuration, and checks whether the payload, the Hirudo RAT, is already installed with its Accessibility service and notification access enabled.

If the payload is absent, the dropper displays a fake in-app "update" prompt and offers the bundled payload APK for installation. The payload is installed as a second app and must be granted its own permissions before any of Hirudo's collection or control features can run. One analysed shopping dropper goes further and raises a blackhole VPN during installation, cutting the device's IPv4 traffic while the payload is installed. This approach is currently observed in multiple families active on the threat landscape.

Figure 1. The Hirudo fraud chain. A branded dropper installs a separate payload behind a fake update; once running, the payload drives several theft and control surfaces that report to the operator backend.

Once the payload is running, the fraud surfaces open up. When the dropper's content triggers a payment, it passes the order details to the payload through an Android intent, and the payload renders a fake checkout page in a transparent WebView positioned over the dropper's order screen. The page is branded with the bank or wallet the dropper supplies and localised into eight languages. The victim types a payment PIN, the payload uploads it as appPayPwd, and returns a forged payment-success result to the dropper so the transaction appears to complete.

Figure 2. The bundled fake-checkout page, here with Maybank branding and example order details. The transparent background places the PIN pad over the dropper's own order page.

Separate from checkout, the payload uses bank- and wallet-specific prompts to request login passwords, uploaded as appPwd, and it reads the genuine app's screen to reflect the right user ID or amount back to the victim. It also targets device-unlock secrets: a full-screen fake pattern overlay captures the first pattern drawn and, in one build, the payload reads PIN, password and pattern input directly from the phone's real lock screen through Accessibility. Rounding out the payload's toolkit are live screen viewing over WebRTC, front- and rear-camera sessions, and SMS collection with a 90-day initial scan and a configured list of bank and wallet senders.

Rewriting the bank: how Hirudo patches a banking app

Hirudo keeps a registry of 42 financial apps, but only eight Indonesian apps, across seven banks, have dedicated replacement downloads. For these, the RAT detects the installed banking app through Accessibility, checks its signing certificate against a stored reference, then shows a fake "update" prompt. It opens Android's uninstaller for the genuine app without waiting for the user to tap, and downloads the bank-specific replacement in parallel.

Figure 3. The replacement path. The RAT detects the bank app, removes the genuine copy, downloads the patched APK and drives the installer through Accessibility.

The replacement keeps the original package name and version but is signed with a public Android test key rather than the bank's key. Android therefore refuses to install it as an update over the genuine, bank-signed app, which is why Hirudo removes the original first. This is a real constraint on the technique: it needs the genuine app uninstalled and the installer authorised, both of which the victim can interrupt.

What makes the replacement dangerous is what runs once it is installed. We reverse-engineered one of the patched mobile builds and found that the bank's own code is left almost untouched. A single line is injected into the app's Application class. At launch it loads a self-contained hooking engine from bundled asset files. The engine is built on two well-known open-source frameworks: YAHFA, which replaces Java methods, and Dobby, which hooks native functions. It arms its hooks only when a shared trigger file, written by the RAT, is present on the device, so a patched app sitting idle without the RAT reveals little.

Figure 4. Once the engine is active, the banking app's own security checks return attacker-chosen answers. Each row is a check the app or its SDK performs and what the patched code gives back instead.

With the engine running inside the banking app's own process, the app's defences are turned against it. When the app asks Android for its signing certificate, the hook substitutes the genuine certificate and hides the test-key signature. When it queries enabled Accessibility services, the hook returns an empty list, so the controlling service is invisible. The screenshot-blocking FLAG_SECURE flag is stripped, allowing the banking screen to be viewed and recorded remotely. Key-attestation certificates are re-signed with a bundled keybox, and Play Integrity requests are relayed over plain HTTP to an operator-controlled server, which returns a verdict for the app to accept.

Two details are worth underlining for defenders. First, the attestation keybox the engine ships is not the operators' own: it is a publicly leaked keybox, and we confirmed that at least two of its certificates appear on Google's attestation revocation list, marked as compromised. A backend that checks revocation can still catch its forgeries. Second, because the Integrity request is relayed rather than genuinely produced, a valid Integrity response alone is not evidence of an untampered app. Both facts point to the same conclusion: once an app can be replaced, its locally produced signals, signature, Accessibility list, integrity verdict, must be treated as attacker-influenced and verified server-side.

Distribution: real ad infrastructure, disposable apps

Hirudo's lures are spread the way legitimate apps are. Each lure is themed on content with broad appeal, football and other video, short dramas, and shopping, and pointed at genuine or genuine-looking destinations such as the SparkShop Mall storefront and the KukuTV short-drama catalogue. The malicious APKs are served from Amazon CloudFront, across separate routes for the different lure families and a dedicated host for the eight patched banking apps. Download checks through late September and into October 2026 showed some of these routes still live, with the casino-themed route serving the same dropper recovered in August.

Figure 5. The operator's APK-processing panel, reachable without authentication, rebuilds shell and payload APKs into lures and patched banking apps. Storage buckets and credentials were exposed.

The campaign is stitched together with commodity attribution tooling. A page archived in June 2026 presented a Play Store-style "1v1 vip" install button, used OpenInstall for install attribution, and shared Meta Pixel IDs with the short-drama records in Hirudo's backend, linking the advertised branding to specific campaign groups. Behind the lures sits an operator APK-processing panel, reachable without a login, that rebuilds "shell" and payload APKs into finished lures and patched banking apps, with cloud-storage buckets and credentials left exposed.

Figure 6. Distribution overview. Advertising and attribution feed themed lure apps, delivered via CloudFront and rebuilt by an operator-run APK panel.

Targeting: Indonesia at the core, a wider reach in code

The banking-app replacement is specific to Indonesia: the eight patched apps all belong to Indonesian banks. But Hirudo's configured scope is broader than its replacement set. The analysed RAT's registries also name credential targets across China, India, Mexico, Morocco and Thailand, while the bundled fake checkout carries Malaysian bank and wallet branding.

This layering suggests an operation that has industrialised one region while keeping the machinery portable. The replacement engine, the lure framework and the backend are not tied to any single bank, and the presence of country-named backend groups and multi-country target lists indicates the same toolkit can be, and in places already is, pointed elsewhere.

A back office built for fraud

Behind the phones sits a backend that combines device control with credential, financial and campaign management. Records captured in August 2026 included thousands of application-credential entries, split across short-drama and shopping campaign groups, alongside device records, lock-screen history and financial profiles carrying monthly-income and risk-score fields. Exposed data also showed that the operators even annotate records they consider "phished," a sign of a workflow geared to turning stolen data into cash.

What this means, and what banks can do

Hirudo marks a deliberate escalation in how Android bankers approach hardened applications. By moving its tampering inside the target app, the operation shifts the contest from the device to the application's own integrity checks, and from a bespoke patch to a reusable engine that can be retargeted at other apps and regions. The defensive conclusion is consistent across every capability we examined: signals produced locally by an app that may have been replaced cannot be trusted on their own.

Concretely, financial institutions should:

• Verify and enforce Play Integrity server-side, bound to the session and the protected action, and check attestation revocation. A valid verdict alone is insufficient, because Hirudo relays Integrity requests through its own server.
• Apply layered defences - adding behavioural analytics. When a Trojan like Hirudo tampers the app, some layers might fall. However, behavioural data can help spot fraudulent activity, Even if malware tries to stop behavioural data collection, its absence already serves as suspicious indicator.
• Treat Accessibility and screen-capture signals as supporting evidence, not as blockers. Patched apps can hide their own Accessibility service and strip FLAG_SECURE, so these checks should feed risk scoring rather than stand alone.
• Retain backend transaction-risk controls at login, credential recovery, beneficiary creation and payment approval, where a forged local result cannot substitute for a server-side decision.

Appendix

Indicators of Compromise