Android overlay attacks expose a mobile banking UI integrity gap

At a glance

What this is: This is an analysis of Android overlay attacks against mobile banking apps, showing how malicious UI layers can capture credentials, mask warnings, and manipulate transactions.

Why it matters: It matters to IAM and fraud practitioners because the attack targets user authentication and approval flows, turning mobile identity assurance into a UI integrity and transaction-authorisation problem.

By the numbers:

• 17 minutes and as quickly as 9 minutes

👉 Read OneSpan's analysis of how Android overlay attacks target mobile banking apps

Context

Android overlay attacks exploit a gap in UI integrity, not a weakness in password policy alone. A malicious app can place a fake or transparent layer over a banking app, capture credentials, and redirect taps while the underlying application believes the user is interacting normally. For IAM teams, the lesson is that mobile authentication and transaction approval are only as trustworthy as the interaction layer that presents them.

The article is especially relevant to fraud, mobile security, and digital identity governance because it shows how trusted user actions can be rewritten at runtime. Where mobile banking relies on PIN entry, visible confirmation screens, or soft approvals, overlay abuse creates a boundary problem between identity verification and transaction authorisation that many control models still treat separately.

Key questions

Q: What breaks when Android overlay protection is not in place?

A: When overlay protection is weak, users can be tricked into entering credentials into a fake interface or approving actions they never truly saw. The failure is not only credential theft. It is the loss of UI integrity, which allows malicious software to intercept trust at the moment of login or transaction approval.

Q: Why do mobile banking apps need overlay controls beyond passwords and biometrics?

A: Passwords and biometrics confirm the user, but they do not guarantee that the screen the user saw was genuine. Overlay controls matter because attackers exploit the interaction layer to capture input or redirect taps. Without UI protection, strong authentication can still be wrapped in a fraudulent approval path.

Q: How do security teams know if overlay defences are actually working?

A: They should test whether protected flows block rendering on supported OS versions, whether obscured touches are rejected on older devices, and whether accessibility abuse is detected during runtime. If the app only logs overlay attempts but still completes the action, the defence is cosmetic, not effective.

Q: Who is accountable when a compromised mobile device completes a fraudulent transaction?

A: Accountability usually spans fraud operations, IAM, mobile security, and the business owner of the transaction flow. If the programme treats device integrity as outside identity governance, the control gap is structural. Teams should define ownership for post-authentication session trust before fraud patterns force the issue.

Technical breakdown

How Android overlay attacks steal credentials and approvals

Overlay attacks work by placing a malicious view over a legitimate app, often after the user grants SYSTEM_ALERT_WINDOW or through Accessibility abuse. In full overlays, the victim sees a convincing fake login and types credentials into the malware. In partial overlays, the attacker masks a field, a warning, or a confirmation button. Tapjacking extends the technique by allowing touches to pass through a transparent layer so the hidden action is executed in the target app. The core weakness is that the app and the operating system may still accept the touch as valid even when the user interface is being visually manipulated.

Practical implication: treat UI integrity as a control surface and block credential capture at the interaction layer, not only at authentication.

Why legacy touch filtering fails against overlay abuse

On Android 11 and below, apps cannot stop overlays from rendering. They can only inspect touch metadata for obscured-window flags such as FLAG_WINDOW_IS_OBSCURED and FLAG_WINDOW_IS_PARTIALLY_OBSCURED, or enable filterTouchesWhenObscured. That helps only when the touch event reaches the app. If malware blocks the touch entirely, or if Accessibility is used to inject or observe interactions, the defensive callback never fires. This is why legacy protection is partial rather than preventive. It reduces some tapjacking cases but does not remove the underlying rendering risk.

Practical implication: do not rely on obscured-touch flags alone, because they fail wherever the malicious layer intercepts or reroutes input first.

How Android 12 changes overlay prevention for sensitive banking flows

Android 12 introduced Window.setHideOverlayWindows(true), which tells the system WindowManager to suppress non-system overlays while the protected window is active. That changes the model from detection to prevention by stopping rogue overlays from rendering over sensitive activities such as login or transfer approval. The control is still environment-dependent, because older devices remain in circulation and Accessibility abuse can still extend beyond simple overlay rendering. Effective defence therefore depends on aligning the app's protection logic with the device's OS version and privilege model.

Practical implication: enforce overlay blocking on API 31+ and keep compensating controls for older Android versions and privileged accessibility paths.

Threat narrative

Attacker objective: The attacker wants to steal banking credentials and use them to authorise fraudulent transactions without the victim noticing.

1. Entry occurs when the attacker places malicious mobile software on the device or persuades the user to grant overlay or accessibility permissions. The malware then waits until a banking app enters the foreground.
2. Credential access happens when the rogue window captures PINs, passwords, or confirmation data, or when tapjacking forces a transaction approval through a hidden button.
3. Impact follows when the attacker reuses harvested credentials on another device or executes an unauthorised transaction from the victim's device.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

UI integrity is now part of identity assurance. Mobile banking teams often treat authentication as a credential problem, but overlay attacks show that the presentation layer can be just as critical as the secret itself. If a user can be tricked into typing into an attacker-controlled surface, the identity event is already compromised before the backend sees it. Practitioners should treat the mobile interface as an enforcement point, not a cosmetic layer.

Android overlay abuse creates a distinct form of transaction fraud governance debt. The attack does not only harvest credentials, it alters what the user believes they approved. That means fraud controls, mobile app security, and identity assurance need shared ownership of approval flows. Security teams should re-evaluate where transaction confirmation, device trust, and step-up authentication intersect, because isolated controls leave the workflow open to visual substitution.

Overlay prevention is a layered control problem, not a single API call. Android 12's system-level blocking improves prevention, but legacy devices, accessibility abuse, and device compromise still weaken the boundary. This is why mobile risk management must combine OS-level protection, runtime monitoring, and device posture checks. The practical conclusion is that banks need policy-driven protection that matches device capability, not one uniform control assumption.

Accessibility privilege is an underappreciated identity-adjacent risk surface. The article shows that a highly privileged service can bypass the intent of overlay checks by reading or injecting UI state. That is a reminder that machine privilege inside a mobile environment can be as consequential as user credentials. Teams should scrutinise privileged services as part of access governance, because app-level permissions can become covert authentication bypasses.

Named concept: UI integrity gap. This is the failure mode where the application trusts an interaction that the user never genuinely saw or approved. It matters because security teams often validate authentication and authorisation outcomes without validating the presentation channel that produced them. Practitioners should close that gap by binding high-risk actions to trusted UI states and device-level overlay controls.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Forward-looking angle: The same governance gap now appears in mobile identity flows, where UI integrity and device trust determine whether authentication and approval events can be trusted at all, as reflected in 52 NHI Breaches Analysis.

What this signals

UI integrity is becoming a programme-level control concern, not just a mobile-app issue. Banks and regulated enterprises should expect more attacks that manipulate the interaction layer rather than the credential store itself. That makes mobile threat telemetry, device binding, and fraud signals part of the same operational picture. The practical shift is to treat approval flows as governed identity events, especially where account takeover and payment authorisation converge.

Named concept: the UI integrity gap. Teams should use this concept to describe the boundary between what the user thinks they approved and what the app actually executed. Once that gap is visible, it becomes easier to justify OS-version baselines, accessibility restrictions, and runtime blocking policies. For practitioners, the next step is to map that gap to Android 12 controls and compensating measures for older devices.

For practitioners

• Enforce overlay blocking on sensitive screens Call setHideOverlayWindows(true) on Android 12+ for login, payment, and transfer activities so non-system overlays cannot render over the app UI.
• Keep obscured-touch checks on legacy devices Retain filterTouchesWhenObscured and explicit MotionEvent flag checks for Android 11 and below, and block transactions whenever touches arrive through an obscured window.
• Audit privileged accessibility services Continuously review enabled Accessibility services and restrict app execution when untrusted or sideloaded services are active, because they can read or inject UI state.
• Bind approvals to device and session context Require device binding and step-up confirmation for high-risk actions so harvested credentials are less reusable across devices or replayed sessions.
• Add mobile threat intelligence to fraud monitoring Correlate overlay, trojan, and device-compromise indicators with authentication events so security teams can distinguish genuine login failures from UI-layer abuse.

Key takeaways

• Overlay attacks turn mobile banking into a UI integrity problem by letting malware capture credentials or redirect approvals through a fake or hidden layer.
• Legacy Android defences reduce some tapjacking but do not prevent overlay abuse, which is why Android 12's system-level blocking matters for sensitive flows.
• Practitioners should combine OS controls, accessibility monitoring, device binding, and mobile threat intelligence to keep authentication and transaction approval trustworthy.

Key terms

• Overlay Attack: An overlay attack is a mobile attack in which a malicious app draws a fake or transparent interface on top of a legitimate one. The user believes they are interacting with the real app, but input is captured or redirected by the attacker-controlled layer.
• Tapjacking: Tapjacking is a form of UI redirection where a user taps something visible, but the touch is delivered to a hidden element underneath. It often uses transparent overlays or deceptive prompts to trigger approvals, clicks, or authorisations without informed consent.
• UI Integrity: UI integrity is the assurance that what a user sees on screen is the same interface the application is actually using to capture input and execute actions. In mobile security, it is a trust property that sits between authentication, user intent, and transaction approval.
• Accessibility abuse: The misuse of built-in operating system accessibility features to observe the screen, capture input, overlay content, or automate app interaction. The feature is legitimate, but when an attacker controls it, the result is covert session manipulation that is difficult to distinguish from normal device behaviour.

What's in the full article

OneSpan's full article covers the operational detail this post intentionally leaves for the source:

• Java, XML, and Android API examples for detecting obscured touches and blocking overlays
• Step-by-step implementation guidance for Android 12 overlay prevention across sensitive activities
• Device-binding and accessibility monitoring recommendations for real mobile banking deployments
• Malware detection and app-shielding considerations for rooted, jailbroken, and emulated devices

👉 OneSpan's full article covers overlay types, Android API controls, and defence-in-depth recommendations

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security workflows that depend on them.