If you have not heard of this term yet, I guarantee you will in the months to come. The term is market spam. This is not a new term or an issue that affects one or two app stores; this is a systemic problem that impacts app stores at large, where spammers focus on getting around rules and the screening process with the goal of making a quick buck. The goal of most market spam, other than getting to a mass audience in the shortest time as possible, is a prolonged presence on a device. Regardless of usage, the staying effect will result in gains for the rouge publisher at some cost for the end user. The key point to note here is prolonged presence, which can be manifested in many ways: either a single app manages to stay on your device for an extended period of time or several apps from the same developer transit through a device as a result of suggestive download recommendations made. In essence this creates the same net effect of an extended stay the user would get from a single app. Without the extended stay part, the chances for a spammer to make any serious money are short lived.
To better understand the effects of the prolonged stay let’s look at an example of two incidents recently identified from two different publisher IDs. Both were published around the same date to Google Play (roughly June 23 or 24). The first, a traditional smash and grab malware, premium SMS Trojan is detected as Android.Dropdialer. The second, a pirated emulator and ROM combination, Trojanized with several AdSDKs, as well as additional functionalities to facilitate the prolonged effect described above, is detected as Android.Fakeapp.
Coincidentally, both apps are using the same popular theme as bait to lure downloads, thus making ideal examples of comparing old school malware to new paradigms. Before being revoked both apps reached download counts in the range of 50,000 to 100,000. Looking at who has the potential to earn more revenue, the dialer is the obvious choice, but this is not the case when taking the net effect into consideration. After installation, Android.Fakeapp would push a notification to download other apps from the same spammer causing the number of impacted devices to suddenly take on a new dimension.
A review of the past activities of the rouge spammer behind Android.Fakeapp shows that since mid-May this is the fifth attempt to push the same app using a new publisher ID every time, resulting in download counts reaching significantly high values in short time spans. Despite the fact the apps were immediately suspended on Google Play, our telemetry data has shown that the constant feed from the suggestive downloads has resulted in a steady, accumulative user base, or the prolonged effect.
A general breakdown of the Android.Fakeapp framework can be summed up as the following. 70 percent of the app code was devoted to a combination of multiple AdSDKs which remove or disregard any consent requirements from the respective AdSDK, as well as tagging on additional functionalities that facilitate suggestions of other apps to download and install. One of these takes up 10 percent as a notification module. Another 10 percent of the app code was devoted to a social spamming module. The core app, or what the user was attempting to install, was only 10 percent of the total code make up.
Symantec has been tracking quite a few of these cases this year. One such case, Android.Fakeapp, shows traces of incremental updates resulting from trial and error efforts where the publisher has made attempts to gauge for weaknesses in the screening process of the market being targeted. Apps that were able to fly under the radar and avoid triggering any initial detection mechanisms are released. The key point for spammers to be successful is to translate best practices into a pseudo framework as quickly as possible.
It should come as no surprise that several high profile threat families discovered last year such as Android.Rootcager or Droid Dreams are text book examples of market spammers at work. Typical practices include, not only using multiple apps, but also using multiple publisher IDs to spread the risk. Despite the fact that Android.Lightdd, the follow up to Android.Rootcager, was also distributed by spammers on Google Play, it did not gain as much notoriety as its predecessor. In many ways this threat was ahead of its time as it characterizes many of the traits that are trending with spammers, notably the decrease in the use of root exploits.
To be continued in Part 3.
Leave a reply