Most organized cybercriminal groups are financially motivated. The shift from web to mobile banking makes mobile banking apps the top targets of cybercriminals. The more people use mobile apps for bank transactions, the more adversary attention is drawn and the more cyberattacks are carried out. 

Regarding the methods used against mobile banking apps, the Verimatrix threat intelligence data feeds show that infecting mobile users with malware outweighs any other threats in the Android ecosystem, and malware is undoubtedly the main attack vector used in the wild. 

Android banking trojans (ABTs) are specially crafted malware for attacking banking apps. They have one goal, and that’s to steal the maximum amount of money from victims’ bank accounts. To accomplish their goal after accessing victims’ devices, the first security measure to stop banking trojans is the banking login credentials. 

Overlay attacks are traditionally the most common technique to overcome this obstacle. They rely on nothing but accessibility service abuse. This post focuses on the technical basis of the overlay attacks. Additional credential theft techniques used by banking trojans will be explored in a future post.

Accessibility Service Abuse

Android’s accessibility service API is designed to help people with disabilities use Android devices and apps. It provides ways to query the content of the active window on the screen and interact with it programmatically. Over the years, it has also been used for hands-free control of the apps, for example, while driving or cooking, or automated testing of user interfaces (UI) other than their original purpose. 

Cybercriminals didn’t take long to discover and abuse the accessibility service API, either. While the first occurrence dates back as early as 2013 by threat intelligence experts, it is a standard feature of banking trojans today.

When the malicious app starts, the first objective of the trojan is to obtain accessibility service permission. To convince the victim, it opens a legitimate-looking window on the screen, as depicted in Figure 1 and Figure 2.

Sample view of Hook ABT as a mobile app overlay.

Figure 1: View from a Hook ABT sample

Sample view of Xenomorph ABT as a mobile app overlay.

Figure 2: View from a Xenomorph ABT sample

Clicking these windows will take the victim to the system settings, where the victim grants the malicious app the necessary accessibility permission. From there onward, the app will grant itself all the remaining permissions automatically by exploiting the accessibility service API.

Overlay Attack

An overlay attack presents a phishing window over a targeted banking app and hopes the victim does not recognize it. The phishing window typically looks identical to the banking app’s login page, and it is triggered quickly when the user launches the banking app, which deceives the victim into typing the banking credentials and/or credit card information into the overlay window. A banking trojan immediately transfers the captured data to the command-and-control server (C2) afterward. 

Predominantly mobile banking apps are targeted with overlay attacks, but many digital wallet and cryptocurrency trading apps have been quickly added to the target list in recent years due to their increased popularity. Globally popular e-mail, messaging, social media, shopping, entertainment, transport, travel, and restaurant apps are other common targets. Interestingly, local popular brands are also found to be targets in regions where mobile malware activity is high.

The following short clip shows what an overlay attack looks like in real life.

A video showing what an overlay attack looks like in real life.


We will explain the implementation of the overlay attack with the example of a state-of-the-art banking trojan: Hook. The implementation is almost the same in different banking trojans. The code snippets below are intentionally reduced for better visibility.

The following code is responsible for detecting the change in the foreground window. This is the part where the accessibility service is misused for the overlay attack. The Android system interrupts the banking trojan via the overridden onAccessibilityEvent(*) callback function, which is called when an event occurs on the screen. TYPE_WINDOW_STATE_CHANGED indicates a change in the visually distinct section of the screen; for instance, the user launched a banking app, and it took over the screen.

Part 1 of an explanation by Verimatrix's experts on how an overlay attack can be set in an app's code.

The following code is responsible for checking if a targeted app is started in the foreground and triggering the overlay attack if it is true:

Part 2 of an explanation by Verimatrix's experts on how an overlay attack can be set in an app's code.

The following code is responsible for starting a new task in the foreground:

Part 3 of an explanation by Verimatrix's experts on how an overlay attack can be set in an app's code.

The following code is responsible for loading the web inject/overlay (HTML file) corresponding to the targeted app in a Web View, updating the default language configuration of the overlay based on the user’s language settings, and adding a javascript interface to receive data from the overlay.

Part 4 of an explanation by Verimatrix's experts on how an overlay attack can be set in an app's code.

returnResult(*) or send_Log_injects(*) function is called within the HTML file in the WebView to pass data to the banking trojan.

Part 5 of an explanation by Verimatrix's experts on how an overlay attack can be set in an app's code.

The following code initiates the transfer of data to a remote command-and-control (C2) server.

Part 6 of an explanation by Verimatrix's experts on how an overlay attack can be set in an app's code.

The implementation of the overlay attacks depends only on the BIND_ACCESSIBILITY_SERVICE permission. REQUEST_IGNORE_BATTERY_OPTIMIZATIONS and RECEIVE_BOOT_COMPLETED permissions are also useful for the reliable operation of banking trojans, which are indirectly used in the overlay attacks.

Android Countermeasures

To the best of our knowledge, Android OS does not yet have a solution to completely stop the overlay attacks.

In Android 12, the AccessibilityTool attribute is introduced. It prompts a warning to alert users that an app, not declared as an accessibility tool, has powerful accessibility permissions 24 hours after granting them. Whether users take this warning seriously and revoke the permissions or not, there is still a 24-hour window that can be exploited. 

In Android 13, sideloaded apps are prevented from acquiring accessibility permissions. It keeps track of the app installation methods and blocks the non-session-based installed apps from getting accessibility permissions. For instance, clicking the APK (Android Package Kit) file downloaded from the web usually triggers non-session-based installation, whereas app stores usually support session-based installation. This countermeasure does not stop the malware installed from the app stores as well as the malware deployed by an intermediate app, also known as a dropper app. The dropper app implements a session-based installation to sideload the malicious app and bypass the restrictions. Users could also be tricked into allowing the restricted setting in the app info menu that explicitly exempts the app from this countermeasure.

In Android 14, the accessibilityDataSensitive attribute in View is introduced. The View class is the basic building block for user interface (UI) components. The new attribute enables developers to let only accessibility tools interact with the critical parts of the UI. However, overlay attacks do not interact with the targeted app’s UI. It detects that the user launches an app and extracts only the package name of that app from an accessibility event. Therefore, this countermeasure does not affect overlay attacks. However, other core features of advanced banking trojans, such as keylogging and automated transfer systems (ATS), are impacted.


It is widespread for ABTs to perform overlay attacks due to their simplicity, effectiveness, and scalability. Below is a short list of infamous ABTs and their overlay attack capability. All of these support the overlay attack enabled by accessibility service abuse. It is a core element of any adversary toolbox.

Android Banking Trojan (ABT) Accessibility Service Abuse Overlay Attack
Anatsa (Teabot)
Octo (ExobotCompact, Coper)

Another good indicator of how pervasive overlay attacks are lies in the activity of the InTheBox dark web marketplace. This is the biggest shop specializing in overlays (HTML files) for various ABTs. It works on a per-order basis to create new overlays, and those fulfilled orders are eventually offered to everyone with a $30 price tag. In a year, 225 new targets for Alien/ Octo/ ERMAC/ Metadroid/ Hook and 52 new targets for Hydra were listed for sale. 

A line graph showing the number of overlays found in the InTheBox Marketplace from November 2022 onwards.

Verimatrix XTD detects overlay attacks and accessibility service abuse with high precision. Today, the anti-malware feature is a necessity for mobile banking apps to defend against sophisticated cybercriminal groups, and XTD brings the necessary anti-malware features to any mobile app.