Novel Android RAT ‘Hirudo’ Replaces Banking Apps With Trojanized Copies

1. Executive summary

SecurityWeek reported on 2026-10-15 that a new Android banking trojan and remote access trojan, tracked as Hirudo, replaces installed banking apps with trojanized copies. The primary item is a headline and a one-line description; no technical detail, no indicators, no attribution and no CVE data were supplied with it. The only substantive technical material available is a September 2026 Malwarebytes Labs write-up of a separate Android trojan, RatHat, analysed by Zimperium zLabs, which describes an AI-assisted accessibility-abuse chain that is the closest documented analogue to what Hirudo is described as doing. No verified reference data resolved for this item, so no CVSS score, severity rating or CISA KEV state can be stated, and none is asserted here. The bottom-line risk to EMEA financial services is that customer-side Android banking fraud of this class defeats app-layer authentication (overlays capture OTP and MFA codes) and reconstructs PINs and unlock patterns from raw touch input, which means device-side compromise can survive the controls banks currently rely on.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

The item is a vendor and press description of a malware family affecting retail customer devices. It reports no incident at a named financial entity, no third-party ICT provider failure, and no supply chain event, so the DORA incident-management, classification, reporting, testing and third-party articles and the NIS2 supply chain and reporting articles have no trigger fact here. The RatHat material describes a malware capability, not an event at a regulated entity. If a client's own mobile estate is later confirmed compromised, DORA Art. 17 (ICT-related incident management process), DORA Art. 18 (classification of ICT-related incidents and cyber threats) and DORA Art. 19 (reporting of major ICT-related incidents to competent authorities) become engaged at that point, and NIS2 Art. 23 (incident reporting obligations) and UK NIS 2018 OES/RDSP duties apply to in-scope entities on the same condition. None of those conditions is met by this item as supplied.

3. Technical analysis & attack chain

The primary item does not contain an attack chain. It states that Hirudo combines elements of a traditional banking trojan and a full-featured RAT and that it replaces banking apps with trojanized copies. No initial access vector, no package names, no C2 infrastructure, no persistence mechanism and no attribution are given. Everything below is the RatHat chain from the Malwarebytes Labs write-up, which is a different family and is presented as the documented analogue, not as Hirudo itself.

Confirmed steps in the RatHat chain, per Malwarebytes Labs citing Zimperium zLabs:

1. Victims are lured by smishing SMS and malicious ads to fake download pages, sometimes disguised as a streaming app or as Chrome, and are persuaded to sideload a malicious APK.
2. After install, the app pressures the user into enabling Android's Accessibility Service, using a fake "network restriction" excuse or a bogus financial incentive.
3. With accessibility access, the malware silently navigates Developer Options, enables Wireless Debugging, and reads the six-digit ADB pairing code off the screen.
4. It pairs with the infected device itself, with no human or second computer involved, obtaining a shell-level ADB session.
5. Over that ADB session it drops two disguised native binaries: a Go-based agent that runs system commands with elevated privileges, and a reverse-proxy client that opens a persistent tunnel to the attacker's server, bypassing firewalls and NAT.
6. It creates overlays for targeted apps, most of them financial, to capture login credentials, one-time passwords and MFA codes.
7. It records raw touch coordinates from the input driver and matches them against a database of known keypad and pattern-lock layouts to reconstruct PINs and unlock patterns, which bypasses protections against screen-reading.
8. Additional capabilities: SMS interception, semi-autonomous device control driven by a live AI assistant reading the accessibility tree to decide where to tap or scroll rather than following a hardcoded script, and restoration of the malicious app after uninstall via a hidden background program.

The AI-driven control path is what makes the chain variable: because the tap and scroll decisions are made at run time against the live accessibility tree, signature- and rule-based mobile detection is weaker against it than against a fixed script. The ADB self-pairing step is the privilege boundary crossed. Wireless Debugging is a legitimate developer feature and the malware uses it exactly as designed, so there is no vulnerability being exploited in the Android platform in this chain.

Confidence caveats. The RatHat chain is single-sourced to Malwarebytes Labs reporting Zimperium zLabs analysis; verify before enforcement. The link between RatHat and Hirudo is not established by any source provided. The primary item names Hirudo and describes app replacement; the related source names RatHat and describes overlay and touch-coordinate theft. Treating them as the same tool, the same operator, or the same campaign would be an assumption. No actor is named in any source, so there is no attribution to assess and none is offered.

4. Mitigation & containment

P1 within 24h

• If Hirudo or RatHat is suspected on a corporate-managed Android device, remove the device from the corporate estate rather than attempting app-level cleanup. The RatHat persistence mechanism survives normal app removal and Malwarebytes states a factory reset is required; treat uninstall as insufficient.
• Block sideloading on managed Android fleets through MDM policy, and alert on any device where Developer Options or Wireless Debugging is enabled. These are the two settings the chain depends on and neither has a legitimate place on a managed banking device.
• Restrict which apps can hold Accessibility Service permission via MDM and, where the OS version supports it, Android Advanced Protection Mode, which Google has begun using to limit which apps may request accessibility permissions at all.

P2 within 72h

• Add detection for ADB pairing activity originating on-device rather than from a tethered host. A device that pairs with itself over Wireless Debugging is the anomaly; there is no legitimate retail banking use case for it.
• Review customer-facing authentication for overlay and OTP-interception exposure. Overlays capture OTP and MFA codes at the point of entry, so controls that assume the customer's screen and input are trustworthy do not hold on a compromised device. Transaction signing bound to hardware keys, and out-of-band confirmation on a separate channel, are the controls that survive this class of compromise.
• Brief fraud and contact-centre teams that a customer reporting a PIN or pattern compromise may have a clean-looking device. The touch-coordinate capture reconstructs the PIN from raw input, so there is no screen-recording artefact to point to.

P3 within 7 days

• Push customer guidance that mirrors the source's own advice: install only from Google Play or another trusted official store, treat any app requesting Accessibility Service for non-accessibility reasons as hostile, and never enable Developer Options or Wireless Debugging on a personal banking device.
• Confirm mobile anti-malware coverage on managed devices. Malwarebytes detects RatHat as Android/Trojan.Exploit.RatHat; coverage against Hirudo is not stated by any source and should not be assumed from that detection name.

No vendor fix, patch version or CVE is named in any source for either family. There is nothing to version-pin here; the controls above are configuration and process controls.

5. Indicators of compromise

No atomic indicators of compromise are available in the source material. No hashes, domains, IP addresses, package names, file paths or registry keys are given for Hirudo or RatHat in any source provided.

The sources do describe observable behaviours. Those are listed separately below and are not machine-pivotable atomic indicators.

Behavioural indicators

6. Detection

The sources give usable artefacts for a Sigma rule on the behavioural side: the Accessibility Service grant, the Developer Options and Wireless Debugging enablement, and the on-device ADB pairing. They give no file-level artefacts, no strings, no mutexes, no filenames and no registry keys, so a YARA rule cannot be built from this material without inventing content. No YARA rule is emitted.

title: Android Wireless Debugging Enabled and Device Self-Paired Without Tethered Host
id: 7f3c1a92-4b6e-4d21-9c8a-2e5b0d7a1f44
status: experimental
description: >
  Detects the ADB self-escalation step described by Malwarebytes Labs and Zimperium zLabs,
  in which an app with Accessibility Service access enables Developer Options and Wireless
  Debugging and reads the pairing code from the screen to pair the device to itself. Built
  from the RatHat chain; applicability to Hirudo is unconfirmed.
author: Adverse Trace
date: 2026-10-15
references:

  - https://www.malwarebytes.com/blog/news/2026/09/new-android-malware-uses-ai-to-steal-bank-logins-and-pins
  - https://www.securityweek.com/novel-android-banking-rat-hirudo-replaces-banking-apps-with-trojanized-copies/
logsource:
  product: android
  service: mdm
detection:
  selection_debugging:
    event_type:

      - 'developer_options_enabled'
      - 'wireless_debugging_enabled'
  selection_pairing:
    event_type:

      - 'adb_pairing_request'
      - 'adb_authorization_granted'
    pairing_origin: 'on_device'
  selection_accessibility:
    event_type: 'accessibility_service_enabled'
    requesting_app_category: 'non_accessibility'
  condition: selection_debugging or selection_pairing or selection_accessibility
falsepositives:

  - Developer or QA devices where Developer Options and Wireless Debugging are legitimately enabled
  - Accessibility apps installed by users who require them, where the app category is misclassified
level: high

Field names in the rule above are placeholders for whatever schema the client's MDM or EMM exports. Map them to the local telemetry before deployment. The detection logic, not the field names, is the deliverable.

7. Sources

• SecurityWeek, "Novel Android RAT 'Hirudo' Replaces Banking Apps With Trojanized Copies", https://www.securityweek.com/novel-android-banking-rat-hirudo-replaces-banking-apps-with-trojanized-copies/, 2026-10-15.
• Malwarebytes Labs, "New Android malware uses AI to steal bank logins and PINs", https://www.malwarebytes.com/blog/news/2026/09/new-android-malware-uses-ai-to-steal-bank-logins-and-pins, September 2026. Reporting Zimperium zLabs analysis of RatHat.

8. Adverse Trace position

Adverse Trace assesses this item as low confidence on Hirudo specifically and moderate concern on the technique class it belongs to. The primary item is a headline with no technical substance, no indicators and no attribution, and no verified reference data resolved for it, so we are not assigning a CVSS score, a severity rating or a KEV state, and we are not naming an actor. The RatHat chain in the related source is single-sourced to Malwarebytes Labs reporting Zimperium zLabs, and we treat it as unverified until a second source corroborates it; the overlap between RatHat and Hirudo is our inference from capability similarity, not a sourced fact, and clients should not treat the two as confirmed to be the same tool. The client impact that matters is on the customer side: overlays that capture OTP and MFA codes and touch-coordinate capture that reconstructs PINs and patterns defeat the app-layer authentication most retail banking stacks depend on, and the persistence mechanism survives uninstall, so a factory reset is the only reliable cleanup. We will monitor for a technical report on Hirudo with package names, C2 infrastructure or hashes, and we will reissue this advisory with atomic indicators and a detection rule set if that material appears. Clients running managed Android fleets should action the P1 items in §4 now rather than waiting for that report, because the configuration controls (block sideloading, alert on Developer Options and Wireless Debugging, restrict Accessibility Service grants) are correct against this technique class regardless of which family is in play.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.