Hirudo Android Trojan Replaces Banking Apps to Steal Credentials

* ThreatFabric detailed a banking trojan named Hirudo.
* Hirudo replaces the real banking app instead of using a fake login screen.
* The malware attempts to disable the bank’s security checks from within the application.
* Eight Indonesian banking apps across seven banks have specially designed replacements ready.
* Credential-stealing code targets users in Indonesia, China, India, Mexico, Morocco, and Thailand.
* Delivery is via a dropper disguised as shopping or video apps, loading content via WebView to appear genuine.
* The dropper can create a broken VPN connection during installation to weaken online reputation checks.
* The payload checks the banking app's signing certificate against a reference.
* The modified app loads a hooking engine using YAHFA and Dobby to modify Java methods and native functions upon startup, triggered by a RAT file.
* The engine returns genuine certificates and an empty list for accessibility services to bypass checks.
* A valid Play Integrity response was relayed through the operator’s server rather than generated genuinely.

The core pattern observed is a deliberate shift in the locus of trust: moving security validation from the device-local application environment to an externally controlled, manipulated signal chain. Instead of fighting hard against endpoint detection and response systems, the operation targets the intrinsic integrity mechanisms of the target application itself. This strategy leverages existing system behaviors—like Android’s update mechanisms and Play Integrity checks—as attack vectors. The escalation noted in the report, moving from simple screen overlays to full application replacement, demonstrates a maturity where the adversary understands that local signals are easily subverted, necessitating server-side verification for any meaningful assurance. The implication is that security defenses must evolve beyond monitoring external behavior; they need to account for an environment where the application's internal state and reported integrity can be entirely fabricated by the attacker in parallel with standard processes. This forces a re-evaluation of what constitutes a trustworthy signal when dealing with mobile application security, pushing defensive measures toward robust, non-local attestation methods.
Bridge Questions: If local signals are inherently untrustworthy once an app can be replaced, what specific, verifiable mechanisms can banks implement to establish immutable trust in application integrity that is impervious to in-process modification? How should the industry shift its focus from detecting malware execution to establishing undeniable proof of the application’s entire historical and current state before any security decision is made? What are the long-term systemic risks when reliance on relayed server feedback—even seemingly valid Play Integrity results—is accepted as a legitimate measure of safety?