January 23, 2024

    A Glance at the Current Financial Services Android Malware Landscape

    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.

    Seamlessly protect against malware with DexGuard’s built-in malware protection feature >

    Distribution patterns

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

    A-Glance-at-the-Current-Financial-Services-Android-Malware-Landscape_diagram-1

    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.

    A-Glance-at-the-Current-Financial-Services-Android-Malware-Landscape_diagram-2Malware “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.

    A-Glance-at-the-Current-Financial-Services-Android-Malware-Landscape_diagram-3Example 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);

    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.

    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.

    A-Glance-at-the-Current-Financial-Services-Android-Malware-Landscape_diagram-4Attempt to uninstall a malicious application which is a device admin app

    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.

    A Glance At The Current FinServ Android Malware Landscape_diagram-5

    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.

    malware-gif-1

    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-gif-2malware-gif-3malware-gif-4

    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.

    A Glance At The Current FinServ Android Malware Landscape_diagram-10_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:

    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

    Discover how Guardsquare provides industry-leading protection for mobile apps.

    Request Pricing

    Other posts you might be interested in