Detecting Banker Malware Installed on Android Devices
This article presents mechanisms and ideas for detecting malicious applications installed on Android devices that abuse the AccessibilityService feature. It focuses on identifying these applications from the perspective of legitimate apps.
Introduction
This article is focused on detection mechanisms of potentially malicious Android applications, which I implemented and shared on my GitHub about 3 years ago. The link to this resource can be found below. Despite the passage of time, these detection mechanisms are not widely recognized, and banker malware exploiting the AccessibilityService remain still popular.
In this article, I’m presenting various mechanisms utilised by malicious Android applications with advanced research and analysis on how specific malware leverages Android features to compromise their users. The presented detection mechanisms can be integrated into legitimate applications to identify potentially malicious software installed on the device or to assess the device’s security risk level.
For those interested in seeing these mechanisms in action, the implementation, along with a demo, is available at:
Is Mobile Malware a Real Threat to Users?
According to research from Kaspersky Security Network shared in The mobile malware threat landscape in 2023, Kaspersky detected 33.8 milion incidents of malware, adware, and riskware attacks against mobile users. These attacks were carried out by over 1.3 milion malicious applications. Nearly half of these packages (40.8%) were associated with adware threats, marking them as the most common form of malicious activity.
Almost 12% of the malicious applications, approximately 154,000, are categorized as Trojan Bankers.
The following chart presents a number of banking Trojan installation packages between 2020 and 2023:
The report does not provide explicit details about the numbers for the iOS and Android ecosystems separately. However, based on various pieces of information, it can be assumed that the majority of these malicious activities are associated with Android.
Actually, there are a number of major malicious campaigns targeting banks across the world. It would be challenging to share them all in this chapter but the following trojans are examples of malicious apps abusing Android AccessibilityService:
- TeaBot: Android malware targeting Europe banks
- Chameleon: Banking Trojan with Biometric Bypass capabilities
These Trojans can be found in applications available on Google Play or third-party app stores. Such apps are distributed through various communication channels, including text messages and emails, which persuade victims to install the malicious software.
Interestingly, a majority of these apps do not directly exploit any vulnerabilities in the Android platform post-installation. Instead, they abuse legitimate Android features, especially AccessibilityService, convincing users to grant excessive permissions to the installed app. This abuse enables Trojan bankers to acquire permissions for:
- Screen streaming
- Keylogging
- Overlaying (modifying screen content)
- SMS reading, sending, blocking
- Recording sounds
- Accessing files
With these permissions, modern trojan bankers are able to perform any activity on the victim’s device. As a result, they can bypass legitimate application’s biometric auth, bypass 2FA codes and transfer (steal) victim’s credentials or funds from financial applications.
So, is mobile malware a significant concern for Android users? Absolutely.
Can malicious activities like these be detected by legitimate sensitive mobile applications e.g. financial apps? While not every case might be detected, a number of fraudulent transactions could be prevented.
Developers of sensitive mobile applications often implement root detection checks. In my opinion, the threat posed by these described malicious applications is currently a more significant concern for user security than rooted devices.
Android AccessibilityService
The purpose of AccessibilityService on Android is not to make life of malware developers easier. The intent of this feature is to assist users with disabilities in navigating and utilising Android devices and applications. In the Android documentation we can read:
An accessibility service is an app that enhances the user interface to assist users with disabilities or who might temporarily be unable to fully interact with a device. For example, users who are driving, taking care of a young child, or attending a very loud party might need additional or alternative interface feedback.
Accessibility applications are able to retrieve the window content presented by other applications, perform activities such as clicking on the button, and providing texts into inputs. These features are highly useful for developers creating apps that help people with disabilities. For example, legitimate accessibility applications can read screen content aloud for users.
However, while these capabilities serve a noble purpose in aiding individuals, in the wrong hands, they can cause substantial harm, leading to significant financial losses for users.
For security reasons, starting from Android 13, accessibility services are restricted only to applications installed from legitimate app stores. However, based on another Kaspersky report, these restrictions can be bypassed. More about security improvements in recent Android versions can be found further in this article.
Example Infection Scenario — Anubis
Some time has elapsed since my initial research was conducted in 2021, but I want to share the infection process to help you better understand your adversary. I utilized an old Anubis sample for this demonstration, although the malicious activities of this and other Trojan bankers may still appear similar.
I installed Anubis — a commonly observed banking Trojan — on my old Samsung S5 Android device, which was used exclusively for laboratory purposes within a simulated environment. I don’t recommend doing this if you don’t have enough knowledge in a mobile security area. After installing malware on your device, the most secure approach is to treat the device as compromised and not use it for any sensitive or personal activities.
To obtain an .apk file containing the Anubis malware, I conducted online research and located it after several minutes. Upon installing the application via adb (Android Debug Bridge), I observed the following icon with “pandemidestek” title on the mobile screen. This particular .apk was distributed mainly targeting Turkish users during the C-19 pandemia.
At this stage, the application was installed, but its malicious mechanisms had not yet been activated. After clicking on the application icon, the app launched, and it directed me to the “Accessibility” settings screen, as presented below. Additionally, the application persistently displayed a notification stating “Enable access…” in the middle of the screen. This notification was designed to convince the victim into clicking on the pandemistek icon once more to grant the necessary access.
To enable the AccessibilityService for malicious app, it was required to toggle “Use service”…
and click on “OK” to confirm the action.
After enabling the Accessibility Service, the malicious app took over the control of the device. It used its new capabilities and just in a few seconds granted a number of permissions without any manual interaction. It accepted all of the permission prompts as shown on the examples below:
After granting the permissions, the application displayed Google website to user and hid its presence on the device.
The infection process resulted in the application taking complete control over my device. Subsequently, any activity I performed on the device could be monitored or hijacked. Moreover, the Trojan was capable of executing actions without my consent or interaction.
For more in-depth analysis of Anubis, utilizing reverse engineering techniques, I highly recommend this article.
Detection Mechanisms
What Can Legitimate Applications Do To Improve User Security?
At the time of writing this article, Android offered features to identify installed applications on a device and gathering basic details about these applications, such as name, signatures, permissions, or information if the application is utilising AccessibilityService. Based on those pieces of information legitimate application could detect potentially malicious apps. They could also notify the application's servers about a suspicious environment, thereby flagging the user's device environment as potentially malicious or high risk in terms of fraud.
Detecting Applications Abusing AccessibilityService
Finally, in this section, I will present techniques to detect potentially malicious applications that abuse AccessibilityService. I hope the previous sections were engaging and in the same time provided you with the context to understand the seriousness of the issue.
Since Android 4 (API level 14), the platform offers applications a method to list accessibility services enabled on the device. This method, named getEnabledAccessibilityServiceList, is a part of AccessibilityManager class. The Java code shown below allows to list enabled accessibility services:
AccessibilityManager am = (AccessibilityManager) mContext.getSystemService(Context.ACCESSIBILITY_SERVICE);
List<AccessibilityServiceInfo> services = am.getEnabledAccessibilityServiceList(
AccessibilityServiceInfo.FEEDBACK_GENERIC |
AccessibilityServiceInfo.FEEDBACK_VISUAL |
AccessibilityServiceInfo.FEEDBACK_HAPTIC
);In the code provided above, you can see the use of feedback flags designed to filter accessibility services that utilize those feedback mechanisms to interact with other applications. From my research, it has been observed that these flags were utilised by malicious applications.
However, using only this code you could notice that it may return legitimate services that are installed with your system. To lower false positive results, it’s possible to filter out system applications by adding the following code:
List<AccessibilityServiceInfo> retSvcs = new ArrayList<>();
PackageManager pm = mContext.getPackageManager();
for (AccessibilityServiceInfo svc : services) {
PackageInfo packageInfo = null;
try {
packageInfo = pm.getPackageInfo(svc.getId().split("/")[0], 0);
} catch (PackageManager.NameNotFoundException e) {
// pass Exception, packageName not found
}
if (packageInfo == null)
continue;
if ((packageInfo.applicationInfo.flags & (ApplicationInfo.FLAG_SYSTEM | ApplicationInfo.FLAG_UPDATED_SYSTEM_APP)) == 0)
retSvcs.add(svc);
}Now, the variable retSvcs contains a list of services installed by the user.
Let’s follow the rabbit and implement more robust detection strategies.
Detecting Suspicious AccessibilityService Capabilities and EventTypes
Accessibility services utilize a range of capabilities and event types. The capabilities dictate the types of actions a service can execute, which can be obtained through the getCapabilities method of AccessibilityServiceInfo class. Event types define the events that will be received by the service. In malicious applications, theCAPABILITY_CAN_RETRIEVE_WINDOW_CONTENT capability can be observed which allows a service to retrieve the window content, as implied by its name. In terms of event types, the following events were identified to be in scope of interests by these apps:
TYPE_WINDOW_STATE_CHANGED
TYPE_WINDOW_CONTENT_CHANGED
TYPE_VIEW_FOCUSEDThey are related with changes on the screen. Those events enable a malicious app to react on user’s activities and read content on change.
Suspicious capabilities and event types can be detected in the following way, assuming that svc is an instance of AccessibilityServiceInfo class.
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR2)
if ((svc.getCapabilities() & CAPABILITY_CAN_RETRIEVE_WINDOW_CONTENT) != 0)
Log.d("Content can be retrieved by ", svc.getId());
if ((svc.eventTypes & (TYPE_WINDOW_STATE_CHANGED | TYPE_WINDOW_CONTENT_CHANGED | TYPE_VIEW_FOCUSED)) != 0)
Log.d("Suspicious event types detected ", svc.getId());Detecting Overlay Attacks Capabilities
One of the attacks employed by malware applications to steal credentials from victims on mobile is known as an overlay attack. In this scheme, a malicious app displays an overlay window to the victim that looks identical to a legitimate banking app’s interface. In this way, victim can be tricked to provide there their credentials or sensitive data. However, executing an overlay attack requires granting android.permission.SYSTEM_ALERT_WINDOW permission. This permission can be verified in the following way assuming that packageInfo is an object of PackageInfo class.
if (packageInfo.permissions != null)
for (PermissionInfo perm : packageInfo.permissions) {
if (perm.name.equals("android.permission.SYSTEM_ALERT_WINDOW")) {
Log.d("Possible overlay attack ", packageInfo.packageName);
}
}
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M && packageInfo.requestedPermissions != null)
for (String permName : packageInfo.requestedPermissions) {
if (permName.equals("android.permission.SYSTEM_ALERT_WINDOW")) {
Log.d("Possible overlay attack ", packageInfo.packageName);
}
}Detecting Other Suspicious Permissions
Additionally, you can detect other suspicious permissions utilised by potentially malicious applications, as presented below:
String[] suspiciousPermissions = {
"android.permission.REQUEST_INSTALL_PACKAGES",
"android.permission.REQUEST_DELETE_PACKAGES",
"android.permission.INJECT_EVENTS",
"android.permission.CAPTURE_SECURE_VIDEO_OUTPUT",
"android.permission.INSTALL_PACKAGES",
"android.permission.KILL_BACKGROUND_PROCESSES",
"android.permission.sec.MDM_REMOTE_CONTROL",
"android.permission.FOREGROUND_SERVICE",
"android.permission.RECEIVE_BOOT_COMPLETED"
};
if (packageInfo.requestedPermissions != null) {
for (String perm : packageInfo.requestedPermissions){
for (String suspPerm : suspiciousPermissions) {
Log.d("Detected suspicious permission ", suspPerm);
}
}
}
if (packageInfo.permissions != null) {
for (PermissionInfo perm : packageInfo.permissions) {
for (String suspPerm : suspiciousPermissions) {
Log.d("Detected suspicious permission ", suspPerm); }
}
}Of course, the list of suspicious Android permissions can be extended. The provided list contain the most dangerous and in many cases unreasonable permissions for a legitimate application.
Detecting If Application Was Recently Installed
Another useful detection mechanism could be to validate if application utilising AccessibilityService was installed recently e.g. in last 15 minutes. If such application was installed recently, the device security risk is higher. This threshold can be extended, I used 15 minutes for example purposes.
if (Math.abs(packageInfo.firstInstallTime - System.currentTimeMillis()) > 15 * 60 * 1000)
continue;More Detection Mechanisms and Detection Demo
More detection mechanisms and video with demo presenting implemented checks can be found on my Github:
Device Risk Analysis
It should be noted that there is no one silver bullet to secure all Android applications against every type of malware discussed in this article. However, it is feasible to implement various checks as part of a device risk analysis conducted from the perspective of a legitimate application.
To implement an effective device risk analysis, I’d recommend to gather as much data as possible about installed applications, their permissions, accessibility services in use and root detection checks. At the beginning of this article, I mentioned root detection. I continue to recommend it as a means to assess the integrity of the device.
Based on these pieces of data it would be possible to create a device risk scoring. In case of high risk score, sensitive actions performed by the application could be flagged as potentially malicious activities. In this way, a number of attacks performed against users of financial applications could be identified before materialising.
Android Security Improvements
After reading this article, it might seem that Android users are significantly vulnerable to threats without adequate protection. However, it’s important to note that the Android platform continuously implements new security mechanisms. These can be leveraged by legitimate applications to bolster their security posture against malware.
For instance, starting from Android 14 (API 34), developers have the ability to set the accessibilityDataSensitive attribute in the view. This ensures that only accessibility services specifically designed for individuals with disabilities will be able to interact with the view. Additionally, any application using an AccessibilityService tailored for individuals with disabilities must have the IsAccessibilityTool attribute set. Furthermore, developers are required to obtain approval from Google Play via Permission Declaration Form before releasing such application in legitimate Google store.
It’s important to note that Android 14 was released on October 4, 2023 and it will take some time for users to update their devices to the latest version. For many users, updating the Android version may require purchasing a new device.
Summary
In this article, my aim was to shed light on the issue of Android AccessibilityService and provide insights into detecting malware applications that exploit this feature. I highly recommend to implement detection mechanisms presented in this article at least as often as root detection checks to protect users of sensitive applications against malware.
The Android platform is still improving, with more security features enforced on Android devices and improved processes in Google Play for identifying malicious applications. As a result, malware developers and threat actors face new challenges in their malicious activities, making their attacks less effective.
It’s crucial to remember that client-side security is an ongoing battle, with attackers constantly evolving and developing more sophisticated campaigns. In response, creators of sensitive applications should increase security awareness among their users to ensure they are aware of ongoing attack scenarios.
Recommendations for Regular Android Users
As a part of this article, I strongly encourage you to share these recommendations with regular Android users. Sharing these tips may help prevent someone from losing money, access to their social media accounts, email inbox, or encountering other security breaches in the future.
- Don’t install applications from untrusted sources other than Google Play.
- Don’t grant permissions to newly installed applications if you’re unsure whether they’re needed.
- Be cautious when clicking on links received from unknown senders. If you have any suspicions, consult with a tech-savvy friend or a family member.
References
- Kaspersky’s report on mobile threats in 2023 | Securelist
- Deep Analysis of Anubis Banking Malware
- Protecting Against Android Accessibility Services Threats | Guardsquare
- Anubis II — malware and afterlife
- Android Banking Trojan Chameleon can now bypass any Biometric Authentication
- TeaBot: a new Android malware emerged in Italy, targets banks in Europe
This article was originally published at my personal website — DevSec Blog. If you’re looking for more Application Security, DevSecOps and related technical articles, just let me know what type of content you’re interested in and Follow me to get notified about new articles as soon as they’re released! 🚀🚀🚀
You can also visit my LinkedIn or Twitter profiles, if you’re keen on speaking about technical stuff! 💬
