Overlay Attacks on Mobile Banking Apps: What They Are and How to Prevent Them

Overlay attacks are one of the most effective and insidious techniques used by mobile banking malware. The attack is deceptively simple: a malicious application draws a transparent or pixel-perfect fake interface on top of a legitimate banking app, capturing the user's credentials as they type. Because the overlay is visually indistinguishable from the real app, users have no way to detect the attack through visual inspection alone. This guide examines how overlay attacks work at the operating system level, why they are particularly dangerous on Android, the real-world malware families that use them, and how runtime protection can detect and prevent them.

What Are Overlay Attacks?

An overlay attack occurs when a malicious application uses the operating system's window management capabilities to draw content on top of another application. In the context of mobile banking, the malware monitors which app is in the foreground. When it detects that the user has launched their banking app, it immediately draws a fake login screen on top of the real one. The fake screen is a pixel-perfect replica of the bank's actual login UI, including the correct logo, colors, fonts, and input field placement.

The user, believing they are interacting with their banking app, enters their username and password into the overlay. The malware captures these credentials and either sends them to a command-and-control server immediately or stores them for batch exfiltration. Some advanced overlay malware also intercepts SMS OTP codes by abusing the READ_SMS permission, completing the full credential set needed for account takeover.

The critical aspect of overlay attacks is that the legitimate banking app is running normally underneath the overlay. The user's interaction is intercepted at the display layer, not the application layer. The banking app never receives the user's input because the overlay captures it first. From the banking app's perspective, the user simply never completed the login flow.

How Overlay Attacks Work on Android

Android's window management system is central to understanding overlay attacks. Android provides two mechanisms that malware exploits: the SYSTEM_ALERT_WINDOW permission (also known as "draw over other apps") and accessibility services.

The SYSTEM_ALERT_WINDOW permission allows an application to create windows that appear on top of all other applications. Legitimate uses include chat head bubbles (like Facebook Messenger's floating chat heads), screen recording tools, and system utilities. Before Android 6.0, this permission was granted automatically at install time. Starting with Android 6.0, users must explicitly grant it through Settings, but many users do so without understanding the implications, especially when prompted by apps that appear useful.

Accessibility services provide an even more powerful attack vector. Originally designed to help users with disabilities interact with their devices, accessibility services can monitor all UI events across all applications, read the content of any screen, perform actions on behalf of the user, and receive notifications about app launches. Malware that obtains accessibility service access can detect exactly when a banking app is launched and immediately trigger an overlay. The accessibility service also allows the malware to automatically grant itself additional permissions, including SYSTEM_ALERT_WINDOW, without user interaction.

The attack sequence typically works as follows. First, the malware is installed, often disguised as a utility app, game, or fake system update. Second, the malware requests accessibility service access, usually through a convincing dialog that instructs the user to enable it. Third, the malware registers a listener for app launch events. Fourth, when the target banking app is detected in the foreground, the malware creates an overlay window with TYPE_APPLICATION_OVERLAY and draws the fake login UI. Fifth, credentials entered into the overlay are captured and exfiltrated.

Why Overlay Attacks Are So Effective

The effectiveness of overlay attacks stems from several factors that make them nearly undetectable by the user. The overlay is a pixel-perfect copy of the banking app's login screen. Modern malware downloads the latest UI assets from its C2 server, so the overlay always matches the current version of the banking app's interface. If the bank updates their login screen, the malware's C2 pushes updated overlay templates within days.

The timing is seamless. The overlay appears within milliseconds of the banking app launching, before the real login screen has time to render. From the user's perspective, they tapped the banking app icon and the login screen appeared, exactly as expected. There is no visual indication that anything is wrong.

Users cannot distinguish the real login screen from the fake one through visual inspection. The overlay sits in front of the real app at the window manager level. There is no border, no title bar, no visual artifact that reveals the overlay's presence. Even technically sophisticated users cannot detect an overlay attack through normal interaction. This makes overlay attacks fundamentally different from phishing, where a careful user can check the URL bar for signs of a fraudulent site.

Android vs iOS Vulnerability

Android is significantly more vulnerable to overlay attacks due to its permissive window management model. The SYSTEM_ALERT_WINDOW permission, while requiring user consent on modern Android versions, is still grantable to any app. The accessibility service framework provides sweeping capabilities with minimal platform-level restrictions on how they are used. Android's open app distribution model (sideloading, third-party app stores) makes it easier for malware to reach users.

iOS is largely resistant to overlay attacks due to its strict sandboxing model. iOS applications cannot draw content outside their own window. There is no equivalent to SYSTEM_ALERT_WINDOW on iOS. The accessibility framework on iOS is more restricted and does not allow third-party apps to monitor or interact with other apps' UI. App Store review provides an additional barrier, though not an absolute one.

However, iOS is not entirely immune. Jailbroken iOS devices lose their sandboxing protections, and jailbreak tweaks can implement overlay-like behavior. More recently, researchers have demonstrated overlay-adjacent attacks on non-jailbroken iOS using creative abuse of notification and widget interfaces, though these are significantly less effective than Android overlays. The practical impact is that overlay attack prevention is primarily an Android security concern, though a comprehensive solution should also detect jailbroken iOS devices.

Detection Methods

Active overlay detection via WindowManager is the most direct approach. The banking application can query the Android WindowManager to determine whether any other application has drawn a window on top of it. On Android 9 and later, the WindowManager provides APIs to check the z-order of windows. If a non-system window is detected above the banking app's window, an overlay may be present. The limitation is that sophisticated malware may use window types that evade this detection, or set their overlay as transparent and touchthrough to avoid triggering z-order checks.

Accessibility service monitoring checks whether any non-standard accessibility services are active on the device. A banking app can enumerate the enabled accessibility services and flag those that are not recognized as legitimate (screen readers for visually impaired users, for example). Any unknown accessibility service represents a potential overlay threat because accessibility services are the primary mechanism malware uses to trigger overlays. The challenge is maintaining an up-to-date allowlist of legitimate accessibility services.

Z-order analysis examines the window stacking order in detail. The banking app determines its own position in the window stack and checks whether any unexpected windows exist above it. This technique detects overlays that are partially transparent or use unusual window flags. By combining z-order analysis with window attribute inspection (size, opacity, input handling flags), the detection can distinguish between system UI elements (status bar, navigation bar) and potential malicious overlays.

Screen recording detection identifies whether another application is actively recording or capturing the screen. On Android, screen recording requires a MediaProjection session, which the banking app can detect. Screen capture via the screenshot API also generates detectable system events. Detecting active screen recording is important because some malware families combine overlay attacks with screen recording to capture additional information beyond the login credentials.

Screenshot detection monitors for screenshot events that may indicate credential harvesting. While screenshots are a legitimate user action, automated or rapid-fire screenshots during a login flow are suspicious. The banking app can register a ContentObserver for the screenshot directory or use the Activity's onScreenCaptureStateChanged callback (Android 14+) to detect when screenshots are taken.

Real-World Malware: Cerberus, Anubis, and BlackRock

Cerberus emerged in 2019 as a banking trojan sold as malware-as-a-service on underground forums for as little as $2,000 per month. Cerberus pioneered several overlay attack techniques that subsequent malware families adopted. Its overlay engine downloads HTML-based overlay templates from a C2 server, allowing operators to target new banking apps without updating the malware itself. Cerberus supports overlays for over 200 banking apps across 30+ countries. Beyond overlays, Cerberus includes SMS interception for OTP theft, keylogging, screen recording, and remote access (VNC) capabilities.

Anubis is one of the most prolific Android banking trojans, first observed in 2017 and still actively maintained. Anubis is notable for its sophisticated accessibility service abuse. Once the accessibility service is enabled, Anubis can automatically grant itself all required permissions without user interaction, disable Google Play Protect, and prevent its own uninstallation. Its overlay engine monitors the foreground app and triggers overlays with sub-100ms latency. Anubis has been distributed through the Google Play Store itself, disguised as legitimate utility apps, reaching tens of thousands of installations before detection.

BlackRock appeared in 2020 as a derivative of the Xerxes malware (itself derived from the LokiBot source code leak). BlackRock expanded the overlay attack target list beyond banking to include social media, messaging, and cryptocurrency apps, targeting over 337 applications. Its overlay templates are particularly sophisticated, matching not just the login screen but subsequent screens in the authentication flow, capturing additional data like security questions, card numbers, and personal information. BlackRock also introduces anti-analysis techniques: it detects emulators, sandboxes, and analysis tools, refusing to activate its payload in research environments.

Prevention with RASP

Runtime Application Self-Protection (RASP) provides the most effective defense against overlay attacks because it operates within the application itself, detecting threats in real-time regardless of the device's overall security state.

Runtime overlay detection continuously monitors the window stack for unauthorized overlays during sensitive operations. Unlike a one-time check at app launch, RASP performs continuous monitoring throughout the session, detecting overlays that are injected after the initial security check. When an overlay is detected, RASP can obscure the sensitive UI (replacing it with a warning screen), terminate the session, or require re-authentication from a clean state.

Accessibility service abuse detection identifies when accessibility services are being used for malicious purposes rather than legitimate accessibility needs. RASP analyzes the behavior of active accessibility services, distinguishing between a screen reader that announces UI elements (legitimate) and a service that monitors app launches and performs automated actions (suspicious). This behavioral analysis reduces false positives compared to simply blocking all accessibility services.

Screen capture prevention uses the FLAG_SECURE window flag and additional platform-level mechanisms to prevent the app's content from being captured by screenshots, screen recording, or media projection. This prevents malware from capturing sensitive information through any visual interception method, not just overlays.

How Deep ID Detects Overlay Attacks and Screen Recording

Deep ID's RASP module provides comprehensive overlay attack detection as part of its device intelligence platform. The SDK performs continuous window stack monitoring during active sessions, detecting overlays with sub-50ms latency from injection to detection. The detection engine distinguishes between system overlays (keyboard, status bar, accessibility indicators) and potentially malicious overlays, minimizing false positives.

The SDK also detects screen recording and screenshot attempts, active accessibility services with suspicious permission profiles, remote access tools (TeamViewer, AnyDesk) that could be used for social engineering attacks where the attacker guides the victim through actions on their own device, and app cloning environments where the banking app is running inside a cloned workspace. All detection results are returned as structured Smart Signals in the device intelligence response, allowing the integrating application to apply context-appropriate policies based on the specific threats detected.