The Fine Line Between Ad and Adware: A Closer Look at the MDash SDK

Just last month, there were reports that Google removed three apps from its Play Store as they were discovered to be adware in disguise. At the time of the discovery, the apps were said to have been downloaded into millions of devices, based on data from the app stores. However, these were not the only apps with similar behavior. During their investigation in early March, our researchers believe that there were over 2,000 apps with similar behavior on Google Play. However, this number has decreased to the hundreds, if not fewer.

The Adware MDash

The adware, detected as ANDROIDOS_ADMDASH.HRX, is an SDK integrated into all of those apps. While it is sometimes called “MobiDash,” we will refer to this adware as “MDash” in this entry. What’s puzzling is that there isn’t any readily available information about this SDK that turned up in our research. It’s highly likely that the SDK was privately published—which is a stark contrast from famous adware vendors who often publish and facilitate the integration of their SDKs to earn as much as they can.

If the SDK was privately published, then how did it reach the app developers? It’s possible that it was distributed in underground forums.

A Look at MDash’s Code

To analyze MDash, we selected an app with the package com.zigzag.tvojdekor. It’s a Russian app that has since been removed from the Lifestyle category on Google Play. Examining the app, we found that the adware SDK MDash was carefully developed and well-maintained.

Figure 1. Sample app with MDash SDK

Figure 2. MDash SDK source structure

When the app is launched, a configuration file disguised in .PNG format is parsed:

Figure 3. Parsing a local configuration file (highlighted), which is disguised in PNG format

When we opened the file using a text editor program, we found that there is another remote configuration file, located on a domain registered to a Russian organization in St. Petersburg.

Figure 4. Opening the disguised configuration file reveals a URL

Figure 5. Remote configurations on a private host

The app initiates the adware SDK when two conditions are met: 1) the remote configuration has the keyword Pl3Sdk, and 2) its value is “true.”

Figure 6. Conditions set for MDash SDK

Figure 7. Default configurations on the remote private host shows that the conditions are always met

Presenting Ads After Screen Unlocks

During installation, this app sets configurations for a so-called “Overapp” ad, possibly installing shortcuts and a home page for the ad. According to the remote configuration details, the Overapp service will start only after 288,000 seconds (over three days) delay. The delay could be so as not to arouse any suspicion once the app is installed.

Figure 8. Initializing MDash SDK

Looking into the ad service DisplayCheckService in the code, we see that a broadcast receiver is registered to receive “SCREEN_OFF” events. During “SCREEN_OFF,” the service will request to the remote site to get ads. Once the user unlocks the phone, an ad will pop up.

Figure 9. Code showing the request to get ads

The service also sets up alarms to check and start itself every 15 minutes.

Ads Displayed

There are several types of ads supported by the SDK. But compared to other ad vendors, there are four distinct ad types in this SDK that deserve focus:

Alert – shows the ad in an alert dialogue box
Recommendation – presented as a recommendation by someone in the user’s contact list
Link – presents a pop-up message, that when clicked, opens the browser to display the ad
SDK – loads other popular ad SDKs to show ads

Figure 10. Sample “link” ad

Monitoring the ads being displayed, we found that they lead to unwanted apps, scams, and even malware. We found that one “update” was really adware, detected as ADW_ADGAZELLE. It’s worth noting that the malware affects computers, not mobile devices.

Figure 11. Other sample ads

Continuous Updates, Improvements

While examining other apps, we found that the MDash SDK is frequently updated, with new features being continuously developed

For example, the app “Winter Bunny – Joyfull DressUp” contains a version of the MDash SDK that contains code to make silent calls in the background, without any user consent. The number it calls is dynamically deployed from the remote server. The SDK contains code to delete the device’s call history to hide the suspicious activity.

Figure 12. This app can make calls without user consent

Figure 13. Code snippet of MDash SDK to make background calls

However, the app doesn’t request the necessary permissions to make the phone calls. This means that potentially fraudulent calls cannot occur.

We have also seen other versions of the MDash SDK search for and create a list of all the installed apps on an infected device. The information is then sent to a remote server, with the goal of deploying ads promoting similar apps.

Figure 14. Collecting information about installed apps

When Ads Turn into Adware

Analyzing the implementation of the SDK, we found that the routines of the SDK could be enabled or disabled from the remote configuration server. At the time of analysis, these routines were enabled by default in majority of the apps. But re-checking the remaining apps, we found that the backend ad server is currently not deploying ads.

Figure 15. Ad deployment was disabled

While this bit of news might seem like a relief for users, they shouldn’t rest easy. Even if the adware behavior is temporarily disabled, there is no guarantee that the developer will not suddenly activate or enable the behavior again. Regardless of the status, users are always at risk since the SDK can be found in their apps.

Of course, there are other checks that might prevent malicious or suspicious behavior from an app. For example, an app cannot make calls unless it contains the necessary permission (that was given by the user). However, this SDK shows that it can easily change from displaying ads to becoming adware by a simple change in the manifest file.

Looking at Developers

We extracted over 1,300 unique certificates signed to these apps. Based on the certification details, about a thousand of them are from Russian developers. Furthermore, about 1,100 certificates appear to have been filled with similar descriptions. The organization “TrueAndroid” seems to be a major contributor to the certificates. However, we cannot vouch for the veracity of the information found in these certificates. Developers can fill out the certificate information with random words as they see fit.

Of course, we cannot say for certain that these app developers also contributed to the development of the MDash SDK. However, we do know that they were able to acquire and integrate the said SDK to their apps, placing millions of users at risk of adware and other threats.

These kinds of SDKs are a good reason for developers to check SDKs before integrating them into their apps. Well-meaning app developers might find themselves earning the ire of the public if they unknowingly incorporated SDKs like MDash in their apps.

We advise users to download apps from known and trusted developers only. App stores do not always assume the responsibility of proactively checking for malicious or suspicious apps, so users should always take the initiative when it comes to protecting their devices. It pays to read reviews of apps to make sure they perform as intended. Reading reviews might help filter out apps that might have been overlooked during security checks. Lastly, users should have a security solution like Trend Micro Mobile Security installed in their mobile devices to detect and block potential threats.

With additional analysis by Kenny Ye.

We have notified Google about these affected apps. As of this writing, majority of the apps—including the Russian and “Winter Bunny – Joyfull DressUp” apps—have been removed from Google Play.

Hashes of the affected apps can be found in this document.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

The Fine Line Between Ad and Adware: A Closer Look at the MDash SDK