Hirudo: the Android banking trojan that rewrites the bank app itself

Most Android banking malware tries to work around a banking app: it draws fake login screens on top, reads notifications, or abuses accessibility to tap buttons. Hirudo goes further. Researchers at ThreatFabric found that it removes the genuine banking app and installs a tampered copy whose own built-in security checks have been neutered. That is a meaningful step up for mobile financial fraud.

What happened

ThreatFabric describes Hirudo as a remote-access trojan (RAT). It combines credential theft, full device takeover, screen and camera capture, and SMS interception, all run from a fairly mature operator backend.

Delivery. Victims are reportedly lured through social-media ads on Meta platforms to fake "Google Play" landing pages promoting shopping, short-drama, football and video apps. The researchers named lure apps including Shopora, 1V1 X, KoiShort and ZoyaTV. These droppers actually work: they load a real storefront or video catalogue in a WebView, so nothing looks wrong. In the background, the dropper checks whether the Hirudo payload is present with accessibility and notification access enabled. If it isn't, the dropper shows a fake "in-app update" to get it installed. Hirudo runs as a separate app and still needs the victim to grant its permissions.

Evasion. Like the related StreamRat family, the dropper sets up a deliberately broken VPN connection just before the payload is installed. This cuts the device off from cloud-based reputation checks. Play Protect's offline detection still works, so ThreatFabric judges this a way to weaken scanning rather than switch it off entirely.

Classic banker features. Once it has permissions, Hirudo can show fake PIN pages over a lure's checkout screen, display bank- and wallet-branded login prompts, draw fake lock-screen pattern/PIN overlays, and give operators live remote control over WebRTC.

The new part: app replacement. For eight mapped Indonesian banking apps, Hirudo:

1. uses accessibility to detect the open banking app and compares its signing certificate with a stored reference,
2. shows a fake "update" prompt, opens Android's uninstaller for the genuine app without waiting for a tap, and downloads a bank-specific replacement APK at the same time,
3. opens the replacement in the system installer and uses accessibility to click through installation and permission screens.

The replacement APKs keep the original package name and version but are signed with a public Android test key. That is why the genuine app has to be removed first: Android won't install them as an update over the bank-signed original. Inside, an embedded hooking engine lies to the app's self-defence checks. It reports the genuine signing certificate, returns an empty list of enabled accessibility services, and strips FLAG_SECURE so screens can be viewed and recorded remotely. Key-attestation certificates are re-signed with a bundled keybox, which ThreatFabric says is a publicly leaked one rather than the operators' own. Play Integrity requests are relayed over plain HTTP to an attacker server that returns a verdict for the app to accept.

Targeting of credentials reaches beyond Indonesia, to China, India, Mexico, Morocco and Thailand. The backend also stores device records, lock-screen history and victim "financial profiles" with income and risk-score fields. According to the researchers, much of this backend was left without authentication.

Why it matters

Hirudo moves the fight from the device into the app. Many mobile banking defences assume that if the app is running, its local checks for tampering, accessibility abuse, screen capture and attestation can be trusted. Once an attacker can swap in their own build, every client-side signal can be faked. A passing Play Integrity verdict, on its own, does not prove the app is unmodified.

The hooking engine is also reusable. ThreatFabric describes it as a retargetable framework rather than a one-off patch, so other apps and regions can be added with little effort. Indonesia is where it was observed, not necessarily where it stops.

What to do

For banks, fintechs and mobile app teams

• Verify server-side, not in the app. Treat signature, accessibility, root/hook and integrity results reported by the client as attacker-influenced. Request Play Integrity tokens with a server-generated nonce, decrypt and validate them on your backend, and check the app-recognition and certificate-digest fields there.
• Don't trust a single "valid" attestation. Combine it with device binding, behavioural and session analytics, and transaction risk scoring.
• Watch for reinstall patterns. If an app is suddenly uninstalled and reinstalled on a known device with a changed install source or signer, step up authentication or freeze high-risk actions.
• Harden transaction flows. Require out-of-band or hardware-backed confirmation for high-value transfers and for changes to payees or devices.
• Monitor brand abuse. Look for fake Play Store pages and social ads that use your brand or point to sideloaded APKs, and report them for takedown.

For organisations and end users

• Install apps only from the official Google Play Store, never from a link in an ad. A "Play Store" page opened in a browser is a red flag.
• Be very suspicious of an app asking you to install an "update" as a separate app, or asking for Accessibility or notification access.
• If your banking app suddenly asks to be uninstalled or "updated" outside Google Play, stop and contact your bank.
• On corporate fleets, use MDM to block unknown install sources and restrict which apps can be granted accessibility rights.

Credit: technical research by ThreatFabric; originally reported by The Hacker News. Summary and analysis by the 4Tify Team.