This the second post in a multi-part blog series about mobile malware aimed at mobile banking and fintech apps. In the previous post, I talked about the growing problem of mobile malware, and in particular how different types of malware families have been heavily targeting mobile banking apps, mobile wallets, and other apps that handle money.
In this post, I’ll discuss how mobile malware is programmed to monitor and learn from its environment, leveraging elements of the environment to adapt and change itself over time. In this way, mobile malware acquires new functionality and adapts itself, broadening its target attack surface to exploit app functions and behaviors it encounters as it interacts with different classes of apps. As a case in point, consider this report published by the United States Health and Human Services Department (HHS) in which they describe how several of the top mobile banking trojans, including variants from the Ursnif malware family, have undergone development upgrades and now target mobile healthcare apps as well. I will also discuss how mobile malware abuses Accessibility Services to gain excessive app permissions and from there harvest and steal the information the malware is after and create the damage the fraudster intended. (spoiler alert: this abuse is the common denominator for malware and RATs like Pegasus, Eventbot, BRATA and all other tools).
Mobile malware often targets and deceives mobile users in order to replicate and stay relevant. You see, malware, unlike a computer ‘virus’ doesn’t self-replicate. In other words, malware doesn’t make copies of itself and spread without something else interacting with it. Instead, malware relies on trickery, deceit, exploiting backdoors in order to fetch updates, and abusing system-level settings. By doing so, malware is constantly evolving into something else, usually in ways that allow its creators to gain a heightened level of control or intelligence about the target environment.
Malware writers often design mobile malware with the intent of using the target environment against the user or apps on the device, and the malware may behave in different ways depending on what it finds in the environment once it’s on the device. For example, the GINP banking Trojan pretended to be a COVID-19 contact tracing app at first, but it evolved into a mobile banking trojan, whose true intent was to coax victims into providing their bank card details.
When certain events were detected, the trojan would display a message about a search for COVID-19-infected individuals (as a disguise). When other events were detected, the trojan displayed a malicious window that prompted the victim to input their bank card details. This flexibility allows attackers to efficiently manipulate potential victims, adapting attacks to the situation as needed.
First, let’s understand how mobile malware gets installed on target devices in the first place.
How Mobile Malware Reaches Target Devices
Nobody wakes up in the morning and says ‘ok let’s go get some mobile malware on my device and let it pilfer my Cash App transactions’. Mobile malware writers know this, so they design malware that masquerades or hides inside other apps, or relies on trickery and social engineering in order to deceive users into installing it. Other times cyberthieves trick users into performing actions that open up channels for malware to enter later. A key point is that malware campaigns usually occur over extended periods of time. They usually include multiple interactions with users and blend multiple techniques and attack vectors. They are rarely one-time, ‘smash and grab’ operations.
1. Fake Apps and Clones
Cyber-criminals create clones of popular apps or entirely fake apps and embed hidden malware inside. In the case of clones, the attackers typically use popular apps that they know will get a lot of downloads from unsuspecting consumers. Recent examples include popular chat apps like WhatsApp, Instagram, WeChat, or productivity apps like MS Word, Adobe. The latter two apps were cloned as part of the very first version of EventBot mobile banking malware that targeted hundreds of banks in Europe. Fake apps are very commonly found on underground app stores like Cydia, Sileo or Up2Down. But you will also find fake apps ‘official’ public app stores, Google Play and Apple’s App Store, often bypassing Apple and Google’s security measures. The malware embedded inside the clone/fake apps may be programmed to lay dormant until it reaches a target device. In fact, today’s really advanced malware is often obfuscated, which helps it stay undetected for longer time periods.
2. Malware/Trojan Droppers
A dropper is a type of malware or Trojan that has been designed to “install” or “drop” some sort of malware to a target system. The malware code can be contained within the dropper in such a way as to avoid detection by virus scanners or the dropper may download the malware to the target machine once activated.
For example, the malware might silently run in the background and listen for interesting events (like a user performing a balance transfer using a mobile banking app). Or the malware might run a series of scans of the user’s device and operating system. Depending on what it finds, the malware may phone home to its C&C (command & control) server to receive an updated payload. That’s one of the ways an ordinary piece of malware gets upgraded to a mobile banking Trojan or RAT.
3. Drive-by Downloads
Drive-by downloads occur when a user installs something or performs an action without really understanding the implications of what they did. In the case of Android apps, Allow Unknown Sources is often a channel used by mobile malware creators and bot herders in order to get malware onto a user’s device. This is a user-enabled Android setting that allows the user to download and install any app or program from any source – trusted or untrusted. This feature gets exploited when users enable it and then forget to turn it off, and/or agree to ‘permission requests’ from apps without knowing if the app requesting the permission is trusted (such as ‘app installers’ that are often malware themselves).
4. Phishing and Smishing
Phishing and Smishing refer to techniques where users are tricked into clicking on links that contain malicious content. There are many different variants of these attacks, but they all follow the same basic plot. Interact with a user over a medium they trust and entice them to click on a link that looks desirable to them, or often the link might appear to come from a trusted source (someone in the victim’s network whose account was likely compromised). The link is, of course, malicious and either delivers malware directly (for example using an executable program or script), or redirects the user to a malicious proxy/server controlled by the attacker (a classic MitM attack). Here’s an example from my friend Dan, whose friend’s Facebook account was apparently hacked. He received the following message on his iPhone from what appeared to be his friend (I’ve blurred out his friend’s details).
When he clicked the link he was redirected to the following page. This is a fake copy of the Facebook login page, controlled by the attacker. Thankfully my friend didn’t fall for the bait. If he did, his account would have likely been taken over. Another reason attackers conduct redirects like this is to engage with the user and entice them to click on malicious content (such as in a s).
5. Code Injection and Hooking
Now that we’ve covered how malware reaches mobile devices, let’s explore what it does once it’s there.
Weaponizing and Scaling Mobile Malware
For fraudsters and malware creators, distributing malware is just the beginning, not the end goal. Malware is never static; it’s always changing, evolving, and adapting to its environment. There are many different ways fraudsters evolve malware over time, to deliver additional capabilities and to scale their malware campaigns. This is typically achieved by abusing normal application functionality or manipulating app functions in unintended ways – such as abusing accessibility features, or acquiring excessive app permissions and using those permissions against the user or app itself (for example, a calculator app that records voice or video).
Abusing Accessibility Services
Accessibility services are mobile operating settings that are designed to help users with disabilities (eg: screen readers, speech to text, touch events). Whenever a user engages a specific accessibility feature, the app receives ‘callbacks’ from the OS to deliver a usable experience to the person with the disability. Accessibility services run in the background and have elevated permissions, which makes them ripe for abuse. When abused, the callbacks can be intercepted and manipulated by attackers to perform different actions than what they are intended for. For example, they can be used to steal pin numbers, read SMS messages, or intercept access codes to bypass MFA and take control over bank accounts. Or they can be used as surveillance tools to monitor activity or harvest financial data.
The recently discovered BRATA malware is a great example of a remote access trojan that posed as an app security scanner on Google Play. In reality, it contained a backdoor that allowed attackers to monitor activity and take over entire devices and applications all by abusing Android accessibility features.
Here’s another example of how attackers abuse normal app functionality to deceive users into granting powerful permissions to malware (when the user thinks they are performing a different action). This article in 9to5 Google talks about how cyber-criminals trick users into enabling Android Accessibility Services to a remote control app called Team Viewer which the attacker uses to take control over the mobile user’s device remotely – Only now, the attacker has a higher level of administrative privileges thanks to Accessibility Services being enabled (this lets the attacker inject or intercept keys events, gestures, modify the user’s inputs, and much more).
Excessive App Permissions
As the name suggests, app permissions govern what a mobile app is allowed to do and access. This ranges from access to data stored on the mobile device, phone contacts, location, camera, microphone, and much more. Granting permission allows the app to use the feature. Malware is often programmed to trick mobile users into approving app permission requests for access to these functions or features. The malware then abuses the permission by using the feature in malicious ways.
For example, security researchers recently discovered a new malware variant hidden inside an app that pretended to be a ‘system update’ app. The app acquired a wide range of permissions to access the user’s data, contacts, clipboard, search history, as well as camera, microphone, and GPS. It abused those permissions to steal users’ private data, messages, and clipboard history, as well as conduct surveillance on users without them knowing. The malware communicated with a remote Firebase server which the operator used to exfiltrate data, remotely control the app/device, and deliver automated malware updates, effectively upgrading the malware to official Remote Access Trojan (RAT) status.
Another infamous RAT is Pegasus. Like every other RAT, it tricked users into granting it excessive app permissions, which gave it the capability of reading text messages, tracking calls, collecting passwords, location tracking, accessing the target device’s microphone and camera, and harvesting information from apps. Pegasus has also been used by oppressive governments to monitor journalists and activists.
Advice to Mobile App Developers
You can’t protect your users from social engineering attacks where they download malware and then are tricked into granting this malware excessive app permissions. What you can protect your users against, is this malware from attacking your app. Since all these malware tools abuse accessibility services, Appdome allows you to build your app to prevent abuse of Android AccessibilityService. As a result, if your Appdome-secured app detects an app with excessive app permissions, your Appdome-secured app will no longer be able to run on the infected device. The next time your customer tries to open your app, they will get a notification that their device has been infected with malware and your app will exit.
To learn how to combat mobile malware and take specific measures to protect your mobile apps against malware and prevent mobile fraud, stay tuned for the next blog in the series, where I’ll discuss what you can do today to build mobile apps that are capable of preventing mobile fraud before it starts.
Want to see Appdome’s mobile malware prevention solution in action, request a demo today!