A newly documented Android banking trojan called Hirudo no longer just draws fake screens over a bank’s app: it removes the genuine app and installs a doctored copy whose own security checks have been rewired to lie. The campaign targets Indonesian banks today, but the technique undermines assumptions that UK banking app teams rely on every day.
What happened
On 14 October 2026 the Dutch mobile security firm ThreatFabric published research on Hirudo, an Android remote access trojan that pairs credential theft with live control of the victim’s handset. BleepingComputer and The Hacker News covered the findings the same day, and the core facts agree across all three.
The standout feature is app replacement. Hirudo holds a list of 42 financial apps, and for eight of them, belonging to seven Indonesian banks, its operators have built dedicated modified versions. When the malware finds one of those apps, it checks the signing certificate, launches Android’s uninstaller for the real app, and fetches the tampered build in parallel, abusing its Accessibility permission to push the installation through.
Indonesia is the focus of the replacement work, but the code also names credential targets in China, India, Mexico, Morocco and Thailand, and a bundled fake checkout page uses Malaysian bank and wallet branding. ThreatFabric found an exposed operator backend, captured in August 2026, containing thousands of stolen credential entries plus phone details, lock-screen data and financial profiles with income and risk-score fields. Victim numbers are unknown.
The technical picture
Infection begins with a lure: a working shopping, adult video or short-drama app (named examples include Shopora, 1V1 X, ZoyaTV and KoiShort). These droppers deliver the content they promise, then present a bogus in-app “update” that installs Hirudo as a second package, which in turn requests Accessibility and notification access. One dropper even switched on a deliberately broken VPN during installation, cutting off the handset’s IPv4 traffic while the payload landed. The lures were hosted on Amazon CloudFront and promoted with ordinary advertising tooling, and ThreatFabric says some download paths were still live in October.
The doctored banking apps are where it gets interesting for anyone who tests mobile software. According to ThreatFabric, the bank’s own code is barely touched. One injected line in the app’s Application class loads a self-contained hooking engine built on two open-source projects, YAHFA for Java methods and Dobby for native functions. The engine stays dormant until the trojan writes a trigger file, so the modified app reveals little when examined in isolation.
Once armed, it answers the app’s self-checks on the attacker’s behalf:
- Signature checks are handed the genuine bank certificate, concealing that the copy carries a publicly available Android test signature.
- Accessibility queries come back empty, hiding the malicious service.
- Screen protection is removed by stripping FLAG_SECURE, so operators can watch and record banking sessions.
- Attestation and Play Integrity are subverted: a bundled keybox re-signs attestation material, and integrity requests travel unencrypted to an attacker server that supplies the answer.
From there Hirudo collects banking passwords, payment PINs entered into a fake checkout overlay, unlock patterns and SMS messages, and can stream the screen and both cameras.
There are weaknesses. Because the copy lacks the bank’s signing key, Android will not let it overwrite the real app, so the original must be removed first and the victim has two chances to stop the process. The keybox is also publicly leaked, and ThreatFabric confirmed that Google has revoked at least two of its certificates, meaning backends that check revocation can spot the forgeries.
Why it matters for UK organisations
No UK bank appears in Hirudo’s target lists, and nothing suggests UK customers are affected today. The concern is the method. ThreatFabric stresses that the replacement engine, lures and backend are bank-agnostic, and the toolkit already spans several countries. Retargeting it means building new patched apps, not a new malware family.
Many UK banking, building society, fintech and insurance apps make risk decisions partly on what the app reports about itself: genuine signature, no Accessibility service running, screen capture blocked, clean Play Integrity verdict. Hirudo shows that each of those signals can be forged once the app itself has been swapped.
The stakes are real. UK Finance figures reported by FinTech Futures in June put 2025 unauthorised payment fraud losses at £703.4 million, with reported cases up 11 per cent. Device takeover is one route into that category, and techniques that neutralise in-app defences make it cheaper.
Expert view
When we test mobile banking apps, a large share of effort goes on client-side protections: root and hook detection, tamper checks, screenshot blocking, overlay detection. Those controls are worth having, but Hirudo demonstrates a principle testers have repeated for years: anything decided on a device the attacker controls is advisory, not authoritative. If the attacker can replace the binary, the binary’s opinion of itself is worthless.
What stands out is the restraint. One added line and a dormant engine keep the modified build almost identical to the original and make the engine reusable across banks. That mirrors how red teams assess app hardening, and it is why a report stating “integrity checks present” should never be read as “fraud controls sufficient”.
The forced uninstall and the revoked keybox are genuine weak points worth exploiting. In my experience, though, operators fix flaws like these quickly once published, so do not build a defence on them alone.
What to do now
- Verify integrity on the server. Validate Play Integrity and key attestation on your backend, tie them to the session and the specific high-risk action, and check attestation chains against Google’s revocation list.
- Treat client signals as risk inputs. Accessibility status, screen-capture state and signature results should feed a risk score rather than act as the only gate.
- Keep money decisions server-side. Apply step-up checks at login, account recovery, new payee set-up and payment authorisation, so a faked local result cannot approve anything.
- Use behavioural analytics. Remote-controlled sessions behave differently from real users, and missing telemetry is itself a warning sign.
- Test for replacement, not just tampering. Ask your pentest provider how your backend reacts to a re-signed, hooked build of your app.
- Harden managed devices. For corporate Android fleets, apply the Cyber Essentials secure configuration and security update controls through mobile device management: block unknown sources, keep devices supported and keep Play Protect on. Tell customers to install banking apps only from official stores.
Bottom line
Hirudo moves the fight inside the banking app and wins by making the app vouch for itself. It is aimed at Indonesia for now, but nothing in its design keeps it there. UK app owners should assume any locally performed check can be faked, and make sure decisions that move money happen on servers they control.
Sources
- ThreatFabric: Hirudo: From Fake Updates to Patched Banking Apps
- BleepingComputer: Hirudo Android malware replaces banking apps to evade security checks
- The Hacker News: Hirudo Android Trojan Uses Patched Banking Apps to Bypass Their Built-In Security Checks
- IT-Boltwise: Hirudo Android-Banking-Trojan ersetzt Apps mit gepatchten Kopien
- FinTech Futures: UK payment fraud losses topped £1.28bn in 2025, new UK Finance report finds
