When the Banking App Becomes the Attack Surface

Overview

A new Android banking malware called Hirudo is demonstrating a more advanced approach to mobile financial fraud: instead of simply impersonating a banking application, it replaces the legitimate application with a modified version designed to disable its security controls. Researchers have identified malicious copies of banking applications targeting financial organisations across Indonesia, China, India, Mexico, Morocco and Thailand. The malware can steal banking credentials, payment PINs, SMS messages and device secrets while providing attackers with remote access to the infected device, including screen viewing, audio recording and camera access. The significant development is how Hirudo attempts to remain inside the trusted banking application while turning its own security mechanisms against it.

The Attack Starts With a Fake Update

Hirudo is typically delivered through applications that appear unrelated to banking, including shopping, adult-content and short-drama applications. These applications can provide their advertised functionality while acting as loaders for the malware. Once installed, the malicious application presents the victim with a convincing update request and subsequently attempts to obtain permissions, including Android Accessibility access. Accessibility is particularly valuable to malware because it can provide powerful interaction with applications and device interfaces. Hirudo uses this capability to begin replacing the legitimate banking application with a modified copy. The result is a particularly deceptive attack chain:

Legitimate-looking application → fake update → permissions → banking application replacement → credential theft.

The Legitimate App Is Rebuilt Into the Attack

The most interesting part of Hirudo is that the malicious banking application reportedly retains most of the original banking application’s code. Rather than creating an entirely fake banking application from scratch, attackers modify the legitimate application and introduce a hooking engine based on open-source YAHFA and Dobby frameworks. This gives the malware an important advantage. The application can continue to look and behave like the legitimate banking application while selected security functions are intercepted or manipulated. Security checks that would normally identify an altered environment can therefore produce results favourable to the attacker.

Security Controls Can Become the Attack Surface

Hirudo reportedly interferes with several security mechanisms. It can substitute the legitimate signing certificate when the application checks its identity, conceal enabled Accessibility services and modify screenshot protections. It can also manipulate key-attestation information and relay Play Integrity requests through attacker-controlled infrastructure. This creates an important security lesson. A security control can be technically present while its result has been manipulated. The banking application may ask:

“Am I running in an approved environment?”

The malware can attempt to ensure the answer is effectively:

“Yes.”

This is fundamentally different from simply bypassing a login screen.

Device Integrity Cannot Be the Only Trust Signal

Hirudo demonstrates why mobile banking security cannot depend entirely on checks performed inside the application process. If malware controls the environment in which those checks execute, local validation can potentially be intercepted or manipulated. ThreatFabric therefore recommends stronger server-side validation, session-bound integrity checks and additional controls around sensitive transactions. This approach changes the trust model. Instead of trusting the application simply because it reports that its environment is legitimate, the banking platform can combine multiple signals before authorising high-risk actions. Transaction behaviour, session characteristics, device reputation and server-side attestation can all contribute to the decision.

The Fraud Does Not End With Credential Theft

Hirudo reportedly goes beyond harvesting usernames and passwords. The malware can capture payment PINs, SMS messages and device-unlock secrets while providing remote access to the infected device. Fake payment interfaces can also be used to collect sensitive information before displaying a fabricated successful-payment message. This is an important evolution in mobile banking attacks. The objective is not necessarily to steal a password and leave. The attacker wants to control the transaction environment itself while keeping the victim convinced that everything is working normally.

Expert in the Cloud Insight

Hirudo highlights a fundamental weakness in application-centric security models. A banking application can contain strong cryptographic controls, certificate validation, integrity checks and anti-tampering mechanisms. But if those controls rely too heavily on information that can be intercepted from inside the compromised application environment, their security value can be reduced. The answer is not to abandon application security.

It is to avoid making the application the sole authority for deciding whether it can be trusted.

Mobile financial security increasingly requires multiple independent layers: application integrity, server-side attestation, session protection, behavioural analytics and transaction-risk controls. For users, the immediate protection remains equally important: keeping Android updated, avoiding unofficial APK sources and reviewing unexpected permission requests. For financial platforms, however, the deeper lesson is architectural:

A trusted application cannot always be trusted to report accurately on its own security state.

When the application itself becomes compromised, the strongest security decision may need to happen outside the application.

Be the first to comment

Leave a Reply

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.