Android trojan drops in, despite Google’s Bouncer

Share this…

We at ESET recently discovered an interesting stealth attack on Android users, an app that is a regular game but with one interesting addition: the application was bundled with another application with the name systemdata or resourcea and that’s certainly a bit fishy. Why would a regular game downloaded from the official Google Play store come with another application named systemdata? This particular application/game from Google Play Store is certainly not a system application, as the name seems intended to suggest.

The packaged application is dropped silently onto the device but has to ask the user to actually install it. The app requesting the installation is passed off as a ‘Manage Settings’ app. After installation, the application runs in the background as service.

ESET detects the games that install the Trojan as Android/TrojanDropper.Mapin and the Trojan itself as Android/Mapin. According to our telemetry, Android users in India are currently the most affected, with 73.58 percent of these detections observed.

It’s the backdoor Trojan that takes control of your device and makes it part of a botnet under the attacker’s control. The Trojan sets timers that delay the execution of the malicious payload. This is to make it less obvious that the trojanised game is responsible for the suspicious behavior. In some variants of this infiltration, at least three days must elapse before the malware achieves full Trojan functionality. It’s probably this delay that enabled the TrojanDownloader to get past Google’s Bouncer malware prevention system.

After that, the Trojan requests device administrator rights and starts to communicate with its remote C&C server. Android/Mapin contains multiple functionalities, such as pushing various notifications, downloading, installing and launching applications, and obtaining the user’s private information, but its main purpose appears to be to display fullscreen advertisements on the infected device.

Distribution vectors: Google Play & Co.

The most interesting thing about this Android Trojan is that it was available for download from the official Google Play Store by the end of 2013 and 2014 as Hill climb racing the game, Plants vs zombies 2, Subway suffers, Traffic Racer, Temple Run 2 Zombies, and Super Hero Adventure by the developers TopGame24h, TopGameHit and SHSH. The malware was uploaded to Google Play on November 24-30, 2013 and November 22, 2014.

According to MIXRANK, Plants vs zombies 2 had over 10,000 downloads before it was pulled. On the same dates System optimizer, Zombie Tsunami, tom cat talk, Super Hero adventure, Classic brick game and the applications mentioned earlier from Google Play Store, packaged with same backdoor, were uploaded to several alternative Android markets by the same developers.

The same backdoor was also found packed with other applications uploaded by the developerPRStudio (not prStudio) on alternative Android markets with some of them referencing to the official Google Play Store. This developer uploaded at least five other Trojanized applications: Candy crush or Jewel crush, Racing rivals, Super maria journey, Zombie highway killer, Plants vs Zombies to various third-party Android markets. All these infected games are still available for download from these markets. The infected applications have been downloaded thousands of times.

Figure 1: Infected applications
Figure 1: Infected applications

Android trojan drops in, despite Google’s Bouncer

Figure 2: Application gets positive feedback
Figure 2: Application gets positive feedback

 

Infection: Victims are asked to install the malware 24 hours after execution

There are variations in the way this malware is launched. A Trojan is dropped and the victim is asked to install it 24 hours after first execution of downloaded application. This method seems less suspicious to the user and makes him believe that the request to install an application comes from the operating system. Other Trojan versions don’t wait 24 hours but start immediately. All variants are triggered after connectivity is changed, when a broadcast receiver is registered in the manifest.

Figure 3: Connectivity changed receiver
Figure 3: Connectivity changed receiver

When the connection is changed, the user is prompted to install the ‘system application’. The dropped malware pretends to be Google Play Update or Manage Settings.

Figure 4: Install requests by trojan
Figure 4: Install requests by trojan

If the user chooses to cancel rather than install, then he or she will be prompted again to install every time the connection is changed. The average user will be convinced that this is some important update and at some point is likely to install it just to get rid of this notification. After that, the Trojan starts a service with its own registered broadcast receiver, waiting for another connection change.

When a connection occurs, the malware tries to register itself with Google Cloud Messages (GCM) servers before the malware can receive messages. After GCM registration Android/Mapin will register the infected device on its own server sending user name, Google account, IMEI, registration ID and its own package name.

Figure 5: Device registering to attacker’s server
Figure 5: Device registering to attacker’s server

To keep itself from being uninstalled, the Trojan demands that the user activate the ‘device administrator’:

Figure 6: Device administrator
Figure 6: Device administrator

The Trojan will notify the remote server as to whether the device admin activation was successful or not. Subsequently the user gets a full screen (interstitial) ad popped up. This interstitial ad will be displayed each time connectivity changes. Those ads are delivered by misusing the legitimate AdMob SDK.

Figure 7: Interstitial ads
Figure 7: Interstitial ads

Communication through Google Cloud Messaging

The Trojan communicates with the server using Google Cloud Messaging (GCM). Such communication is getting more and more common in malware these days. The backdoor can respond to commands received from the server.

Figure 8: Commands
Figure 8: Commands

Not all of its functionality has been fully implemented, and some of the functionality that isimplemented isn’t used. There is a possibility that this threat is still under development and the Trojan may be improved in the future. Its main purpose, controlled from the remote server, is to deliver aggressive advertisements to the end user while pretending to be a system application.

It can also deliver another malicious program to the user’s device. It can enable or disable interstitial or banner ads, change the publisher ID for displayed ads, choose whether or not to display ads to the user, change the delay time between ads being shown, install, download and launch applications, push notifications, revoke device admin rights, change the server with which the malware communicates, and create shortcuts on the home screen to URLs that install downloaded applications. After executing each task, received using GCM, the client device will inform the remote server over HTTPS that its task has been successfully completed.

Conclusion

The Trojan was successfully uploaded to the Google Play Store, probably because Bouncer hadn’t implemented all the relevant malware triggers, in this case for emulating a change of network connectivity. Another interesting question is why Bouncer didn’t statically analyze the executable file inside the assets of the uploaded game. For that reason, the Trojan stayed undetected and was freely provided to users. The infected game “Super Hero adventure” was uploaded to the Play Store by the developer “SHSH”. It’s possible that more applications from this developer were uploaded to the official Google store. The Trojans were eventually pulled from the Google Play store, but were undetected for nearly a year and a half. Perhaps because of this and similar cases, Google announced that as of March 2015, all apps and updates must pass human review.

Best practice for avoiding the download of malware from the official store is to download applications from trustworthy developers and to read comments from people who are already using them. And also to consider whether the permissions that an app expects when it requests installation are justified. If something suspicious happens, consider supplying a sample to your antivirus vendor for analysis, along with your reasons for submitting.

Source:https://www.welivesecurity.com/