Hirudo is an Android banking trojan that combines credential theft, remote device control, screen capture and SMS interception with a more advanced technique: replacing legitimate banking applications with modified versions designed to bypass their built-in security checks.

According to ThreatFabric, the campaign involves replacements for eight Indonesian banking apps, while its credential-targeting activity spans Indonesia, China, India, Mexico, Morocco and Thailand.

The malware is distributed through seemingly legitimate shopping, entertainment and short-video applications that prompt users to install a separate malicious package disguised as an update.

How the Hirudo Infection Works

Hirudo uses legitimate-looking applications as the entry point for infection. These apps may display functioning storefronts, video catalogues or entertainment content, making them appear trustworthy to unsuspecting users.

The infection process follows several stages:

1. Malicious app distribution: Victims are directed to fake Google Play Store-style pages, reportedly through advertisements on Meta-owned social media platforms.

2. Dropper installation: The user installs a seemingly legitimate shopping or entertainment application.

3. Fake update prompt: The dropper checks whether Hirudo is already installed and may display an update prompt to initiate installation of the separate malware package.

4. Permission abuse: Hirudo requires its own permissions, including Accessibility Service and notification access, to perform its malicious functions.

5. Credential theft and surveillance: The malware can capture credentials, payment PINs, screen activity and SMS messages while enabling remote interaction with the device.

6. Banking app replacement: For targeted Indonesian banking applications, Hirudo prompts the victim to remove the genuine app and installs a modified replacement.

ThreatFabric identified the following dropper applications in its reporting:

These names and package identifiers are investigation leads, not a complete list of all potentially associated applications.

What Makes Hirudo Different?

Traditional Android banking trojans commonly use fake login screens or overlays to capture credentials when victims open financial applications. Hirudo adds another layer by attempting to manipulate the security mechanisms inside the banking application itself.

1. Replacing legitimate banking applications

Hirudo checks the installed banking app and its signing certificate before presenting a fake update prompt. The original application is then uninstalled, while a bank-specific modified version is downloaded.

Although the victim must replace the genuine application, the modified copy can provide a more persistent route to capturing financial activity.

2. Interfering with application integrity checks

The modified banking applications reportedly include a hooking engine designed to manipulate several security signals:

• Signature verification: Return the expected legitimate signing certificate.

• Accessibility checks: Return an empty list when querying enabled accessibility services.

• Screen protection: Remove Android's FLAG_SECURE flag, potentially allowing protected screens to be captured remotely.

• Play Integrity: Relay integrity requests to an operator-controlled server that returns a response for the application to accept.

The report also states that the malware includes a publicly leaked attestation keybox.

Why this matters: A banking application may appear to pass its local security checks even when its code or runtime behaviour has been modified. A successful integrity response alone should therefore not be treated as definitive proof that an application is genuine.

Hirudo's Capabilities

The exact capabilities available on a particular device depend on the installed malware version, granted permissions and campaign configuration.

SOC Investigation: How to Detect and Respond

Security teams investigating suspected Hirudo infections should focus on the installation chain, permission changes, application integrity and possible financial compromise.

Step 1: Identify suspicious applications

Review Android application inventories for unfamiliar shopping, video or entertainment applications installed outside trusted distribution channels.

Check:

• Application name and package identifier.

• Installation source and timestamp.

• APK hash and signing certificate.

• Whether the application was installed shortly before suspicious banking activity.

• Any unexpected removal and reinstallation of banking applications.

Do not rely on the application name alone, as names can be changed or impersonated.

Step 2: Investigate suspicious permissions

Review whether an unfamiliar application has been granted:

• Accessibility Service access.

• Notification access.

• Other sensitive permissions relevant to its behaviour.

Correlate permission grants with application installations, fake update prompts and unusual device activity.

Step 3: Examine banking application integrity

Compare the installed banking APK with a verified version obtained from the bank or another trusted source.

Where possible, validate:

• Package name and signing certificate.

• APK hash and version.

• Unexpected application replacement.

• Changes to security-related code or runtime behaviour.

• Discrepancies between client-reported integrity signals and independent server-side validation.

Preserve evidence before removing suspicious applications, where operationally and legally appropriate.

Step 4: Review suspicious network activity

Investigate connections to unfamiliar domains or infrastructure associated with the suspicious application. Look for unusual communication patterns following installation, permission grants or banking app replacement.

Correlate network evidence with DNS, proxy, firewall and available mobile telemetry. Avoid treating a single unfamiliar connection as proof of compromise.

Step 5: Assess account and financial exposure

Determine whether the affected device accessed banking or wallet applications after infection. Review suspicious authentication events, transaction activity, SMS-related evidence and changes to account recovery settings.

If compromise is suspected, contact the relevant bank through an official channel and follow its fraud-response process. Reset credentials and revoke sessions using a trusted device.

MITRE ATT&CK Mapping

The following are potential investigation mappings based on the reported behaviours. Confirm each mapping against observed evidence before assigning it to an incident.

These mobile techniques belong to MITRE ATT&CK's Mobile matrix. The mappings describe potential behaviour and do not establish that every technique was observed in every Hirudo infection.

Prevention and Defensive Recommendations

For Android users

• Install applications through Google Play or another trusted, verified distribution channel.

• Avoid installing APKs offered through advertisements, pop-ups or unexpected in-app update prompts.

• Review Accessibility and notification access permissions regularly.

• Keep Android and security protections updated.

• Never assume that a familiar-looking banking interface proves an application is genuine.

For financial institutions

• Validate application integrity through server-side controls rather than trusting client-generated signals alone.

• Correlate device integrity, authentication and transaction risk signals.

• Monitor suspicious application replacement and anomalous device behaviour.

• Apply additional verification or transaction restrictions when risk signals conflict.

For SOC and incident response teams

• Retain mobile application inventory, installation and authentication telemetry.

• Correlate suspicious APK activity with identity and financial account events.

• Establish procedures for preserving evidence from potentially compromised mobile devices.

• Treat suspected banking trojan infections as potential credential and financial exposure incidents, not merely malware detections.

Conclusion

Hirudo demonstrates how Android banking malware is evolving from credential-stealing overlays towards tampering with the security checks of targeted applications. By combining deceptive distribution, remote device control and modified banking apps, it can undermine trust in signals that financial applications normally use to assess their own integrity.

For defenders, the central lesson is that application integrity must be independently verified, and mobile security decisions should not rely solely on signals generated by an application that may already be compromised.