New Android malware uses AI to steal bank logins and PINs

1. Executive summary

Zimperium's zLabs has documented an Android banking Trojan, RatHat, that hands a live AI assistant control of the infected device's accessibility tree and lets it decide where to tap or scroll instead of following a hardcoded script. The variable attack path is designed to defeat signature- and rule-based mobile security tooling. RatHat distributes itself through smishing and malvertising, abuses the Accessibility Service, then self-pairs via Wireless Debugging to obtain a shell-level ADB session, drops a Go-based privileged agent and a reverse-proxy client, and steals banking credentials, OTP/MFA codes, and device PINs and unlock patterns by recording raw touch coordinates from the input driver. EMEA financial services clients should treat this as a direct threat to retail and corporate mobile banking customers: credential and OTP theft on an infected device defeats SMS-based and app-based second factors, and the reverse-proxy tunnel gives the attacker a persistent channel that survives normal network controls. No verified reference data was resolved for this item, so no CVE, CVSS, or CISA-KEV state applies; the analysis below rests on the Zimperium research as reported by Malwarebytes, which is a single source.

2. Regulatory framing

No other article in the regulatory reference is engaged by a fact distinctive to this item. The compromise occurs on customer-owned devices outside the client's ICT perimeter, which limits the reach of Art. 24 testing and Art. 28 third-party provisions here.

3. Technical analysis & attack chain

Confirmed steps, as described by Zimperium zLabs and reported by Malwarebytes:

1. Initial access via smishing (SMS phishing) texts and malicious advertisements that lead victims to fake download pages. The pages are sometimes disguised as a popular streaming app or as a browser such as Chrome, and trick the user into sideloading a malicious APK.
2. On installation, the app pressures the user into enabling Android's Accessibility Service, using a fabricated "network restriction" excuse or a bogus financial incentive.
3. With accessibility access, the Trojan silently navigates Developer Options, enables Wireless Debugging, and reads the six-digit pairing code directly from the screen. It then completes the pairing itself, with no person or computer involved. Wireless Debugging is a legitimate Android feature for developers testing over Wi-Fi; RatHat repurposes it for self-escalation.
4. Self-pairing yields a shell-level ADB session, which the malware uses to escape the normal app sandbox and drop two disguised native binaries: a Go-based "agent" that executes system commands with elevated privileges, and a reverse-proxy client that opens a persistent tunnel back to the attacker's server, traversing firewalls and NAT.
5. Credential theft via overlays displayed over targeted apps, most of which are financial. The overlays also capture one-time passwords and MFA codes.
6. PIN and pattern recovery: the Trojan records raw touch coordinates directly from the input driver and matches them against a database of known keypad and pattern-lock layouts to reconstruct PIN codes and unlock patterns. This bypasses protections against screen-reading, because the malware never reads the screen to obtain the secret.
7. Additional capabilities: SMS interception, semi-autonomous device control driven by the AI service, and restoration of the malicious app after uninstall via a hidden background program.

The AI element is the distinguishing capability. Rather than scripting tap sequences per target app, RatHat gives a live AI assistant access to the device's accessibility tree and the assistant determines where to tap or scroll at runtime. Zimperium assesses that this variable attack path makes the Trojan harder for signature- and rule-based mobile security tools to detect, since there is no fixed automation script to fingerprint.

Persistence is two-layered: the reverse-proxy client maintains the outbound tunnel, and the hidden background program reinstalls the malicious app if a user removes it. Malwarebytes states that the persistence mechanism survives normal app removal and that a factory reset is required to clean an infected device.

Confidence caveat: every technical claim above is single-sourced, resting on Zimperium zLabs research as reported by Malwarebytes on 2026-09-18. No second vendor has corroborated the AI-driven accessibility abuse, the ADB self-pairing technique, or the touch-coordinate PIN recovery at the time of writing. No hashes, package names, C2 domains, or target-app list are published in the source material, so the specific binaries and infrastructure cannot be pivoted on yet. Verify before enforcement.

4. Mitigation & containment

P1, within 24 hours:

• Alert fraud and SOC teams on the behavioural pattern rather than signatures: a sideloaded app requesting Accessibility Service, followed by Wireless Debugging being enabled and a six-digit pairing code being read on-screen. Instruct mobile device management (MDM) teams to confirm that Developer Options and Wireless Debugging are disabled and blocked by policy on all corporate-enrolled Android devices.
• Review recent mobile-banking fraud cases for the compromise chain in §3: credential entry followed by OTP capture, or transactions authorised from a device that also shows SMS interception. Where a case matches, treat the enrolled device as compromised and revoke its sessions and trusted-device status.
• Add the detection name Android/Trojan.Exploit.RatHat (Malwarebytes) to threat-intelligence watchlists so vendor feeds triage it correctly when samples arrive.

P2, within 72 hours:

• Block sideloading on managed Android fleets: enforce Google Play as the only install source via MDM, and enable Android's Advanced Protection Mode where the device population supports it, since Google uses it to restrict which apps can request accessibility permissions.
• Audit accessibility-service grants across managed devices and revoke any granted by non-accessibility apps. Any app requesting Accessibility Service for a stated reason unrelated to accessibility should be treated as suspect.
• Brief customer-facing fraud teams: the social-engineering pretexts observed are a fake "network restriction" message and a bogus financial incentive, delivered by smishing or malvertising, with the payload disguised as a streaming app or Chrome. Update smishing guidance and in-app warnings accordingly.

P3, within 7 days:

• Advise customers, through existing fraud-prevention channels, to install apps only from Google Play or another trusted official store, and never to enable Developer Options or Wireless Debugging at an app's request.
• Update incident response runbooks to state that a RatHat-infected device requires a factory reset, because the persistence mechanism survives normal app removal. Trusted-device re-enrolment after a reset should require re-verification, not automatic restoration.
• Review whether current mobile threat defence tooling on the estate is signature- and rule-based; the AI-driven variable attack path is specifically designed to evade that class of tooling, so confirm coverage includes behavioural detection of accessibility abuse and ADB activation.

5. Indicators of compromise

No indicators of compromise available in the source material. The source publishes no hashes, package names, domains, IPs, or URLs for RatHat.

Behavioural indicators:

6. Detection

Insufficient indicators to author detection rules. The source material contains no file hashes, package names, distinctive strings, mutexes, registry keys, C2 addresses, or command-line artefacts for RatHat. The detection name Android/Trojan.Exploit.RatHat is a Malwarebytes product label, not a threat artefact, and cannot anchor a YARA or Sigma rule. The behavioural indicators in §5 should be implemented as MDM and fraud-analytics logic until Zimperium publishes technical IOCs.

7. Sources

• Malwarebytes, "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, 2026-09-18
• Malwarebytes Labs, "Rokarolla Android malware can take over your phone and steal banking logins", https://www.malwarebytes.com/blog/mobile/2026/06/rokarolla-android-malware-can-take-over-your-phone-and-steal-banking-logins, 2026-06 (context on the Android banking-Trojan class; not a RatHat source)
• Help Net Security, "New Android malware relays bank cards to fraudsters while victims still hold them", https://www.helpnetsecurity.com/2026/08/14/windrelay-android-nfc-relay-malware/, 2026-08-14 (context on the Android banking-Trojan class; not a RatHat source)

8. Adverse Trace position

We assess RatHat as a high-impact threat to EMEA financial services customers despite the single-source basis, because the documented capability set defeats the two controls most banks rely on for mobile authentication: app-side second factors, via overlay and SMS interception, and device trust, via PIN and pattern recovery from raw touch coordinates. The AI-driven accessibility abuse lowers the marginal cost of targeting new banking apps, since the operator no longer needs a hardcoded overlay or automation script per target, and it degrades signature-based mobile defences at the same time. We treat the attribution as unconfirmed: no actor is named in the source material and no MITRE profile exists in the verified reference data, which resolved nothing for this item. All technical detail is single-sourced to Zimperium zLabs as reported by Malwarebytes, so clients should verify against Zimperium's primary publication before enforcing blocks or policy changes. We will update this advisory when Zimperium publishes the technical IOCs, the target-app list, or sample hashes, and we will re-issue at if a second vendor corroborates the AI-driven attack path.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.