Hirudo Android Banking Malware: Detecting and Defeating App-Replacement Credential Theft

A new Android banking trojan dubbed Hirudo has emerged with a technique that should concern every organization whose employees or customers transact from mobile devices: rather than overlaying fake login screens or abusing accessibility features in isolation, Hirudo replaces legitimate banking applications with modified, trojanized versions of the same apps — versions in which the built-in security checks have been deliberately disabled. The victim opens what appears to be their normal banking app, and their credentials flow straight to the attacker.

This is a meaningful escalation in mobile malware tradecraft. Root detection, tamper-evidence, certificate pinning, and repackaging detection exist precisely to stop modified banking apps from operating. A malware family that strips or bypasses those controls at the repackaging layer neutralizes years of defensive engineering invested by banking app developers. For SOC teams, CISOs, and mobile threat defense owners, the actionable takeaway is this: you can no longer rely solely on the banking app's self-protection. Detection must move to the device, the network, and the identity layer.

This post breaks down the reported Hirudo behavior, walks through detection content you can operationalize today, and provides an audit script and remediation playbook.

Technical Analysis

What Hirudo Does

Based on the reported behavior, Hirudo's attack chain works as follows from a defender's perspective:

1. Delivery / sideloading. The victim is lured into installing an APK outside of Google Play — typically via phishing pages, SMS lures, or malicious third-party app stores. The delivered package is a modified clone of a legitimate banking application.
2. App replacement. Hirudo replaces the legitimate banking app on the device with the trojanized build. To the user, the icon, name, and UI look identical. Under the hood, the package signature changes (it is no longer signed by the bank's legitimate developer certificate) and the install source is no longer Google Play.
3. Security check neutralization. The modified APK has its defensive controls disabled or stubbed out — the classes of controls that banking apps normally enforce include root/jailbreak detection, debugger and hooking detection (anti-Frida), tamper/repackaging detection, and TLS certificate pinning. With these gutted, the trojanized app can operate on compromised devices, survive inspection attempts, and communicate with attacker infrastructure without pinning failures.
4. Credential capture. When the victim authenticates, the modified app harvests banking credentials and exfiltrates them to attacker-controlled infrastructure, enabling account takeover and fraudulent transactions.

Why This Technique Is Dangerous

• It defeats in-app self-defense. Every control implemented inside the app binary can be removed from the app binary by a sufficiently motivated repackager. Hirudo demonstrates this is happening operationally, not just in research papers.
• Signature mismatch is the tell. A replaced banking app will not carry the bank's genuine signing certificate. Devices that verify installer source and signing identity can catch this deterministically.
• It scales through social engineering, not exploits. The prerequisite is the user installing an APK from an untrusted source — meaning "Unknown Sources"/sideloading policy is a primary control, not an afterthought.

Affected Platforms and Exploitation Status

• Affected platform: Android devices on which users install the trojanized banking APK. Devices restricted to Play Store installs with Play Protect active, or under enterprise management with sideloading blocked, have materially lower exposure.
• Exploitation status: This threat is active in the wild per the source reporting. There is no CVE associated with this activity — it is malware tradecraft, not a patchable software flaw. No vendor patch will fix it; the mitigation is policy, detection, and user-behavior hardening.

Detection & Response

The highest-fidelity detection opportunities for Hirudo-class app replacement are: (1) sideloading events, (2) package signature/installer-source mismatches on banking apps, and (3) ADB-driven installation activity from managed endpoints. The content below is built around those observables.

Sigma Rules

---
title: ADB Package Installation on Managed Windows Endpoint
id: 3f9a2b71-4c8d-4e1f-9a6b-7c5d2e8f1a04
status: experimental
description: Detects use of the Android Debug Bridge to install APK packages onto connected devices from a workstation. A common vector for sideloading trojanized banking apps such as Hirudo, and unusual outside developer/QA teams.
references:
  - https://www.bleepingcomputer.com/news/security/hirudo-android-malware-replaces-banking-apps-to-evade-security-checks/
  - https://attack.mitre.org/techniques/T1476/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1476
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\adb.exe'
    CommandLine|contains:
      - ' install '
      - ' install-multiple '
      - ' pm install '
falsepositives:
  - Android developers and QA engineers deploying builds
  - MDM/EMM administrators provisioning test devices
level: medium
---
title: APK File Dropped in User Download Directories
id: 8c1e5d39-2f6a-4b7c-a3d9-5e4f6a8b9c1d
status: experimental
description: Detects creation of Android APK files in user download or desktop directories on managed endpoints. Trojanzied banking APKs like Hirudo payloads are commonly staged on a workstation before transfer or sideloading to a device.
references:
  - https://www.bleepingcomputer.com/news/security/hirudo-android-malware-replaces-banking-apps-to-evade-security-checks/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|endswith: '.apk'
    TargetFilename|contains:
      - '\Downloads\'
      - '\Desktop\'
      - '\AppData\Local\Temp\'
falsepositives:
  - Developers building Android applications
  - IT teams distributing legitimate enterprise APKs
level: low
---
title: Package Install or Replace from Non-Play-Store Source (Android Logcat)
id: 5b7d3f12-9a4c-4e8b-b2f1-6d3c8a5e7f29
status: experimental
description: Detects Android package install/replace events where the installer of record is not Google Play or an approved enterprise store. A Hirudo-style replaced banking app will show a non-Play installer and a changed signing certificate. Tune the exclusion list to your approved EMM agent package names.
references:
  - https://www.bleepingcomputer.com/news/security/hirudo-android-malware-replaces-banking-apps-to-evade-security-checks/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.initial_access
logsource:
  product: android
  service: logcat
detection:
  selection:
    EventMessage|contains:
      - 'PackageManager: Replacing package'
      - 'PackageInstaller: Install succeeded'
  filter_play_store:
    EventMessage|contains:
      - 'com.android.vending'
  condition: selection and not filter_play_store
falsepositives:
  - Enterprise mobility management agents pushing internal apps
  - OEM system updaters
level: high

KQL — Microsoft Sentinel / Defender

This query hunts Android devices onboarded to Microsoft Defender for Endpoint for recently observed app installation activity and correlates with network connections from Android devices to rare or newly seen destinations — the exfiltration behavior expected from a credential-stealing trojanized app.

// Hirudo hunt: Android sideloaded apps + anomalous network egress
let lookback = 14d;
let androidDevices = DeviceInfo
    | where Timestamp > ago(lookback)
    | where OSPlatform has "Android"
    | summarize by DeviceId, DeviceName;
// Part 1: App/package installation events on Android devices
DeviceEvents
| where Timestamp > ago(lookback)
| where DeviceId in (androidDevices)
| where ActionType has_any ("AppInstalled", "PackageInstalled", "SideLoadedAppInstalled")
    or (InitiatingProcessFileName has_any ("packageinstaller", "pm", "adb"))
| project Timestamp, DeviceName, ActionType, FileName, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine
| summarize InstallEvents = count(), Files = make_set(FileName) by DeviceName, bin(Timestamp, 1h)
| where InstallEvents > 0
| join kind=leftouter (
    // Part 2: network egress from the same devices to uncommon destinations
    DeviceNetworkEvents
    | where Timestamp > ago(lookback)
    | where DeviceId in (androidDevices)
    | where RemoteUrl !has_any ("google.com", "googleapis.com", "gstatic.com") // baseline exclusions - extend with your banking app CDNs
    | summarize Connections = count(), Destinations = make_set(RemoteUrl, 10) by DeviceName, bin(Timestamp, 1h)
    ) on DeviceName, Timestamp
| project Timestamp, DeviceName, InstallEvents, Files, Connections, Destinations
| order by Timestamp desc

Velociraptor VQL

This artifact hunts managed endpoints for ADB usage and staged APK artifacts — the workstation-side footprint of a sideloading operation used to push a Hirudo-style trojanized banking app onto a device.

-- Hirudo hunt: ADB execution and staged APK artifacts on endpoints
SELECT Pid,
       Name,
       CommandLine,
       Exe,
       Username,
       CreateTime
FROM pslist()
WHERE Exe =~ '(?i)adb\.exe$'
   OR CommandLine =~ '(?i)(adb\s+(-s\s+\S+\s+)?install|pm\s+install)'

// Companion file hunt: run as a glob-based artifact to find staged APKs
SELECT FullPath,
       Size,
       Mtime,
       Ctime
FROM glob(globs=['C:/Users/*/Downloads/*.apk',
                 'C:/Users/*/Desktop/*.apk',
                 '/home/*/Downloads/*.apk'])
WHERE Mtime > now() - 1209600  -- last 14 days
ORDER BY Mtime DESC

Audit & Hardening Script

Run this against a managed/test Android device (with USB debugging authorized) to audit for the Hirudo-style indicators: sideloaded packages, non-Play installer sources, and banking apps not signed by their expected certificates.

#!/bin/bash
# hirudo-device-audit.sh - Audit Android device for sideloaded/replaced banking apps
# Requires: adb, device with USB debugging authorized
set -euo pipefail

echo "=== Hirudo-style App Replacement Audit ==="
date -u

echo ""
echo "[*] Checking ADB connectivity..."
adb get-state >/dev/null 2>&1 || { echo "[!] Device not reachable via ADB"; exit 1; }

echo ""
echo "[*] Sideloading setting status (0 = disabled, 1 = enabled):"
adb shell settings get secure install_non_market_apps 2>/dev/null || echo "    (setting not present on this Android version)"

echo ""
echo "[*] Third-party packages and their installer of record:"
for pkg in $(adb shell pm list packages -3 | tr -d '\r' | sed 's/package://'); do
  installer=$(adb shell pm get-installer-package-name "$pkg" 2>/dev/null | tr -d '\r')
  if [ "$installer" != "com.android.vending" ] && [ -n "$installer" ]; then
    echo "    [!] NON-PLAY INSTALLER: $pkg  <-  $installer"
  elif [ -z "$installer" ]; then
    echo "    [!] NO INSTALLER RECORD (possible ADB/manual install): $pkg"
  fi
done

echo ""
echo "[*] Signing certificate digests for installed banking-like packages:"
for pkg in $(adb shell pm list packages -3 | tr -d '\r' | sed 's/package://' | grep -Ei 'bank|pay|wallet|finanz|credit|banca|sparkasse'); do
  cert=$(adb shell dumpsys package "$pkg" 2>/dev/null | grep -A1 'signatures' | head -2 | tr -d '\r' | tr -d ' ')
  echo "    $pkg : $cert"
  echo "        -> Compare against the bank's known-good signing cert from a clean Play Store install."
done

echo ""
echo "[*] Enabled accessibility services (review for unknown packages):"
adb shell settings get secure enabled_accessibility_services | tr -d '\r'

echo ""
echo "[*] Play Protect status:"
adb shell settings get global package_verifier_enable 2>/dev/null | tr -d '\r' || true

echo ""
echo "=== Audit complete. Investigate any NON-PLAY INSTALLER or signature mismatch on banking packages. ==="

Remediation

If a device is confirmed or suspected to be running a replaced banking app:

1. Isolate the device immediately. Remove it from Wi-Fi and mobile data (airplane mode) to cut exfiltration and attacker C2.
2. Reset banking credentials from a known-clean device. Assume credentials entered in the trojanized app are compromised. Change passwords, revoke sessions, and rotate any MFA seed or soft-token provisioned on the device. Contact the bank's fraud line to flag the account and review transactions for the exposure window.
3. Do not "just uninstall." The malicious APK may have dropped secondary payloads or enabled persistence-capable permissions (accessibility services, device admin). For personal devices, a factory reset is the safest path. For enterprise-managed devices, use your EMM to execute a selective or full wipe and re-enroll.
4. Forensic preservation first, where warranted. If the device belongs to an executive, finance staff, or a regulated-data environment, capture an ADB-level acquisition (installed package list with installer sources and signatures, enabled accessibility services, device admin list) before wiping.

Organization-wide hardening to prevent recurrence:

• Block sideloading via policy. On managed Android (Android Enterprise / Intune / Workspace ONE), disable install from unknown sources at the work-profile and device level. This single control breaks Hirudo's delivery model.
• Enforce Google Play Protect and keep it enabled — verify via EMM compliance policies, not assumption.
• Deploy a mobile threat defense (MTD) solution that validates app signing certificates and installer provenance. A replaced banking app is trivially detectable by signature mismatch — but only if something is checking.
• Move verification out of the app. Since in-app anti-tamper controls can be stripped by repackaging, rely on server-side signals: device attestation (Play Integrity API verdicts evaluated server-side), impossible-travel, new-device fingerprinting, and step-up authentication on credential changes or transaction anomalies.
• User awareness targeted at the lure. Train users that banks never distribute app updates via links in SMS, email, QR codes, or ads — updates come only from Google Play. Hirudo's entire model depends on a user accepting an APK from an untrusted channel.
• Monitor for the hunt content above. Deploy the Sigma, KQL, and VQL detections to catch ADB-based sideloading and staged APKs on managed endpoints, especially for finance and treasury staff whose mobile banking access is highest-value.

If you find a confirmed infection in your environment, treat it as a financial-fraud incident, not just a malware event: engage your IR retainer, notify affected financial institutions, and preserve evidence for potential law-enforcement referral.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub