Hirudo Android Trojan Replaces Banking Apps to Steal Credentials
October 15, 2026 
Android trojan Hirudo replaces genuine banking apps with modified versions to steal credentials and bypass security checks, enabling financial fraud.
ThreatFabric researchers detailed a new Android banking trojan called Hirudo that takes a genuinely different approach to defeating banking security. Instead of throwing a fake login screen over the real app, it uninstalls the real app and puts a modified copy in its place.
“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.” reads the analysis published by ThreatFabric.
Eight Indonesian banking apps from seven banks already have specially designed replacements ready. The malware’s credential-stealing code also targets users in Indonesia, China, India, Mexico, Morocco, and Thailand.
Hirudo is delivered as a second app hidden inside a convincing dropper. The dropper looks like a legitimate shopping app, short drama platform, or adult video service. It loads real content through a WebView to make the app look genuine. If it detects a banking app on the device and finds that Hirudo is not yet installed, it displays a fake in-app update prompt.
One dropper analysed by researchers goes a step further. During installation, it creates a deliberately broken VPN connection that cuts off the device’s internet access while Hirudo is installed. This does not fully bypass Google Play Protect, but ThreatFabric believes the technique is designed to weaken online reputation checks and code analysis while the malicious APK is being installed. Hirudo is then installed as a separate app from the dropper. Before it can carry out its malicious activities, it must obtain its own Accessibility and notification permissions.
When the payload detects a target banking app, it checks the app’s signing certificate against a stored reference, then shows a fake update prompt and immediately opens Android’s uninstaller without waiting for the user to tap confirm. It downloads the patched replacement in parallel.
“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.” reads the analysis. “It opens Android’s uninstaller for the genuine app without waiting for the user to tap, and downloads the bank-specific replacement in parallel.”
The replacement keeps the original package name and version number, but it’s signed with a public test key rather than the bank’s real certificate. Android won’t install it as an update over a properly signed app, which is why the original has to go first. That requirement is a real constraint: the victim can interrupt it. But if they don’t, what follows is clever enough to matter.
The bank’s original code remains almost unchanged. Only one line is added to the app’s Application class. This line loads a built-in hooking engine when the app starts. The engine uses two open-source frameworks: YAHFA to modify Java methods and Dobby to modify native functions. It activates only when it finds a trigger file created by the RAT on the device. Without this file, the modified banking app appears harmless.
Once activated, the engine runs inside the banking app and controls how it responds to security checks. If the app asks for its signing certificate, the engine returns the genuine one. If it checks which accessibility services are enabled, the engine returns an empty list. It also removes the flag that blocks screenshots, allowing the attacker to view and record the banking screen remotely.
Play Integrity checks are sent over plain HTTP to a server controlled by the operator, which returns an acceptable result. Researchers highlight two important points. First, the keybox used for attestation has been leaked publicly, and at least two of its certificates are already on Google’s revocation list. Second, a valid Play Integrity response does not prove that the app has not been tampered with. In this case, the response was relayed through the operator’s server rather than generated through a genuine integrity check.
The lures don’t spread through side-loaded APKs from shady forums. They’re served from Amazon CloudFront, tied to campaign tracking through OpenInstall attribution, and linked to Meta Pixel IDs connecting specific branding to specific campaign groups. Some download routes were still live through late September and into October 2026. The operator APK-processing panel, which rebuilds dropper and payload APKs into finished lures and patched banking apps, was reachable without authentication, with cloud storage buckets and credentials left exposed, a significant operational security failure that helped ThreatFabric map the operation.
Records from August 2026 included thousands of credential entries split across campaign groups, device records, lock-screen history, and financial profiles with monthly income and risk score fields. Operators annotated records they considered “phished,” which signals a workflow built to convert stolen data into actual fraud rather than just collect it.
ThreatFabric’s conclusion on the defensive side is worth reading directly: “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.” A valid Play Integrity verdict from a relayed request is not a green light. A clean accessibility list from a patched app is not evidence there’s no controlling service running. The signals the app produces locally are no longer trustworthy, and any bank relying on them as blockers rather than inputs to server-side risk scoring is running on assumptions this trojan was designed to exploit.
“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.” concludes the report. “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.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
Pierluigi Paganini
(SecurityAffairs – hacking, Android malware)
