Notifications
Clear all
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.
NHIMG editorial — based on content published by OneSpan: How banks can detect and prevent overlay attacks against mobile banking apps
By the numbers:
- 17 minutes and as quickly as 9 minutes, cly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read OneSpan's analysis of how Android overlay attacks target mobile banking apps →
Android overlay attacks: are mobile banking controls keeping up?
Explore further
11/08/2026 3:27 pm
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.
A few things that frame the scale:
- 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.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
A question worth separating out:
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.
👉 Read our full editorial: Android overlay attacks expose a mobile banking UI integrity gap
