A Glance at the Current Financial Services Android Malware Landscape

Written by Gerardo Pinar Loriente

In late 2022, a group of mobile banking apps suffered an attack by a malware strain designed to capture user credentials and automate the app to execute malicious transactions on behalf of the app user. In the context of such incidents, Fintech companies face the challenge of reinforcing their mobile applications against malware. This requires a thorough understanding of the latest malware trends and a commitment to implementing countermeasures — including countermeasures within the mobile app.

We have conducted research on malware that was discovered between 2020 and 2023, selecting 15 samples targeting the Financial Services sector, in particular, Android banking and mobile wallet applications. The samples were selected with the goal of aligning the most common malware families (see Appendix). We have identified common patterns in recent malware and explored specific defense mechanisms that could effectively deter malware from attacking your application. An especially important finding of this study is that malware countermeasures often constitute a tradeoff between security and user experience. Mobile application developers should refrain from implementing solutions that degrade user experience, especially for the most vulnerable groups of the apps’ users. Finally, we concluded that the effectiveness of malware countermeasures will rely on protections against reverse engineering and tampering.

In this research report, we will present our findings on how malware is usually distributed, before diving deeper into the attack methods and behavior patterns that were observed in the study.

Distribution patterns

Alternative markets and phishing have been, and still are, two of the most common ways of distributing malware.

However, the main channel of malware distribution is Google Play Store ( Cimpanu, Threat Fabric, nccgroup) where inconspicuous “dropper” apps are uploaded. Threat actors disguise these malicious apps as genuine apps, with functionalities such as document scanners or QR code scanners; these apps may even operate as expected. Once the dropper app is downloaded and run by the unsuspecting user, the malware will be unpacked and loaded onto the device. With the app installed, threat actors can then remotely download additional modules from the malware campaign server.

Malware “dropper” app on Google Play Store (source: Threat Fabric via Bleeping Computer)

Attack methods

The main attack methods observed in the analyzed samples are briefly described below.

Accessibility services abuse

Accessibility services are a set of native features on the Android OS developed to assist and enhance the experience of users with disabilities. However, our research shows these powerful features can be abused to introduce critical security risks. For instance, the important application sandbox principle is broken from the moment that a specific app has the ability to interfere with the UI of other apps. As we could expect, malware developers are well aware of, and taking advantage of, the newly available possibilities for exploitation.

Malicious accessibility services work by inspecting the events generated on the device, which allows them to track which application is being executed at any moment, what text is being entered, and what the screen layout looks like. We have seen this information being used in three distinct ways:

1. Triggering actions at a specific moment, e.g. when a particular view is shown on the screen.
2. Capturing sensitive information (keyloggers).
3. Performing a number of actions without the user’s knowledge or consent. Namely, self-granting permissions or elevating privileges to become a device admin app; as well as obstructing any action from the user that could threaten the malware’s operation, such as permission or privilege revocation, uninstallation, etc.

UI injections

Banking trojan apps are frequently capable of displaying, on top of a target application, a layer that mimics its login screen. This type of malware usually synchronizes with a server to download layout replicas of legitimate apps that are installed on the same device. These replicas are usually known as “injections’’ or “injects”. This malware then constantly tracks which application is being executed, and whenever it detects one of its targets, an overlay (e.g., a login screen) is drawn at the right moment. An example is shown below. When the user enters their credit card information, it is actually being entered on the layer controlled by the malware and is subsequently stolen by the malicious actor. More information about this threat and defense mechanisms is provided in this blog post.

Example of injection to steal payment card information (source: Cyberwise)

Injections can be classified as:

• view injections: referred to as “overlays” in this research, which is also the classical name.
• activity injections: simplified as “injections” in this research.

For overlays, a view is generated as a result of inflating a layout and adding to the window manager together with specific parameters to determine the nature of the window that will be placed on top of the target app:

WindowManager.LayoutParams params = new WindowManager.LayoutParams(\
    WindowManager.LayoutParams.MATCH_PARENT,
    WindowManager.LayoutParams.MATCH_PARENT,
    WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY,
    WindowManager.LayoutParams.FLAG_FULLSCREEN,
    PixelFormat.TRANSLUCENT);

LayoutInflater li = (LayoutInflater) getSystemService(LAYOUT_INFLATER_SERVICE);
View view = li.inflate(R.layout.target_overlay, null);
windowManager.addView(view, params);

In the case of activity injections, an activity is started through an intent. This activity usually contains a web view which will be loaded with the data received from the command-and-control server:

Intent intent = new Intent(this, MaliciousActivityInjectionActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.addFlags(Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
intent.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
startActivity(intent);

Device admin

Many of the malware pieces that we analyzed aim to become a device admin app. This status confers advanced capabilities such as wiping data; performing actions on the screen lock (i.e., changing the screen lock, setting password rules, monitoring screen unlock attempts, locking the screen, setting screen lock password expiration, etc.); setting storage encryption; disabling the camera, amongst other. All these actions are usually triggered remotely from an admin panel. Moreover, an application cannot be uninstalled as long as it is registered as an administrator.

Attempt to uninstall a malicious application which is a device admin app

In the samples we analyzed, the mechanism used to steal credentials was activity injection, whereas overlays were used for other reasons such as deceiving the user into thinking something is going on which does not correspond to reality. For instance, some command-and-control servers use a command to lock the device which is implemented with an overlay that prevents navigation. The content of the overlay window intends to make the user believe that the device is doing some operations such as restoring corrupted files.

SMS spying

We observed two methods used by the apps to spy on the SMS:

1. Using the RECEIVE_SMS permission together with a broadcast receiver with an intent filter to listen for incoming messages.
2. Using the READ_SMS permission and a content resolver to query for SMS.

This feature was fairly common, having been observed in all but two of the samples that we analyzed. A particular use case for this in the context of banking apps is the theft of 2FA (Two-factor Authentication) codes.

Screen spying

Another feature commonly integrated into malware is the screen capture capability which is used to steal sensitive data. The screen content can usually be streamed to the campaign server by the administrator commands from the admin panel.

Summary table

The different methods used in the examined malware pieces are summarized in the table below. The year corresponds to the date when the sample was first uploaded to the threat intelligence vendor database.

Behavior patterns

Most of the samples share a common pattern in deploying the malware capabilities which is based on acquiring accessibility capabilities as the initial step. The strategy to achieve this is by bothering the user through continuous notifications and/or windows popping up, prompting the user to grant accessibility capabilities for the malicious application.

Webviews, notifications, and toasts are shown to prompt the user to grant accessibility capabilities

Once this first milestone has been reached, the malware will start abusing accessibility capabilities. On one side, clickers are used to self-grant permissions and become a device admin app as well as to prevent the user from taking any action that could jeopardize the malware such as permission revocation, uninstallation, etc. For instance, if the user tries to access the malware application settings, the malware will click the “go backward” button. On the other side, keylogger mechanisms are activated.

Clicker behaviors are illustrated in the pictures below. Note that, in the example of the clicker self-granting device admin app status, the user could actually notice what is going on. However, this usually happens very quickly so it is not perceptible to the user.

Malware becoming a device admin app (left), preventing the user from accessing the app settings (center), and preventing device admin deactivation (right)

In parallel, the malware starts collecting information about the device and attempts to establish communication with its command and control server. If this communication succeeds, the malware will send the collected information and the server will send new modules or “injections” (if any) for any identified target, such as a particular bank application.

Apps executing in the foreground are monitored via accessibility services and, whenever a target application appears, an injection will be overlaid at the right moment, e.g. mimicking the login screen.

All retrieved data is then sent to the server.

Behavior patterns in malware

Discussion and conclusion

Malware attack methods are built based on vulnerabilities from three elements: the OS, the app design, and users’ behavior. We have identified attack patterns eventually relying on the user granting accessibility capabilities to the malicious app. We have also seen how these capabilities break the sandbox principle, exposing sensitive assets. Moreover, practices like using 2FA through SMS are actively exploited by malware and should be avoided.

The most popular methods to attack financial services applications that were used in the researched malware are:

• Malicious accessibility services
• SMS spying
• Screen overlays
• Screen recording

Excluding SMS spying, where the recommendation is to switch to different 2FA methods, the remaining three attack methods leverage specific features provided by the Android operating system to interact with any application that outputs data on screen and relies on-screen touch controls. The problem is that these features are used for legitimate reasons such as to support people with impairments, and cannot simply be deactivated in all cases. Consequently, countermeasures will constitute certain user experience tradeoffs. Simple methods such as denying all accessibility services will render the application unusable by people with disabilities or special needs. These users are the most vulnerable audience of your application and require the availability of accessibility service functionality. As a result, we advise against implementing security at their expense by simply turning off the functionality.

Instead, thoughtful implementation of countermeasures based on data and tailored to specific user workflows can achieve a much better outcome for all users and stakeholders. For example, requiring biometric authentication before an important transaction would not degrade the user experience, but it would effectively stop an a11y-based automation in its tracks since the biometric authentication screen cannot be automated by third-party software. However, biometric authentication can be avoided by malware by forcing a downgrade to non-biometric authentication, as demonstrated in the article by ThreatFabric.

When a proper set of malware countermeasures is implemented in an application, malware has to resort to specific repackaging and code patching techniques. Our research team is familiar with several examples, including a major banking app in Southeast Asia, where attackers attempted to patch out anti-malware functionality in an application. These examples demonstrate how important reverse engineering and tampering defense is as a foundation of any malware protection.

Concerning the status of countermeasure implementation in applications in the wild, in this study, researchers analyzed 1100 applications from the Google Play Store. Of the analyzed applications in the finance sector:

• Only 15.1% of them had login screens resistant to leaks through accessibility events,
• Only 3.5% were resistant to screen spying, and
• Only 5.8 % were resistant to malicious Input Method Editors (IMEs).

The methods used to protect against malicious accessibility services were deactivation and filtering of accessibility events. These numbers clearly show insufficient maturity in terms of protection in financial apps.

Appendix: Sample collection and background

In preparation for the practical study, we have reviewed security reports from main threat intelligence vendors and studied existing works done by other security researchers. This enabled us to focus on the right strains of malware and address the most important aspects of the malware under research.

We have selected 15 malware samples, discovered between 2020 and 2023 and targeting the financial services sector, more specifically Android banking and wallet applications. During the sample collection, we tried to align with the most relevant malware families. For instance, considering the number of users attacked in 2022, we included in our study samples from: Bian, with 24.25 % of attacks; Anubis sample (11.24 %); Gustuff, with 3.13 % of attacks; Bray (2.27 %) and Sova (2.14 %). Considering the number of samples seen in 2022 from January to May, we have included: Hydra (21.1 %); Cerberus (16.3 %); Anubis (6.6 %); Hookbot, whose ancestor Ermac had 6.9 %, and Gustuff (2.1 %).

We have analyzed the samples with a focus on the attack methods and patterns exhibited by that particular malware. Reproducing the attack methods on test devices allowed us to complete the second part of the practical study — research for effective countermeasures for every attack method, taking into account the version of the operating system, available permissions, and other aspects of the environment.

The sites used for sample collection were: Malware bazaar, Triage, and GitHub. Threat research sites consulted were: Securelist, Kaspersky, Malpedia, Threat Fabric, and NCC Group.

Threat intelligence engine sites used were mainly: Joe Sandbox, Virus Total, and Triage.

Information about some of the most relevant malware families is referenced below:

Anubis:

• sysopfb. “Manually unpacking Anubis APK” Github, 2018
• Bilal Can, Ahmet. “N Ways to Unpack Mobile Malware” pentest.blog, 2019
• eybisi. “Mobile Malware Analysis: Tricks Used in Anubis” eybisi, 2019
• Elshinbary, Abdallah. “Deep Analysis of Anubis Banking Malware” GitHub, 2020

Cerberus:

• ICS & IOT Cyber Security Bootcamp. “Cerberus Banking Trojan Research” Github, 2020
• Recorded Future. “Banking Web Injects Are Top Cyber Threat for Financial Sector”. recordedfuture.com, 2020

Godfather:

• LaurieWired. “Unmasking the Godfather” Github, 2023.

Hydra:

• Ionut Bucur. “Avira Labs Research Reveals Hydra Banking Trojan 2.0 targeting a wider network of German and Austrian banks” Avira Protection Labs, 2022.

Sharkbot:

• RIFT: Research and Intelligence Fusion Team. “SharkBot: a “new” generation Android banking Trojan being distributed on Google Play Store” nccgroup, 2022

Ermac and Hookbot:

• Kamp, Joshua, and Alberto Segura. “From ERMAC to Hook: Investigating the technical differences between two Android malware variants” NCC Group, 2023

Hashes of the samples are provided in the table below:

Sample_ID: SHA-256

• sample_01: cae0c0d33e68be9cf81099680b815eb714d8296cb219b7a6247f7f081820f39a
• sample_02: 1bdb7b83f3964b84d03694bbbc66a02f5a270043b8ac635932d9de12b81b172e
• sample_03: 48f23e5276fed57e2cd5986163f6ea13a0bfcb8bd63c71cf19eb09478f1bd1c8
• sample_04: 540bbe4d507b0e3691922d97fe1ff62c4e7668b3f1b6c3997083a1c49615e068
• sample_05: 0b72c22517fdefd4cf0466d8d4c634ca73b7667d378be688efe131af4ac3aed8
• sample_06: a14aad1265eb307fbe71a3a5f6e688408ce153ff19838b3c5229f26ee3ece5dd
• sample_07: 71c78101f7792fe879a082e323fed89c5e4a43132d01d3f79ed02afd8db45497
• sample_08: a6d27ba039ac9cb0d5a6a3cffca2002feb9ecb8cfed54ce5c0a768064084d43d
• sample_09: 50055d1f3b7df208e6d096ccd4317b2997af606c6c5662d30c0a457d6ce93965
• sample_10: 785190db6e1c12453e118fddd34cba9fb96a522347c7542813c2e97a5abce489
• sample_11: d7bc1f5935f83370514f5df110997c804eb15dc2ba1ade0a7f3021940445e65b
• sample_12: c0e391e254b74359896d287069883652a4b8bfd9ce2fd20a3cd7b441e1cbd600
• sample_13: 724a56172f40177da76242ee169ac336b63d5df85889368d1531f593b658606b
• sample_14: 1ed0598ecb75c742320d8168fd40d1d821c0e0680f2055d86372968c71527d96
• sample_15: da815165a474d869c8b2eb7aa288f728caa2a9195d81249acfee5db1a749e271

Originally published at https://www.guardsquare.com on January 23, 2024.