TL;DR: 34 malware families are targeting 1,243 mobile banking and fintech apps across 90 countries, with 21 families focused on 68 core banking and fintech apps across 12 LATAM countries, according to Zimperium; attackers are using AI across localisation, exploit scripting, and phishing overlays. The threat now sits at the device layer, where fake screens, accessibility abuse, OTP interception, and device takeover undermine mobile trust assumptions.
At a glance
What this is: Zimperium reports a mobile banking malware wave in LATAM that uses accessibility abuse, overlays, OTP interception, and device takeover to steal credentials and push fraudulent transfers.
Why it matters: This matters because mobile banking security now depends on protecting the transaction path and device trust signals, not just authenticating the user and hardening the app.
Context
Mobile banking malware exploits the gap between user authentication and transaction execution. Once an attacker can manipulate the device, the banking app can still appear legitimate while the victim is being watched, redirected, or impersonated in real time. The article's core warning is that mobile trust assumptions are being broken at the endpoint, not only in the cloud or backend.
For identity and access teams, this is a fraud and identity assurance problem as much as an application security problem. Credential theft, OTP interception, and session manipulation undermine the controls many banks rely on for consumer authentication, step-up checks, and transaction approval. In LATAM, the article shows that local payment rails and banking habits are being weaponised alongside the malware techniques themselves.
Key questions
Q: What breaks when mobile banking apps do not use app shielding and secure session controls?
A: Without app shielding and proper session controls, fraudsters can reverse-engineer apps, create convincing fake apps, steal data from the app itself, or exploit open sessions. That creates a wider attack surface even when the login appears legitimate. Security teams should assume the mobile app, not just the account, is a target.
Q: Why do evolving mobile malware campaigns increase account takeover risk?
A: They increase risk because the same device can remain usable to the user while malware quietly captures credentials, OTP codes, or transaction data. When device compromise and user identity stay linked in the same session, fraud controls need to decide whether to trust the device, the account, or neither. That is why timing and context matter as much as detection.
Q: What signs indicate that a mobile banking session is being abused?
A: Common indicators include accessibility-service misuse, unexpected overlays, root or jailbreak signals, emulator use, suspicious screen-sharing activity, and OTP flows that do not match normal customer behaviour. These signs matter because they show the device itself may be acting as the attack platform rather than a trustworthy endpoint.
Q: How should banks balance step-up authentication with device trust checks?
A: They should treat step-up as necessary but not sufficient. High-risk mobile transactions need both user verification and device integrity signals, because an attacker controlling the handset can intercept or replay approval steps. The right governance model ties approval to the transaction context and the trustworthiness of the device and session.
Technical breakdown
Why accessibility abuse is the primary mobile fraud enabler
Android accessibility services were designed to support users, but malware can misuse them to read screen content, capture keystrokes, click controls, and observe app state. That creates a powerful bridge from initial device compromise to transaction manipulation without needing traditional code injection. Because the activity can look like legitimate user interaction, app-level authentication alone does not reliably distinguish the attacker from the customer. In this model, the device becomes the control plane for fraud, and the banking app is reduced to a target surface rather than a trust anchor.
Practical implication: banks need runtime signals that detect accessibility abuse, overlay use, and device control during active sessions.
How overlays and OTP interception defeat step-up authentication
Screen overlays place a fake interface over the real banking app, which lets malware capture credentials, card details, and transaction data while the victim believes they are entering information into the genuine app. If the malware also intercepts SMS or push notifications, one-time passcodes can be captured or redirected before they complete their protective function. This breaks the assumption that possession of a second factor proves the real user is present. For fraud teams, the control failure is not authentication itself, but the integrity of the interaction path that carries the authentication challenge.
Practical implication: transaction authentication must be coupled with overlay detection and OTP channel hardening.
Why device takeover changes the fraud model
Device takeover gives attackers live control of the handset, including real-time screen viewing and remote input. That allows them to time transfers, bypass friction points, and imitate human behaviour closely enough to evade many behavioural checks. When malware can operate as the user inside the device, conventional trust models that assume the endpoint reflects a human intent signal stop working. The article's examples, including ATS fraud and remote control variants, show that the decisive issue is not only stolen credentials but stolen session authority.
Practical implication: banks should treat high-risk mobile sessions as untrusted until device integrity and interaction provenance are verified.
Threat narrative
Attacker objective: The attacker wants to capture mobile banking credentials, control the session, and move money through unauthorized transfers without detection.
- Entry begins on the mobile device when victims are lured into installing or interacting with malware that abuses trusted Android capabilities or deceptive overlays.
- Credential access follows through screen capture, keystroke logging, OTP interception, and remote observation of banking activity.
- Escalation occurs when the malware takes over the session or device and initiates unauthorized transfers through ATS or remote control.
- Impact is fraudulent movement of funds and broader erosion of trust in mobile banking sessions and payment rails.
Breaches seen in the wild
- CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Mobile fraud has shifted from credential theft to interaction control. The article shows that the decisive compromise is no longer only the secret or the password, but the device interaction layer that carries authentication and transaction approval. When malware can read the screen, intercept OTPs, and manipulate overlays, banking trust depends on runtime device integrity rather than login success alone.
AI-assisted malware development is compressing the defender's response window. The article's account of AI being used for localisation, exploit scripting, and phishing-page construction means mobile fraud campaigns can adapt faster than signature-based controls can catch up. That shifts the governance problem from static detection to continuous behaviour-based assurance across sessions and devices.
Session authority is becoming the real asset under attack. In mobile banking, an authenticated user is not sufficient if the session can be hijacked, mirrored, or remote-controlled from the same handset. This is why mobile fraud now sits at the intersection of identity verification, application security, and transaction risk, and practitioners need to govern the whole interaction chain, not just the login event.
Local payment rails create localised fraud patterns, not just localised malware. The article's LATAM examples show that attackers are tailoring malware to regional banking habits and payment systems such as Pix. That means fraud governance must account for regional transaction behaviour, device posture, and app abuse techniques together, or controls will lag behind the attacker model.
Overlay-resistant and device-integrity-aware controls are now a fraud governance baseline. Mobile banking programmes should treat runtime attestation, accessibility abuse detection, and transaction-step verification as core control expectations, not advanced extras. The practitioners who govern mobile identity well will focus on the trustworthiness of the device and the session, not only the strength of the initial login.
From our research library:
- U.S. fraud losses are projected to reach $40 billion by 2027.
What this signals
Mobile fraud governance now has to start at the endpoint. Banks should assume that a compromised handset can make a legitimate banking app behave fraudulently even when the user appears authenticated. That shifts programme ownership toward device integrity, transaction provenance, and runtime telemetry rather than relying on the login journey alone.
Interaction integrity is the named risk that matters here. The article shows that the attacker wins by controlling what the user sees, what the app receives, and which approval event actually reaches the bank. Practitioners should treat overlay resistance, accessibility monitoring, and session assurance as linked controls, not separate workstreams.
For practitioners
- Harden the mobile app against tampering Build resistance to reverse engineering, hooking, and instrumentation so attackers cannot easily study or alter the banking app before deploying fraud tooling.
- Detect runtime abuse on the device Instrument the app to flag rooting, jailbreak, debuggers, emulators, accessibility abuse, and Frida-style hooking during active sessions.
- Treat overlays as transaction-risk signals Block or step up when the app detects overlay patterns, fake screens, or UI interactions that do not match expected user navigation.
- Harden OTP and notification channels Reduce reliance on SMS or push-based one-time passcodes for high-risk actions and add transaction binding where the approval is tied to the specific payment.
- Move from signature-only malware controls Use behaviour-based mobile malware protection that can recognise new variants rather than waiting for known signatures to appear.
Key takeaways
- Mobile banking fraud now exploits the device interaction layer, not just stolen credentials or weak passwords.
- The article shows a large and regionally concentrated malware problem, with AI being used to speed localisation, exploitation, and deception.
- Banks that do not monitor runtime device integrity, overlays, and OTP manipulation will keep mistaking compromised sessions for valid customer activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The malware steals credentials, OTPs, and session data from mobile banking flows. |
| NHI-04 — Insecure Authentication | OTP interception and session manipulation undermine authentication assurance in the article. | |
| Recommendation — Scan mobile flows for exposed credentials and treat any captured OTP or token as compromised. Bind mobile authentication to device integrity and reject approvals from untrusted sessions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Fraud succeeds when the attacker defeats the authentication path during mobile sessions. |
| Recommendation — Strengthen authentication checkpoints for high-risk mobile transactions and detect replay or interception. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on OTP capture, notification abuse, and credential handling. |
| Recommendation — Manage authenticators so mobile approvals cannot be reused, intercepted, or silently redirected. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Malware abuses device and app permissions to extend fraudulent access during sessions. |
| Recommendation — Review mobile permissions and session authorisations to limit what a compromised app can do. | ||
Key terms
- Accessibility Service Abuse: A misuse pattern where an Android app leverages Accessibility permissions to read the screen, simulate taps, and automate user actions. In practice, it turns a legitimate assistive feature into a control surface for fraud, credential theft, and permission abuse inside the active session.
- Screen Overlay Attack: A screen overlay attack uses a fake interface layered over a legitimate mobile app to capture credentials or other sensitive input. It is often aimed at banking and payment applications, where users expect to enter high-value information. The deception works because the fake screen closely matches the real app experience.
- Automated Transfer System: An Automated Transfer System is malware logic that initiates and completes fraudulent payments without manual attacker interaction. It turns a compromised device into a transaction engine, allowing the attacker to move funds while the user sees normal app behaviour or is distracted by a convincing prompt.
- Device Takeover: A fraud pattern in which the attacker uses a compromised or trusted device to inherit reputation and bypass normal risk checks. Because the device appears familiar, merchants may trust the session even though the real user no longer controls the endpoint or associated authentication factors.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build stronger controls around access, lifecycle, and trust boundaries.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org