April 9, 2024
In our recent webinar “Android Malware: How It Works And How to Protect Your Application against It”, I sat down with our Security Researcher, Gerardo Pinar Loriente, to present the findings of our latest research on Android Malware targeting the Financial Services industry.
To learn more about malware research, watch the on-demand webinar above or read the summary below. Furthermore, you can find more information about other attack techniques and countermeasures in our Mobile Application Security Research Center.
Seamlessly protect against malware with DexGuard’s built-in malware protection feature >
Android malware: Types, evolution, and scale
By definition, malware is any software intentionally designed to disrupt, damage, or gain unauthorized access to a particular system. One of the first known examples of malware was the Creeper virus, created as a part of an experiment in 1971. Fast forward five decades and the malware landscape is now difficult to pin down given just how diverse the types of malware have become. Nowadays, malware attack targets can range from specific end-users to the general population of specific countries.
Broadly speaking, we can categorize mobile malware into two categories, depending on their target victim. User-targeting malware, like Pegasus, is a type of malware that focuses on spying on specific high-profile users using zero-day exploits. This type of malware generally employs highly sophisticated attack methods. On the other hand, App-targeting malware like BrasDex, is a relatively easy malware to develop, abusing OS features (i.e., accessibility services) to commit fraud and steal money from a broader audience. In our webinar, we chose to focus on App-targeting malware.
Android Malware Evolution
When we take a look at the trends of app-targeting malware campaigns over the past decade, we can see that there are mainly two ways for them to attack users: By stealing and monetizing users’ stolen personal information and a more recent trend of performing financial fraud directly on victim’s devices by exploiting Android’s services, namely accessibility services, and overlays.
Unsurprisingly, over the years the number of banking malware families with dangerous capabilities like device takeover has increased steadily. This, coupled with tens of thousands of malware samples that could target one mobile banking app alone, makes it easy to understand why developers may feel overwhelmed and puzzled about where and how to start addressing this challenge. Android malware is a real, ongoing global problem that costs victims tens - if not hundreds - of millions of dollars each year.
For us to be able to implement the right countermeasures against malware, we will need to first identify how malware works to understand its behaviors and the techniques used to attack users.
Android malware: Accessibility services as the cornerstone
In our research, we focused our efforts on studying attack methods observed in real-life Financial Services malware that target Android banking and digital wallet apps. Trying to align with the threat intelligence reports, we selected 15 recent samples, no older than 2019, out of the most popular malware families. As a result of this study, we have identified 7 common attack methods employed by the samples we studied, namely accessibility abuse, activity injection, view injection, privilege escalations as well as more classical attack methods such as SMS and screen spying. You can learn more about our research findings in this blog.
If we look at the anatomy of malware attacks, we can see that the end target is the user’s sensitive data to perform fraudulent transactions. Some examples of this data are Personally Identifiable Information (PII), card payment data, and PIN codes. Accessing the user's sensitive data can be done through different methods such as spying on keyboards, SMS, and screens. For instance, using Android accessibility services is a useful feature in Android designed to assist users with disabilities so they can properly use the app can be utilized by attackers. Malware could intercept sensitive information as it is typed, or conveniently manipulate what is being shown on a user’s screen through overlays, tricking users into disclosing sensitive information to the attackers. Furthermore, they can also automate certain actions such as performing fraudulent fund transfers without the users’ knowledge. We observed that the fundamental malware attack patterns rely on accessibility services.
Accessibility Services on Android
Malware can gain access to accessibility services capabilities by prompting the user to grant these capabilities using web views, notifications, and toasts. The malware will continually harass the user with these prompts until the user grants the malware access to the capabilities. Then, the malware will use clickers to obtain additional permissions and become a device admin app. Concerningly, the malware can protect itself from “harm” through defensive clicking, making it impossible for users to revoke these privileges, effectively preventing them from accessing app settings or performing factory resetting to their devices.
Once the malware has obtained the required privileges and persistence, malware can start what they’re built for, such as:
- Sniffing accessibility services events for sensitive user data
- Automating actions like fraudulent transactions on target applications
- Triggering actions at the right moment like deploying UI injections, namely:
- Overlays to manipulate users or steal sensitive data
- Activity injections to steal sensitive data
Accessibility services abuse countermeasures
Detecting suspicious applications
Simple Allowlisting
One primary approach developers can take is to scan for applications in the user’s device with accessibility services enabled, and search for dangerous patterns like side-loading, device administrator, etc. This can be done by checking these applications against a predefined list using simple allowlisting.
Allow system apps
Another approach is to allow trusted system applications that legitimately require accessibility services functionalities. We can do this by checking whether or not they have their FLAG_SYSTEM set. If they have it set, this means the application can be trusted.
Spot accessibility services and device admin
Since Malware that has gained accessibility services capabilities would usually self-grant device administrator rights, we could utilize these two characteristics to spot potentially dangerous applications.
Spot side-loaded accessibility services apps
Malware often follows a multi-stage approach from distribution until it is fully operational on a victim device. For instance, attackers would distribute a seemingly harmless and legitimate application on an official application store like Google Play Store. Once unknowing users download and install it, the application will deploy the malware payload as an additional module or a separate application. Knowing this, we can spot potentially dangerous applications by first defining a list of trusted installers like Google Play Store, Samsung Galaxy Store, and Huawei App Gallery, amongst others. Once we have listed them down we can iterate across a list of enabled accessibility services and single out the applications that were not installed from one of the trusted app stores.
Blocking accessibility services capabilities
Complete block of accessibility services
One of the most obvious ways to prevent accessibility services abuse is by blocking these capabilities altogether. While this might seem a quick and convenient way to solve this problem, this will come at the cost of those who need this feature, essentially preventing them from being able to use our application altogether. But this doesn’t have to be the case! What if we can determine whether a user truly needs accessibility services by asking them to follow a certain sequence of commands during the initial configuration of the application?
We can confirm if a user requires accessibility services to use our application
One example to test for this would be to first ask the user to wait for a few seconds through text and audio prompts. We can then show a text prompt to ask the user to perform certain tests such as clicking an on-screen button. If the user does what the test asks, we can safely assume that the user can read the text without a problem and does not need accessibility services to use the application. On the other hand, if the user does nothing or fails to pass the test, we can safely allow the user to use accessibility services. However, this method could easily be bypassed by malware if the on-screen buttons are not protected against clickers. This highlights not only the importance of layering our malware defenses but also creativity in ensuring that all of our users get to have the same level of security and user experience.
Filtering accessibility events to prevent keyloggers and clickers
How keylogger work
Attackers can spy on the input of sensitive data the users type by spying on accessibility events of particular fields the data is being filled into. Countermeasures based on filtering accessibility events at the source were proposed in a paper in 2017. This allows us to control what information gets disclosed outside of the application. One way to do this is by using accessibility delegates.
Preventing keylogger
Using accessibility services, malware can know everything that is displayed on the screen and can retrieve views and write or click on them just by using Android APIs. For instance, malware can retrieve a button identifier and perform an action using ACTION_CLICK. This means malware can know exactly when and which parts of the screen to click on to perform fraudulent transactions in a split second, without the user even realizing it. We can prevent this from happening by filtering the action at the source using accessibility delegates, setting up a callback function to detect any clickers that try to interact with our application, and blocking specific actions like writing text (ACTION_SET_TEXT) and clicking (ACTION_CLICK).
Preventing clicker: Before and after
Preventing View injection aka. Overlay
There are different types of Android overlay that attackers can use to perform their attacks, depending on whether they let touches through or not: transparent overlay and non-transparent overlay (blocking or not blocking). It is worth noting that Android does not allow an overlay to capture a touch and pass it through.
Different types of Android overlays
To prevent each of these overlays we can employ several different defense techniques. Using FLAG_WINDOW_IS_OBSCURED and FLAG_WINDOW_IS_PARTIALLY_OBSCURED we can detect any touches that have gone through an overlay. With Window Punching, we can detect the opposite, where a touch input of a view gets blocked by an overlay. Finally, starting from Android 12 we can hide all non-system overlays and address all of these cases by setting setHideOverlayWindows(true)in the code.
Different types of Android overlays
Window Punching to prevent overlay attack
Proposed in 2016, Window Punching is a technique that simulates touches (“punches”), ideally at random, across the whole screen or a portion of the screen such as password fields or buttons. If a “punch” touches something that does not belong to our application, we will get a security exception as we are not permitted to “touch” another application without permission. This exception indicates something is on top of our application (i.e., an overlay).
In the picture below, we can see a login screen where window punching is being applied across the whole screen and at the password field area. The reaction can be configured differently depending on when the check triggers.
Window punching in action
Preventing activity injection
Similar to overlays, malware can also rely on accessibility services capabilities to inject an activity just at the right moment - for example, when a target application is observed on the screen of an infected device. These injections are usually designed to be remarkably indistinguishable from the original application, tricking users into unknowingly submitting sensitive data (e.g., login data, payment card data) to the attackers.
Attackers inject a deceiving WebView to trick users into submitting sensitive data
Window Punching to prevent activity injection
The good news is that window punching also works to detect activity injections. Unfortunately, unlike other attack methods where we can simply crash the application, activity injection is immune to this type of reaction from the app as attackers capture the sensitive data input in a WebView separate from the application. What we can do instead, is to warn users through notifications or toasts whenever an activity injection is detected. Going a step further, we can also react by returning the protected activity on top as soon as an activity injection is detected.
Attackers inject a deceiving WebView to trick users into submitting sensitive data
Preventing Screen Spying
Malware can spy on an infected device’s screen, camera, and microphone and stream all that content to the command-and-control server in real-time. Luckily, preventing screen captures is fairly easy to achieve using a fairly well-known and widely used method, FLAG_SECURE. However, in older Android versions, this method can still leave gaps allowing sensitive information to still be stolen by spying on the keyboard.
A financial application protects its screen contents with the secure flag, but its IME is unaffected and leaks the password ["How Android's UI security is undermined by accessibility", Kalysch et al.]
To mitigate this issue, we can set FLAG_SECURE on a dedicated keyboard in our application. By doing this, we can black out on any screen casting/recording whenever a keyboard appears on the screen. We can also apply this mitigation technique for specific views to cater to different use cases, by specifying the field identifier we want to protect. For instance, in the example below, only one of the password fields is protected.
FLAG_SECURE in action during screen recording
Conclusion
Malware is a complex problem with no one-size-fits-all solution and requires all stakeholders to play a role in addressing the malware problem. For instance, users should avoid downloading, installing, and using illegitimate shady applications, whether deliberate or not, and be more aware of how to keep themselves safe from malware. Furthermore, OS developers, such as Apple and Google, should provide secure APIs, while developers are responsible for identifying the APIs they need and understanding how to use them properly, tailoring them to the known risks they need to protect themselves against.
Lastly, developers must layer their protection with proper code obfuscation and runtime protection to ensure robust protection against malware. In one of our latest blogs, we discussed how a well-known Southeast Asian bank had its malware defenses circumvented due to the lack of static and dynamic attack protection, rendering its users vulnerable to further malware threats.
