Android Overlay Attacks: Platform Limits and Defences

An overlay attack places a window controlled by the attacker on top of a legitimate application, usually a banking login screen, so that the victim types credentials into the wrong place. It is the defining technique of Android banking fraud and maps to MITRE ATT&CK Mobile T1417.002 — GUI Input Capture.

The technique has been in use for a decade, and the platform has spent most of that decade restricting it. Several Android releases since version 6 have closed part of the route. Banking trojans have adapted to each change, and the current generation relies less on the classic overlay permission than on the accessibility service.

The defending side — application security teams at banks and fintechs, and the analysts who triage samples that target them — needs three things: how the platform limits overlays today, what attackers do instead, and which controls a banking application can apply to its own screens.

Two ways to put a fake screen in front of the victim

The classic overlay. The malicious application holds SYSTEM_ALERT_WINDOW, shown to the user as "Display over other apps", and draws a window above whatever is in the foreground. When it detects that the targeted banking application has opened, it renders a copy of the login screen on top.

The accessibility-driven inject. The malicious application holds an accessibility service. The service receives window-change events, so it knows which application is in the foreground without enumerating processes. When the target appears, the malware launches its own activity — typically a WebView loading an HTML "inject" that imitates the bank — over the real application. No overlay permission is needed for this route.

The distinction matters in triage. A sample that declares SYSTEM_ALERT_WINDOW and nothing else describes, more often than not, a chat bubble or a floating widget. A sample that combines an accessibility service, foreground detection and a list of targeted package names describes a banking trojan, whether or not it requests the overlay permission.

How Android has restricted overlays

Two patterns stand out. First, some restrictions depend on the app's target API level and others apply to every app on a given OS version, so a device running an older Android release keeps the older behaviour; across Latin America, older devices remain a meaningful share of the installed base. Second, the exemptions in Android 10 explain why accessibility became the attacker's preferred route: an application with a bound accessibility service is allowed to start activities from the background, which is exactly what an inject needs.

How trojans adapted

Accessibility first. Modern families treat the accessibility service as the core of the implant. It detects the foreground application, launches the inject, reads one-time codes on screen, dismisses warning dialogues and blocks the uninstall screen. The overlay permission, where requested, becomes a secondary capability.

Coached installation. Every restriction that adds a confirmation screen is defeated most reliably by a person on the phone. In voice-led fraud, the caller presents as the bank's fraud department and walks the victim through enabling installation from unknown sources, granting accessibility and, on Android 13 and later, allowing restricted settings.

Changing the installation path. Restricted settings apply to applications installed outside session-based installers. Droppers have responded by installing the second stage through the session-based package installer API, which the Android 13 restriction did not cover; Android 15 extends restricted settings to many of those installers.

Remote targeting. The list of targeted applications and the inject templates usually arrive from the command-and-control server after installation. The installed APK contains the machinery, not the targets. This is why a static report of such a sample may show the capability set without naming the institutions involved.

The broader capability chain — accessibility abuse, SMS interception, staged delivery — is described in how Android banking trojans work.

Controls a banking application can apply

A banking application cannot prevent malware from being installed on the device. It can make its own screens a harder target and detect conditions that warrant a warning.

Discard touches when the window is obscured. Setting android:filterTouchesWhenObscured="true" on sensitive views, or calling setFilterTouchesWhenObscured(true), makes the view ignore touches delivered while another visible window covers it. For finer control, the application can inspect MotionEvent.FLAG_WINDOW_IS_OBSCURED and, from API 29, FLAG_WINDOW_IS_PARTIALLY_OBSCURED, and decide how to respond. This is a tapjacking control: against a credential overlay, the victim's input goes to the attacker's window, not to the bank's view.

Hide third-party overlays. On Android 12 and later, an application that declares the HIDE_OVERLAY_WINDOWS permission can call setHideOverlayWindows(true) on its windows. Application overlays from other apps are then hidden while those windows are shown. This is the most direct control available against classic overlays on supported versions.

Mark sensitive views for accessibility. On Android 14 and later, the accessibilityDataSensitive attribute restricts access to marked views to accessibility services that declare themselves as accessibility tools. The declaration is enforced by Google Play policy rather than by the platform, so a sideloaded service can claim it; the attribute raises the bar without closing the route. Password fields, one-time code fields and transaction confirmation screens are the natural candidates.

Protect against screen capture. FLAG_SECURE on sensitive windows prevents screenshots and blocks the window from appearing in screen recordings and non-secure displays. It does not stop overlays or accessibility reading, but it closes the screen-recording route that some families use alongside them.

Inspect enabled accessibility services. AccessibilityManager exposes the list of enabled services. An application can warn the user, or apply additional verification to high-risk transactions, when an unknown service is active. The decision has to be made carefully: users of assistive technology depend on these services, and blocking every enabled service excludes them.

Move confirmation off the device screen. For transaction signing, the strongest control is one the malware cannot render: confirmation through a separate channel or a cryptographic signature bound to transaction details, rather than a code the trojan can read from the screen or the SMS inbox.

These controls belong to the MASVS-PLATFORM category of the OWASP mobile standard, which covers how an application interacts with the operating system and its user interface. What MASVS and MASTG measure explains how that category is assessed and why a high score does not imply a threat-free device.

What static analysis shows in a suspected overlay sample

For a sample under suspicion, static analysis establishes the capability set without executing anything:

No single row is conclusive. The combination is the finding, and Droidwatch scores combinations rather than individual permissions for that reason. Findings are mapped to MITRE ATT&CK Mobile techniques so that the result enters an existing detection programme; the relevant ones for this pattern are T1417.002 for the overlay itself, T1516 for input injection and T1582 for SMS control. The SOC triage workflow sets out how to reach a classification from these signals.

Where the targets are delivered by the server, static analysis cannot name them. Executing the sample under instrumentation may reveal the inject when it loads, provided the command-and-control infrastructure is still answering; the trade-offs are covered in static vs dynamic analysis of Android malware. On Droidwatch, dynamic analysis is Android only, runs on the customer's own device or emulator through the Droidwatch agent, and is available from the Pro plan. No sample executes on Droidwatch infrastructure.

For a bank's own application, the same platform runs in the release pipeline: scanning APKs in CI/CD covers how to gate builds on the findings.

Frequently asked questions

Does Android still allow overlay attacks? Yes, with restrictions. The user must grant the overlay permission explicitly, overlays sit below critical system windows, and since Android 12 an application can hide third-party overlays over its own windows. Accessibility-driven injects remain the main route, particularly when the victim is coached through the permission screens.

What is the difference between an overlay attack and tapjacking? An overlay attack captures input by showing a fake screen. Tapjacking tricks the user into tapping a hidden element beneath a deceptive window. Android 12 blocks most touches that pass through windows of other apps, which curtails tapjacking; filterTouchesWhenObscured covers older versions for the views that use it.

Can a banking app detect that an overlay is shown on top of it? Partially. Touch events carry flags indicating that the window was obscured, and on Android 12 and later the application can hide third-party overlays outright. An activity launched over the application by malware is a different case: the bank's activity simply loses focus.

Is SYSTEM_ALERT_WINDOW alone a sign of malware? No. Messaging applications, screen filters and accessibility aids use it legitimately. It becomes significant when it appears together with accessibility abuse, target selection and inject rendering.

Which MITRE ATT&CK technique covers overlay attacks? T1417.002, GUI Input Capture, in MITRE ATT&CK Mobile.