How an Android application can drain your wallet
The Wireless Application Protocol billing (WAP Billing) is a payment mechanism that enables consumers to subscribe to paid services and get charged directly to their mobile phone bill. To initiate a subscription process the user has to navigate to a website that offers the service, while the device is registered to a cellular network, and click on a designated subscription button. As a verification step, a one-time password is sent to the user which has to be submitted back to the service provider in order to confirm the subscription.
Billing fraud is one of the most prevalent types of Android malware that leverages weaknesses in the aforementioned process in order to automatically subscribe the users to paid services. With revenue reaching up to $10 billion dollars annually, it monopolizes the media spotlight since it found its way to a wider audience through the Google Play Store back in 2017. Up to this day it is still among the Potential Harmful Applications (PHA) with the highest install rate according to Google Play’s transparency report.
This paper focuses on Toll Fraud, a Billing Fraud subcategory and tries to shed some light on its behavioral model from a solid technical perspective. More specifically, we are investigating the evasion techniques used and the actions taken from the malware’s side in order to imitate the user and perform a fraudulent subscription. Finally, we propose improvements with regard to Antivirus detection as well as improvements to the operating system level in order to mitigate the issue.
Billing fraud is one of the most prevalent types of Android malware. With revenue reaching up to $10 billion dollars annually, it monopolizes the media spotlight since it found its way to a wider audience through the Google Play Store back in 2017. Up to this day it is still among the Potential Harmful Applications (PHA) with the highest install rate according to Google Play’s transparency report.
This paper discusses Toll Fraud, a Billing Fraud subcategory (besides SMS and Call Fraud) and tries to shed some light on its behavioral model from a solid technical perspective. Although Toll Fraud includes any type of billing except premium SMS and premium calls, we are focusing on the Wireless Application Protocol (WAP) billing and how this mechanism can be exploited from malicious actors at the expense of the mobile end user.
The WAP Billing Mechanism
WAP billing is a payment mechanism that enables consumers to buy content from sites that support this protocol and get charged directly to their mobile phone bill. The subscription process starts with the customer initiating a session with the service provider over a cellular network and navigating to the website which provides the paid service. As a second step the user has to click on a subscription button and in some cases receives an OTP that has to send back to the service provider in order to verify the subscription.
We define as fraudulent a subscription that takes place without the user’s consent. More specifically, a toll fraud application will perform the subscription on behalf of the user in a way that the overall process won’t be perceivable, and to do that the following steps are required:
- Disable the Wi-Fi connection or wait for user to switch to a mobile network
- Silently navigate to the subscription page
- Auto-Click the subscription button
- Intercept the OTP (if applicable)
- Send the OTP to the service provider (if applicable)
- Cancel the SMS notifications (if applicable)
One significant and permissionless inspection, before performing these steps, is to identify the subscriber’s country and mobile network. The Mobile Country Codes (MCC) and Mobile Network Codes (MNC) can be used to provide this information and they can be fetched by using either the TelephonyManager or the SystemProperties class. The TelephonyManager.getSimOperator() API call returns the MCC+MNC as a concatenated string while other functions of the same class can be used to retrieve various information about the mobile network that the device is currently subscribed to. As the Network and SIM operator may differ (e.g., in roaming), the getSimOperator function is usually preferred.
The same type of information can be fetched by using the SystemProperties.get(String key) function where the key parameter may be one or many (using multiple calls) of the following strings:
gsm.operator.numeric, gsm.sim.operator.numeric, gsm.operator.iso-country, gsm.sim.operator.iso-country, gsm.operator.alpha, gsm.sim.operator.alpha
The difference with the first call is that the android.os.SystemProperties class is marked as @SystemApi, therefore it can’t only be invoked using reflection. The MNC+MCC is also used as a cloaking (hiding / evasion) mechanism, as the malicious behavior won’t be unleashed unless the SIM operator belongs to the ones targeted.
What follows is an analysis of the fraudulent subscription steps in the context of the Android Operating System, in order to identify the API (Application Programming Interfaces) calls and the permissions needed for their implementation.
Forcing Cellular Communications
Prior to Android 10 (SDK 29), disabling the Wi-Fi was possible by invoking the WifiManager’s setWifiEnabled function. The permissions needed for this call are the ACCESS_WIFI_STATE and CHANGE_WIFI_STATE and since their protection level is set to normal, they are automatically approved by the system. Toll Fraud applications that target a higher SDK started using ConnectivityManager’s requestNetwork function.
According to the Android Developers page:
This method will attempt to find the best network that matches the given NetworkRequest, and to bring up one that does if none currently satisfies the criteria. The platform will evaluate which network is the best at its own discretion. Throughput, latency, cost per byte, policy, user preference and other considerations may be factored in the decision of what is considered the best network.
|The required permission for this call is either CHANGE_NETWORK_STATE (protection level: normal) or WRITE_SETTINGS (protection level: signature||preinstalled||appop||pre23), but since the latter is protected the first is usually preferred. A NetworkCallback will be used to monitor the network status and retrieve a Network type variable that can be used to bind the process to the particular network via the ConnectivityManager.bindProcessToNetwork function. This will allow the malware to use the Mobile network even when there is an existing Wi-Fi connection.|
Fetch and Subscribe
OTP (one-time passwords) Handling
In most cases, an extra step is required for a subscription to be valid. The service provider sends a one-time password that must be sent back to the server to complete the process. As the OTP can be sent either by using the HTTP/USSD protocol or an SMS message, the malware must be capable of intercepting these types of communication. For the HTTP protocol the server’s reply must be parsed to extract the token while for the USSD, the only way to be intercepted is by using the accessibility service. To intercept an SMS message the application needs first to get notified about it which requires the android.permission.RECEIVE_SMS permission.
Another way of intercepting SMS messages is to extend the NotificationListenerService. This service receives calls from the system when new notifications are posted or removed including the ones sent from the system’s default SMS application. Finally, besides the Broadcast receiver and the Notification Listener a ContentObserver can be used to receive callbacks for changes to specific content.
Since API level 18, an application that extends the NotificationListenerService is authorized to suppress notifications triggered from other applications. The relevant API calls are:
- cancelAllNotifications() to inform the notification manager to dismiss all notifications
- cancelNotification(String key) to inform the notification manager to dismiss a single notification
- cancelNotifications(String  keys) to inform the notification manager to dismiss multiple notifications at once
This API subset is abused by the malware developers to suppress the service subscription notification messages posted by the default SMS application. More specifically, upon successful subscription the Service provider sends a message to the user to inform about the charging and gives the option to unsubscribe. By having access to the notification listener service, the malware can call any of the functions mentioned above in order to remove the notification.
Cloaking refers to a set of techniques used to hide a malicious behavior. Regarding billing fraud applications, most of them won’t take any action if the Mobile Network is not targeted. Additionally, the malicious code is in most cases downloaded and executed using dynamic code loading.
Mitigating the threat
Looking back to what has been discussed so far it is obvious that the conventional mitigation techniques based on static detection of malware code patterns can only offer temporary remediation due to the extended use of encryption, compression, obfuscation and steganography. Additionally, the usage of Java reflection eliminates the requirement to directly reference system API functions which lessens even more the value of a static approach.
There are though characteristics that come as a result of mass infection and cloaking strategies that the malware developers tend to follow. We can classify these characteristics as primary and secondary, with the first to be (among others) the requested permissions and the used API functions and the second the application’s category, the developer’s profile, the user comments etc.
Regarding the usefulness of the secondary characteristics, this occurs from the fact that since this malware category uses the Google Play Store as its means of spreading, the malware developers are trying to find ways to infect as many devices as possible on a brief amount of time while remaining published as long as they can. To achieve that, they use specific patterns that inevitably produce the aforementioned characteristics. For example, a strategy which is commonly used includes the following steps:
- Use of open-source applications that belong to popular categories and can be trojanized with a minimum of effort. The preferred categories are personalization (wallpapers, lock screens etc.), beauty, editors, communications (messaging, chat etc.), photography and tools (cleaners, fake AVs etc.).
- Upload clean versions, until the application gets a sufficient number of installs.
- Separate the malicious flow from the uploaded application in order to remain undetected for as long as possible.
The applications that have been uploaded in the context of this strategy can easily be traced as they all share some common characteristics:
- Excessive set of permissions which is not apt to the application’s usage (e.g., wallpapers, editors and camera apps that bind the notification listener or ask for SMS permissions).
- Common user interface characteristics (icons, policy pages, buttons etc.).
- Similar package names.
- Suspicious developer profile (name, email address).
- User complaints.
Regarding the primary characteristics, the requested permissions may include:
READ_SMS, RECEIVE_SMS, SEND_SMS, BIND_NOTIFICATION_LISTENER_SERVICE, CHANGE_WIFI_STATE, ACCESS_WIFI_STATE, CHANGE_NETWORK_STATE, INTERNET
Similarly, the most common API calls include:
setWifiEnabled, requestNetwork, setProccessDefaultnetwork, bindProcessToNetwork, getSimOperator and cancelAllNotifications.
The restricted set of information that an application can request for another imposes serious limitations on the actions that can be taken using on-device inspection capabilities. These actions may include:
- Instant or on-demand scanning based on signatures that cover known generic patterns of this type of samples.
- FileQuery requests and Telemetry based on conditions related to primary and secondary signals.
- Monitoring the HTTP Communications using a VPN Implementation.
Further than that, considering that each app can only access its own file system as well as the external directory (after getting the relevant permissions), any file that the malware drops in its data folder is not accessible by the client. Additionally, the memory mapped for each application during the runtime is also not accessible, thus in-memory scanning is also not an option. This being said, a more comprehensive approach would require a fully controlled cloud environment.
We saw so far that it is possible to narrow down the search scope by filtering out applications based on their secondary characteristics. Under a fully controlled environment (where the Android OS system limitations don’t apply) the prospect of a reliable detection increases dramatically.
A generic detection strategy may include the following steps:
- Parsing of the Android manifest in order to identify the requested permissions.
This will filter out those applications that are not able to complete the subscription steps described in the previous paragraphs.
- Use of dynamic instrumentation techniques in order to intercept commonly abused API calls and alter, if needed, their returned values.
With the perspective of triggering a malicious behavior, functions that are often used by this family to perform a device or mobile network reconnaissance may be altered accordingly (root detection, MNC MCC etc.).
- Dumping of the application’s memory space.
As part of detaching the malicious flow from the main application the malware uses dynamic code loading to execute payloads which are either embedded in the APK or downloaded from a command-and-control server, thus obtaining a full memory dump is a critical part of the detection process.
- Intercepting the HTTP communication.
Additionally, based on given filequery information, cloud can leverage a pre-determined verdict on the same sample or similar variants or prepare a verdict by rescan samples with some dynamic instrumentation features. Four important dynamic instrumentation or behavior monitoring features can be as follows:
- Trace file creation, owner process of file creation and mark them similar “mark of the web” if the file is downloaded from a URL.
- Trace file creation, owner process of file creation and mark them if the output file is from decryption.
- Monitor execution of System.load() or System.loadLibrary() with files with mark of web flag or with files with mark of encryption.
- Monitor invocation of DexClassLoader.loadClass with files with mark of web flag or with files with mark of encryption or decryption.
Android API restrictions
Security measures are evolving in order to follow the newest privacy norms and requirements in a rapidly changing mobile ecosystem, thus on a frequent basis those measures are being reviewed, redesigned or even written from scratch. Undoubtedly, Google put a lot of effort into improving the security of the Android API, considering that before API 23 dangerous permissions were silently approved by the operating system.
Regarding the under-investigation malware category, it was identified that most of the actions that lead to unwanted subscriptions are performed in a way that is not transparent to the user. These actions include:
- Obtaining details about the SIM operator
- Loading web content which is not visible to the user
- Binding the process to a cellular network or altering the network state
- Reading and canceling SMS notifications
Certainly, most of the above are also used for legitimate purposes, which is a fact that must be considered when proposing restrictions. The last two actions though may be regulated with minimal usability impact, by simply notifying the user about the mobile network usage and defining an access scope to the notification listener service.
The Google Play Store Publish Policy
Perhaps the most effective and immediate remediation approach would be a revision of Google’s Play Store policy on matters related to requested permissions and dynamic code loading. Leveraging the user’s trust to Google, as the application distributor, all that the malware developers have to do is to find a way to convince the users to approve the set of permissions that fits their needs. It is of high importance to ensure that requests for binding privileged services, like the notification listener, fall into line with the application’s functionality.
Starting from November 3, 2021, Google requires the developers to complete a Permission Declaration Form if their app requests the use of high-risk or sensitive permissions. The goal is to restrict access to sensitive user or device data as well as let fall the risk of abusing high privilege services. The notification listener service has so far been excluded from this requirement, even though it provides access to a broader set of sensitive information, including messengers and incoming SMSs.
Toll fraud is one of the most prevalent types of Android malware in Google Play Store since 2017 where families like Joker and their variants made their first appearance. By silently navigating to websites offering premium services, this malware imitates the users’ actions in order to perform fraudulent subscriptions and charge them using the WAP billing protocol. Additionally, by using sophisticated evasion techniques it manages to evade detection and achieve a high number of installations before a single variant gets removed.
Detection wise, following a cloud-side approach, which combines static and dynamic analysis techniques, seems to be much more promising in regard to a client-side oriented solution, taking into consideration the Android OS security restrictions applied to the AV agents.
Proactively, we suggested minor changes to specific API calls as well as a revision of the Google Play Store’s publishing policy, to harden the exploitation of the WAP billing mechanism and narrow down the set of applications that will be able to request for relative permissions.