Topic starter
11/08/2026 3:13 pm
TL;DR: Android banking trojans use overlay attacks to steal credentials and manipulate transactions by drawing rogue interfaces over legitimate apps, and Android 12 added system-level overlay blocking while older versions still depend on touch-flag filtering and app hardening, according to OneSpan. The real governance issue is UI integrity: if authentication and transaction approval can be obscured or redirected, mobile banking risk becomes an identity and fraud control problem, not just a malware problem.
Editorial analysis by NHI Mgmt Group, based on content published by OneSpan: “How banks can detect and prevent overlay attacks against mobile banking apps”.
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.
A: Overlay attacks matter because they can capture credentials while looking like a legitimate login screen.
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.
Practitioner guidance
- 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.
Bottom line: Overlay attacks let Android malware interfere with what users see and touch, turning mobile banking UI design into a security control.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/08/2026 3:27 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Android overlay attacks expose a mobile banking UI integrity gap