The spread of malware from user PCs to handheld devices such as smartphones has been a gradual process that started gaining momentum about a decade ago. At first, relatively basic Trojans would focus on stealing SMS messages to compromise two-factor authentication (2FA) sent to users by their banks. Then, increasingly sophisticated malware started emerging in the wild with features that can take over the device, harvest data, control communications and even lock the user out, to name a few.

But while mobile malware used by financially motivated threat actors is indeed a lot more elaborate nowadays, infecting devices remains somewhat of a challenge. Embedded security controls typically prevent Android devices from running apps from third-party sources, and without the user activating side-loading, or worse yet, jailbreaking the device, infecting users at scale can be rather slow even for motivated attackers.

So how is it that we keep seeing mobile malware infection numbers rise and even skyrocket, with numbers breaking previous records almost every year? These numbers can be attributed in large part to infection campaigns that take place directly on the official app store, such as Google Play.

The first thought on anyone’s mind would be that official stores should be a trusted source and protected by controls to prevent the entry of malware, and that is true. What cybercriminals have been doing is using a workaround in the shape of mobile malware downloaders.

These are benign-looking apps that can very often be found on the official Google Play store. The loader app could seem like something useful users would want to get, or something enticing, offering some free videos or games, but it naturally has ulterior motives: After it is downloaded, it will usher in malware to the device by fetching and running it from the attacker’s server.

Fake Apps Downloaded Millions of Times

While campaigns do vary widely, fake app downloads reportedly can reach millions of users. The trust users have in official stores can push the download rate and amplify campaigns. For attackers, planting these fake apps in stores means exposure to a huge user base daily and a very cost-effective way to bank on the traffic that comes through the store.

A recent report indicates that just one malicious app on the Play store, a fake emoji keyboard app called ai.type, was installed by 40 million users. Worst of all, even though it was removed from the store, it’s still present on user devices, stealing information and making money for its operators via click-fraud and ad-related income. This sort of scale justifies taking a longer look at the cybercrime strategy that enables malicious content to get to official stores in the first place.

Early Stage in the Kill Chain

In the mobile malware kill chain, the role of malware downloaders begins in the early stage of the infection flow. They do not typically contain malware capabilities and are designed to “blend in” and look like legitimate apps in the Google Play store. They often entice relevant users to download them by looking like banking apps, foreign exchange calculators, free translation apps or other trending apps. Malware authors remain up to date regarding popular trends, they can fixate on region-specific trends, or aim to infect as many users as possible with malware that spreads persistent ads or click-fraud.

To appear like legitimate apps, these downloaders just prompt installation from the Play store app, and do not require any special permissions, like the request_install_packages permission. This permission is not very common but not considered to be alarming since legitimate apps also use it, making downloaders harder to detect as potentially malicious.

Figure 1: The typical mobile malware downloader infection flow (Source: X-Force Research)

Post-installation, evil downloaders in disguise will examine the device’s characteristics, then download and install malware from untrusted sources, thereby having a better chance of bypassing the security measures enforced both on the Play store and on the device.

In some cases, downloaders can be masked as a known popular app, and then ask the user to enable an “Update” download post-installation. This is when the user will unknowingly install two apps: a malicious app and the original app they intended to get — a scheme planned by the malware’s distributor to keep users from suspecting that something went wrong if they look for the real app later on.

Fetch and Deploy

Most downloaders do not feature a lot of functionality as they are used during the first stage of infection. Their purpose is to evade the detection of anything suspicious, so their feature list is kept to a bare minimum.

A common scenario is that apps that download and install a secondary APK from the internet fetch them from a server controlled by the attacker. This allows the malware’s developers the agility to version the malicious APK, modify or replace files, and infect users with different files all the time. This can also help them evade detection by static controls and antivirus or file blacklists.

A less common scenario is the Trojanized app technique. These types of downloaders have the malware embedded into their own APK, usually as an encrypted/packed blob to keep it concealed. Malware developers may choose this route to do some operational security because, this way, the downloader does not need to communicate with a command-and-control (C&C) server over the internet, requires fewer permissions and can still launch the malicious app without any connectivity. While not as agile as fetching files from the internet, this technique has its merits.

Downloader Campaigns

Downloaders can be very similar in terms of their inner workings. In the wild, we prefer to classify them by campaign. We define a campaign as a set of malware samples that target entities in a certain region or vertical, such as banks in the U.S., and use the same tactics, techniques and procedures (TTPs), including social engineering methods, C&C servers, codebases, etc.

Attributing samples to a wider campaign can help contribute to a broader understanding of the TTPs used by the perpetrators of the campaign and can also help hunt for new, present or future samples to be used by the same attackers.

While some downloaders are a commercial offering on the dark web and underground fraud-themed forums, others are private codebases that are not offered for sale to other actors in the mobile malware sphere. In the past, X-Force researchers looked into commercial campaigns that featured the Anubis malware infecting users via the Play store. But the ExoBot Trojan, which is a private distribution of Marcher, is used exclusively by its developers and their cybercrime faction.

Next, after fetching the malicious application that they were created to deliver, downloaders need to install it.

Common Malicious Install Pathways

Different malware developers may opt to use their own preferred tactics. According to X-Force research analysis, the most common installation tactics use the Android PackageManager API that can launch an install prompt.

Figure 2: The most common ways that malware apps get installed on Android devices (Source: X-Force Research)

Each method has its own merits and faults, and each is affected by Android security controls that are part of the user’s operating system version.

Using Android Package Manager APIs to Install Malware Apps

Using the PackageManager API to install applications is subject to the way that API works, to applicable permissions and to user consent. One of the factors that affects the ability to use the API is its version and the OS version of the target device.

For example, a minor change that separates API 23 and lower, and API level 24 and above: An update to the access level of files was introduced in version 24, forcing applications to use a file provider for accessing files rather than providing the absolute path.

These variations influence whether, and how, malicious apps can install the malware they fetch into the device.

Installing Apps

Described below are the two main code sequences for installing an application. The code regarding the APK installed from the external SD card uses the newer API, which requires a file provider and is already enforced for applications on the Google Play store.

Prompt installation from device path (API 24 and above):

Remember the update to the access level of files that was introduced in version 24 of the API? That update is a security layer that’s meant to offer a secure way to handle files between apps. It requires that apps use a component called the Android FileProvider to access world-readable files instead of providing an absolute path. Before this change, it was possible to send a file object and trigger the install intent; but starting with Android 7 (Nougat), the FileProvider requirement came into the picture.

A Redirect to Google Play

The second scenario we see quite often is when a malicious link that can’t install an app does not attempt to fetch malware from the internet; instead, it redirects the user to the Google Play store where they will be sent to the downloader app page.

Prompt Google Play installation:

Figure 3: Post-installation warning that redirects users to yet another suspicious app on Google Play (Source: X-Force Research)

The on-screen prompt in Turkish above translates to: “ERROR! Failed to install application! You’re being redirected to Google Play.”

Typical Downloader App Permissions

While app permissions are asked for and granted differently across mobile devices, Android-based operating systems will ask the user to grant permissions on installation. When it comes to downloaders, these apps ask for some repeated permission sets to enable them to later fetch and run malware.

One of the must-haves is the permission to install other applications:

• android.permission.REQUEST_INSTALL_PACKAGES

Other, very common permissions asked for are those that will enable the app to create persistence in case the user turns their device off and on again, to access the internet, or to save the APK:

• android.permission.INTERNET — Necessary for accessing external websites and for downloading a file from the internet
• android.permission.RECEIVE_BOOT_COMPLETED
• android.permission.WRITE_EXTERNAL_STORAGE — For saving the downloaded APK to the device’s SD card

REQUEST_INSTALL_PACKAGES

The permission REQUEST_INSTALL_PACKAGES is available from API Level 23 (Android 6.0 Marshmallow) and required from Level 26 (8.0.0 Oreo). Currently, applications published to the store must target Android 9, API version 28. It is therefore safe to say that all downloaders on the store will have this permission.

Please note that android.permission.INSTALL_PACKAGES is a permission that allows installing an APK without any interaction with the user, but this permission can only be used by system apps, and as such, it is out of the scope of threats described in this document.

WRITE_EXTERNAL_STORAGE & INTERNET

Per X-Force research observations of malware in the wild, downloaders will connect to the attacker’s server and download the malicious APK from there, then automatically save it to the Downloads folder on the SD card.

How to Mitigate Risk From Downloader Apps

Mitigating the potential installation of an app that might end up being a malicious intruder can be challenging because that initial app can look benign. There are still some ways to avoid these apps with some vigilance and app permission awareness, outlined here:

• Start by only downloading apps from official stores that vet the apps and check them before they are offered to the user base.
• Fake apps may look useful, but they are usually from unknown sources, feature low-grade design, faulty syntax and are likely smaller in size than other apps.
• Multiple apps that look alike are likely from the same campaign and should be avoided.
• There are millions of fake apps that try to impersonate reputable ones. If you are looking for a specific app, make sure it’s the correct one. You can usually get the right URL from a vendor’s/service provider’s official website.

Taking a closer look at the app’s developers can reveal if they are a legitimate source. If they have other apps, they are more likely to be real. If they don’t, and do not have a reputable website with scarce and generic user reviews, it could be wiser to look for another, better-vetted app.

Figures 4 and 5: Recently found downloader apps detected on Google Play (Source: X-Force Research)

Organizations can mitigate the risk to bring-your-own-device (BYOD) and work-issued devices by configuring app download parameters. A mobile device management (MDM) solution can also help with that task. To detect apps that have already been downloaded, organizations can look at blacklisted malicious apps or get help from a service provider to detect suspicious and malware-laden apps on user devices.

Educating users can be another useful layer of security against any cyberthreat, and malicious apps are no exception. Explain potentially malicious apps to your user base and enable them to understand app permissions that could be indicative of excessive access rights. Lastly, ask your users to never jailbreak or root their devices, whether they own the device or have a company-issued device.