Android overlay attacks expose a mobile banking UI integrity gap

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OneSpan's blog post: Android overlay attacks let malicious apps draw over banking screens, stealing credentials or redirecting transaction approval through fake or obscured interfaces.

Why it matters: Mobile banking teams need to treat UI integrity as a fraud and identity control issue, because app-level authentication is weakened when users cannot reliably see what they are approving.

Context

Overlay attacks exploit a design gap in mobile operating systems: an app can appear to sit in the foreground while another app renders on top of it. In mobile banking, that turns a visual trick into a control problem, because the user may be typing credentials or approving a transfer into a malicious layer rather than the legitimate app.

The identity angle is real here. These attacks do not just hide malware behavior, they interfere with authentication and transaction approval paths that mobile banking relies on for assurance. Once an attacker can shape what the user sees and touches, fraud prevention becomes dependent on UI integrity as much as on credential strength.

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 overlay attacks on mobile devices create such a high fraud risk for identity and financial services?

A: Overlay attacks matter because they can capture credentials while looking like a legitimate login screen. Users believe they are entering passwords or one-time codes into a trusted app, while the malware relays the data to an attacker. That makes overlays especially dangerous for banking, identity verification, and any workflow that relies on user-entered secrets or biometric assurance.

Q: What are the signs that overlay defences are failing on Android devices?

A: Repeated blocked touches, unusual foreground app switching, unexpected accessibility service activity, and successful approval flows on older devices are strong warning signs. If the controls only work on some client versions, the estate is already fragmented enough for attackers to target the weakest path.

Q: How should mobile banks decide between app-level checks and OS-level overlay blocking?

A: Use both, but prioritise OS-level blocking where Android 12 or later is available because it prevents the overlay from rendering in the first place. App-level touch filtering remains necessary for older devices, yet it should be treated as a fallback, not the primary control.

Technical breakdown

How Android overlay attacks hide the real banking screen

An overlay attack uses the Android window overlay mechanism to place a rogue interface over a legitimate app. In practice, malware can present a full-screen fake login, a partial field replacement, or a transparent layer that is hard for the user to notice. The attack works because the target app still believes it is receiving normal user interaction unless the platform or the app detects that the window is obscured. This is why overlays are so effective against banking apps: they exploit trust in the visible UI rather than breaking encryption or network controls.

Practical implication: Treat visual integrity as a security control and test whether critical banking flows remain trustworthy when another app renders above them.

Why touch filtering is not enough against tapjacking

On older Android versions, banks cannot stop overlays from appearing, so they rely on touch filtering. The system can mark events with obscured-window flags such as MotionEvent.FLAG_WINDOW_IS_OBSCURED or MotionEvent.FLAG_WINDOW_IS_PARTIALLY_OBSCURED, and apps can reject those touches. That helps when the user still interacts through the app view, but it does not stop overlays that block touches or use transparent pass-through tricks. In those cases, the malicious layer intercepts or redirects the interaction before the banking app can inspect it, which leaves the underlying transaction logic exposed.

Practical implication: Do not treat obscured-touch checks as a complete defence, because they miss overlay patterns that never deliver a trustworthy event to the app.

How Android 12 changes overlay blocking for sensitive flows

Android 12 added a stronger model by letting apps ask the system to hide non-system overlays while sensitive windows are active. Using Window.setHideOverlayWindows(true), the app can instruct WindowManager to reject TYPE_APPLICATION_OVERLAY rendering on top of its foreground activity. That shifts the defence from passive detection to platform-enforced blocking. It is a meaningful architectural change, but only for devices that support it. Mobile banking teams still need to account for version fragmentation, Accessibility API abuse, and device compromise, because overlays are one layer in a broader mobile fraud chain.

Practical implication: Use system-level overlay blocking on supported devices, but keep fallback controls for older Android versions and for devices where the attack surface is wider.

Threat narrative

Attacker objective: The attacker wants to capture banking credentials or manipulate transaction approval so funds or account access can be abused without the user’s informed consent.

1. Entry occurs when a malicious Android app persuades the user to grant overlay or accessibility-related capability, or when malware lands on the device through a trojanised app.
2. Credential_harvested follows as the malware displays a fake banking interface or intercepts input, capturing PINs, passwords, or transaction details from the victim.
3. Escalation happens when the attacker uses the harvested credentials or manipulates a live transaction to gain account access or authorise a payment.
4. Impact is fraudulent account access or unauthorised transfer execution, with the user believing they interacted with the legitimate banking app.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• 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

UI integrity is the control boundary mobile banking teams still under-protect. Overlay attacks succeed because the app can no longer trust that the user is seeing or touching the screen it rendered. That makes authentication and transaction approval a presentation-layer governance issue, not just a malware detection problem. Practitioners should treat visible-screen assurance as part of the banking trust model.

Touch filtering is a mitigation, not a boundary control. Legacy Android defences can reject obscured touches, but only when the event reaches the app cleanly. Transparent overlays, full-screen fakes, and pass-through tapjacking can still defeat that model. The named concept here is UI trust gap: the distance between what the user believes they approved and what the app actually processed. Teams should govern for that gap explicitly.

Android 12 narrows the gap, but platform versioning makes the risk uneven. System-level overlay blocking materially improves protection, yet large mobile estates rarely sit on one OS version. That leaves banks with mixed assurance across devices, which is exactly where fraud operators concentrate. Practitioners should align mobile risk policy to the weakest supported client path, not the newest one.

Accessibility abuse turns overlay defence into a broader mobile app hardening problem. The article correctly notes that privileged accessibility services can observe text or inject UI structure in ways that sidestep ordinary overlay checks. That means identity and fraud teams need to coordinate with mobile security, app shielding, and device trust decisions. The practitioner conclusion is simple: overlay protection must sit inside a layered mobile assurance model.

Transaction approval should be treated as a high-value identity event. Once a malicious UI can influence approval, the issue is no longer only credential theft. It becomes fraudulent delegation of user intent. Banks that design controls around identity proofing, device binding, and secure interaction patterns reduce the chance that a fake screen can stand in for genuine customer consent.

What this signals

UI integrity has become a practical fraud-control requirement for mobile banking. If the customer cannot reliably see the genuine approval surface, then authentication strength alone does not protect the transaction. Banks should therefore align mobile app assurance, device trust, and customer verification around what can be rendered and touched on the handset.

Android fragmentation is the reason overlay risk persists. The same control can be strong on one device version and weak on another, which means programme teams have to design for mixed assurance across the fleet. Mobile security, fraud, and IAM owners should jointly define which flows demand overlay blocking, device binding, and stronger approval steps.

UI trust gap: this is the governance blind spot created when the user’s visible screen and the app’s executed action diverge. Closing it requires runtime blocking, device hygiene, and flow-specific trust decisions, not just better phishing awareness.

For practitioners

• Enforce overlay blocking on supported Android versions Call setHideOverlayWindows(true) on sensitive activities such as login and money transfer so the system hides non-system overlays while the app is foregrounded.
• Keep obscured-touch rejection on legacy devices Retain android:filterTouchesWhenObscured="true" and explicit MotionEvent flag checks on interactive components that still run on Android 11 and below.
• Bind transactions to the originating device Require device binding so credentials captured on one handset are far less useful on another, especially when the overlay malware only steals secrets rather than full device trust.
• Audit Accessibility service exposure Continuously enumerate enabled accessibility services and block or restrict sensitive flows when untrusted or sideloaded engines are active, because overlay checks alone do not catch those pathways.
• Use malware detection and app shielding on mobile endpoints Combine mobile threat intelligence, device compromise checks, and app shielding to detect rooted, jailed, emulated, or malware-infected environments that increase overlay risk.

Key takeaways

• Overlay attacks let Android malware interfere with what users see and touch, turning mobile banking UI design into a security control.
• The article shows that older Android defences can detect obscured touches, but they do not fully stop overlays that intercept or pass through interaction.
• Banks need layered mobile assurance, with OS-level blocking on supported devices and fallback controls for legacy Android estates.

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.
• Device binding: A control that links an authenticator or key pair to a specific endpoint so the same secret cannot be copied and reused elsewhere. It strengthens assurance, but the binding step itself becomes a high-value target if attackers can intercept the enrollment process.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. For teams managing identity risk across humans, workloads, and machine-driven workflows, it provides a common control language.