Ztorg: money for infecting your smartphone

This research started when we discovered an infected Pokémon GO guide in Google Play. It was there for several weeks and was downloaded more than 500,000 times. We detected the malware as Trojan.AndroidOS.Ztorg.ad. After some searching, I found some other similar infected apps that were being distributed from the Google Play Store. The first of them, called Privacy Lock, was uploaded to Google Play on 15 December 2016. It was one of the most popular Ztorg modifications, with more than 1 million installations.

After I started tracking these infected apps, two things struck me – how rapidly they became popular and the comments in the user review sections.

Popularity

These infected apps quickly became very popular, gaining thousands of new users each day!

For example, com.fluent.led.compass had 10,000–50,000 installations the day I found and reported it to Google.

However, it still wasn’t deleted from Google Play the next day and the number of installations increased tenfold to 100,000–500,000. It means there were at least 50,000 new infected users in the space of just one day.

Comments

There were lots of comments saying that people downloaded these apps for credits/coins/etc.

In some of these comments the users mentioned other apps – Appcoins, Advertapp, etc.

That’s where this latest research work started.

Advertising

Apps that pay users

The app mentioned most in the comments was Appcoins, so I installed it. After that, the app prompted me to install some other apps, including one that was malicious, for $0.05.

To be honest, I was surprised that only one was malicious – all the other apps were clean.

The funny thing is that they check for root rights on the device and don’t pay those that have them. And the first thing that Ztorg did on the device after infection started was to get superuser rights.

I contacted the Appcoins developers to try and find out where this malicious advertising offer came from, but they deleted the offer and answered me by saying there was no malware and that they had done nothing wrong.

Then I analyzed the apps installed by infected users and made a list of the most popular ones that paid users to install software:

mobi.appcoins

com.smarter.superpocket

com.moneyreward.fun

And of course they offered malware too:

All these offered users 0.04-0.05 USD for installing an app infected with Ztorg from Google Play.

Campaigns

So I decided to take a closer look at these offers and the dumped traffic for these apps.

A typical session in which an advertising app turned into a malicious one was as follows:

1. App receives offers, including malicious ones, from its server (for example, moneyrewardfun[.]com). Malicious offers are sent from well-known ad services (usually supersonicads.com and aptrk.com).
2. After a few redirections from ad service domains (in one case there were 27 redirections) the app goes to global.ymtracking.com or avazutracking.net. These URLs are related to the ads too.
3. Then it redirects to track.iappzone.net.
4. And the final URL that leads to the Google Play Store was app.adjust.com.

All the offers that I was able to dump had track.iappzone.net and app.adjust.com.

adjust.com is a well-known “business intelligence platform”; the URLs that are used in malicious campaigns look like this:

https://app.adjust.com/4f1lza?redirect=https://play.google.com/store/apps/details?id=com.game.puzzle.green&install_callback=http://track.iappzone.net…

By analyzing these URLs we can identify infected apps on Google Play.

Malicious server

URLs from iappzone.net look like this:

http://track.iappzone.net/click/click?offer_id=3479&aff_id=3475&campaign=115523_201|1002009&install_callback=http://track.supersonicads.com/api/v1/processCommissionsCallback.php?advertiserId=85671&password=540bafdb&dynamicParameter=dp5601581629793224906

This URL structure (offer_id=..&aff_id=..&campaign=..) is related to the OffersLook tracking system. It contains many interesting things, like offer id, affiliate id. But it turns out that cybercriminals use different values for them, making these parameters unusable for us. Except one – install_callback. This parameter contains the name of the ad service.

While searching for iappzone.net I was able to find some APK files that contained this URL. All of those files are detected by Kaspersky Lab products as Ztorg malware. The interesting thing was that iappzone.net used the IP 52.74.22.232. The same IP was used by aedxdrcb.com, which was mentioned in CheckPoint’s gooligan report. A few weeks after that report was made public, iappzone.net (which wasn’t mentioned in the report) was moved to a new IP – 139.162.57.41.

Ad modules

Luckily I was able to find iappzone.net not only in the APK files but also in network traffic from clean apps. All these apps had an advertising module – Batmobi or Mobvista in most cases. Network traffic from these ad modules looked similar to the network traffic from the apps that paid users to install promoted apps.

Here is an example of an app with a Batmobi ad module. The module received a JSON file with offers from their server api2.batmobil.net.

The user sees a list of advertised apps:

After the user clicks on the ads, they are redirected to the Google Play Store.

In this case, the redirects look like this:

api2.batmobil.net -> global.ymtracking.com->tracking.acekoala.com -> click.apprevolve.com ->track.iappzone.net ->app.adjust.com -> play.google.com

After analyzing ad campaigns containing iappzone.net, I was able to find almost 100 infected apps being promoted on Google Play.

The other interesting aspect of these campaigns was that their URLs contained the install_callback parameter that I mentioned earlier. Turns out the cybercriminals only used four ad networks.

Ad sources

track.iappzone.net callbacks

However, this doesn’t mean that malware was only being distributed through these four networks. These ad networks are selling their ads to a wide range of advertising companies. In my research, I saw some malicious ads coming from other advertising networks like DuAd or Batmobi, but after a few redirects these ads were always pointing to one of the four advertising networks listed above.

Furthermore, I tracked several malicious ad campaigns that looked like this:

Batmobi -> Yeahmobi-> SupersonicAds

which means that these networks also redistribute ads to each other.

I wasn’t able to find any other ad networks in the install_callback parameter until the end of March 2017.

Other sources

During my research I found some infected apps that were not promoted by these advertising networks. When I looked at their detection paths I found that there were several patterns to them. Most of the paths where these apps were detected (except the installation path /data/app) were as follows:

[sdcard]/.android/ceroa/play/

[sdcard]/.nativedroid/download/

[sdcard]/.sysAndroid/download/

[sdcard]/.googleplay_download/

[sdcard]/.walkfree/apks/583737491/

[sdcard]/Android/data/TF47HV2VFKD9/

[sdcard]/Android/Data/snowfoxcr/

[sdcard]/DownloadProvider/download/

I analyzed the apps using these paths and discovered that all of them are already detected by Kaspersky Lab products as adware or malware. However, the apps downloaded to these folders are not all malicious – most of them are clean.

* Malicious apps that were downloaded to a specific folder as a percentage of all apps in that folder.

Infected apps

Similar apps

All the infected apps that I analyzed surprised me in that they don’t look like they were patched with malware code. In many other cases, cybercriminals just add malicious code to clean apps, but not in this case. Looks like these apps were created especially for distributing malware.

Publishers from Google Play

Some of the publishers’ emails from Google Play:

When I started to search for them, I found that most of the emails are related to Vietnam.

For example:

1. trantienfariwuay -> tran tien [fariwuay] – Vietnamese singer
2. liemproduction08 -> liem production [08] – Thuat Liem Production, company from Ho Chi Minh City, Vietnam
3. nguyenthokanuvuong -> nguyen [thokanu] vuong – Vietnamese version of Chinese name Wang Yuan

Malicious modules

Almost all of the infected apps from Google Play contain the same functionality – to download and execute the main module. During this research, I found three types of modules with this functionality.

Dalvik

Every infected app from Google Play with this type of malicious module was protected by the packer. I will describe the app with the package name com.equalizer.goods.listener. It was packed using the Qihoo packer. This app has many different classes and only a few of them are related to the malicious module. Malicious code will be triggered by the PACKAGE_ADDED and PACKAGE_REMOVED system events. It means that malicious code only starts executing after the user installs/updates/removes an app.

As a first step, the malicious module will check if it’s running on a virtual machine, emulator or sandbox. To do so, it will check several dozen files that exist on different machines and several dozen values for different system properties. If this check is passed, the Trojan will start a new thread.

In this new thread the Trojan will wait a random amount of time, between an hour and an hour and a half. After waiting it will make a GET HTTP request to the C&C (em.kmnsof.com/only) and, as a result, the Trojan will receive a JSON file encrypted with DES. This JSON should contain a URL from which a file can be downloaded. The file is an ‘xorred’ JAR that contains the malicious classes.dex – the main module.

Native

Since October 2016 I’ve reported lots of apps with this malicious module to Google, so they were able to improve their detection system and catch almost all of them. This meant the cybercriminals had to bypass this detection. In the beginning they changed some methods in the code and used commercial packers. But in February 2017 they rewrote the entire code, moving all functionality to the ELF (native, .so) library.

Example: com.unit.conversion.use (MD5: 92B02BB80C1BC6A3CECC321478618D43)

The malicious code is triggered after app execution starts from the onCreate method.

The malicious code in the infected classes.dex is simple – it starts a new thread that loads the MyGame library and it has two methods for dealing with sandbox detections, which will be executed from the library.

In this version, the delays are much smaller than in the previous one – it waits only 82 seconds before execution.

After starting, the MyGame library will check if it’s running in a sandbox by executing the two methods from classes.dex. One will try to register the receiver for the BATTERY_CHANGED action and check if it’s correct. Another method will try to get application info about the com.android.vending package (Google Play Store) with the MATCH_UNINSTALLED_PACKAGES flag. If both of these methods return “false”, the malicious library will execute a GET request to the command server.

It receives: “BEgHSARIB0oESg4SEhZcSUkCCRFICAUSHwoLEhZIBQkLSQ4fSQ4fVlZVSQEWVlZVSAcWDUpeVg==”

The library will decode this answer and xor it with a 0x66 key.

Result:

b.a.b.a,b,http://dow.nctylmtp.com/hy/hy003/gp003.apk,80

g_class_name = b.a.b.a

g_method_name = b

g_url = http://dow.nctylmtp.com/hy/hy003/gp003.apk

g_key = 80

The .apk file available at g_url will be downloaded into the cache folder of the app folder (/data/data/<package_name>/cache). The library will xor it with g_key and load it using a ClassLoad method from the DexClassLoader class.

As we can see, the cybercriminals changed a lot in the malicious code, and replaced the Java code with C code. But the functionality remains the same – connect to the C&C, download and execute the main module.

Detection bypassing

Once I was able to receive the package IDs from these campaigns, I installed the infected app from Google Play on my test device and… nothing happened. After some investigating, I found that the cybercriminals only return a malicious payload to users that install apps via ads. However, some of the other infected apps started to infect my test phone when installed directly from Google Play – without clicking on any ads.

Dropper

In April 2017 the cybercriminals changed their Ztorg code again. In this third type of malicious module, the cybercriminals moved all the functionality back to classes.dex. The main difference with the previous version is that it’s no longer a Trojan-Downloader. It doesn’t download the main module from a malicious server; instead it contains an encrypted module in the Assets folder of the installation package. The file called info.data is xored with 0x12 and then loaded using the ClassLoad method.

Payload (main module)

In all the attacks that I analyzed the main module had the same functionality. I’ll describe one of the most recent – 2dac26e83b8be84b4a453664f68173dd. It was downloaded by the com.unit.conversion.use app using the malicious MyGame library.

This module is downloaded by the infection module and loaded using the ClassLoad method. The main purpose of the module is to gain root rights and install other modules. It does this by downloading or dropping some files.

Some files can only be dropped from this module; there are no URLs for them.

Some of the URLs with the down.118pai.com domain didn’t work at the time of this research. All files that have these URLs can be dropped. All files that have URLs only and cannot be dropped have URLs with the domains sololauncher.mobi and freeplayweb.com, which were accessible at the time of this research.

In one of the previous versions of the main module, dated September 2016, all the URLs had the down.118pai.com domain and were available at that time.

Some of the dropped/downloaded malicious files will be added to the /system/etc/install-recovery.sh file. It means that these files will remain on the device even after a reset to factory settings.

All files that are dropped and downloaded by this module can be divided into a few groups:

Clean files, tools

Exploits, exploit packs, exploit droppers

Most of these files will be downloaded by the Trojan, but some of them can only be dropped from the Trojan body. However, most of the downloaded files are the same as they were seven months ago in September 2016.

Native (ELF) malicious modules

All of these files can only be dropped from the Trojan’s body. They are not downloaded.

Malicious apps

.gmtgp.apk (7d7247b4a2a0e73aaf8cc1b5c6c08221)

This app is detected as Trojan.AndroidOS.Hiddad.c. It downloads (from the C&C http://api.ddongfg.com/pilot/api/) an additional encrypted module, decrypts and loads it. In my case it downloads Trojan-Clicker.AndroidOS.Gopl.a (af9a75232c83e251dd6ef9cb32c7e2ca).

Its C&C is http://g.ieuik.com/pilot/api/; additional domains are g.uikal.com and api.ddongfg.com.

The Trojan uses accessibility services to install (or even buy) apps from the Google Play Store.

It also downloads apps into the .googleplay_download directory on the SD card and installs them using accessibility services to click buttons. The folder .googleplay_download is one of the sources used to spread the Ztorg Trojan. It can click buttons that use one of 13 languages – English, Spanish, Arabic, Hindi, Indonesian, French, Persian, Russian, Portuguese, Thai, Vietnamese, Turkish and Malay.

dpl.apk (87030AE799E72994287C5B37F6675667)

This module contains the same methods to detect emulators, sandbox and virtual machines as in the original infected module.

It downloads an encrypted file from the C&C api.jigoolng.com/only/gp0303/12.html into the file /.androidsgqmdata/isgqm.jar. After decryption, the Trojan loads this file.

The main purpose of dpl.apk is to download and install apps. It receives commands from the following C&Cs:

• log.agoall.com/gkview/info/,
• active.agoall.com/gnview/api/,
• newuser.agoall.com/oversea_adjust_and_download_write_redis/api/download/,
• api.agoall.com/only/

The module downloads them into the DownloadProvider directory on the SD card. This folder is one of the sources used to distribute the Ztorg Trojan.

In my case, it downloaded five malicious APKs; four of them were installed and listed in the Installed apps section.

.gma.apk (6AAD1BAF679B42ADB55962CDB55FB28C)

This Trojan tries to download the additional isgqm.jar module with the main functionality in the same way as the other modules. Unfortunately, its C&Cs (a.gqkao.com/igq/api/, d.oddkc.com/igq/api/, 52.74.240.149/igq/api, api.jigoolng.com/only/) didn’t return any commands, so I don’t know the main purpose of this app.

This app can modify /system/etc/install-recovery.sh, and download files to the /.androidgp/ folder on the SD card. These files will be installed in the system folders (/system/app/ or /system/priv-app/).

I assume this Trojan is needed to update other modules.

.gmq.apk (93016a4a82205910df6d5f629a4466e9)

This Trojan wasn’t able to download its additional module isgq.jar from the C&Cs (a.apaol.com/igq/api, c.oddkc.com/igq/api, 52.74.240.149/igq/api).

Installed apps

The following apps were silently downloaded and installed on the device after infection. All of them have some well-known ad services.

They also have malicious modules that start downloading ads and apps when commanded by their C&C.

But using clean advertising networks like Mobvista and Batmobi creates an ad recursion, because these ads were used to distribute the original infected app.

A few new folders appear on the SD card after a successful infection. Among them:

• .googleplay_download
• .nativedroid
• .sysAndroid
• DownloadProvider

All of these folders were used by some of the malware to spread the initial Ztorg infection and were used after infection to distribute other apps – some of them malicious.

Other Trojans

Despite the fact that almost every Trojan from Google Play found during this research had one of the three malicious modules described in this research, there were also a few other Trojans.

One of them, called Money Converter (com.countrys.converter.currency, 55366B684CE62AB7954C74269868CD91), had been installed more than 10,000 times from Google Play. Its purpose is similar to that of the .gmtgp.apk module – it uses Accessibility Services to install apps from Google Play. Therefore, the Trojan can silently install and run promoted apps without any interaction with the user, even on updated devices where it cannot gain root rights.

It used the same command and control servers as .gmtgp.apk.

Conclusion

During the research period I found that Trojan.AndroidOS.Ztorg was uploaded to Google Play Store almost 100 times as different apps. The first of them was called Privacy Lock, had more than 1 million installations and was uploaded in mid-December 2015. Every month after I started tracking this Trojan in September 2016 I was able to find and report at least three new infected apps on Google Play. The most recent apps that I found were uploaded in April 2017, but I’m sure there will be more soon.

All of these apps were popular. Furthermore, their popularity grew very fast, with tens of thousands of new users sometimes being infected each day.

I found out that these Trojans were actively distributed through advertising networks. All these malicious campaigns contained the same URL, which allows me to easily track down any new infected apps.

I was surprised that these Trojans were distributed through apps that were paying users for installing promoted apps. It turned out that some users got paid a few US cents for infecting their device, though they didn’t know it was being infected.

Another interesting thing about the distribution of this Trojan is that after infection it used some of the advertising networks to show infected users ads about installing promoted apps. It creates a kind of ad recursion on infected devices – they become infected because of a malicious ad from an advertising network and after infection they see ads from the same advertising network because of the Trojan and its modules.

Cybercriminals were able to publish infected apps on Google Play because of the numerous techniques they used to bypass detection. They continued to develop and use new features in their Trojans all the time. This Trojan has modular architecture and it uses several modules with different functionality and each of them can be updated via the Internet. During infection Ztorg uses several local root exploit packs to gain root rights on a device. Using these rights allows the Trojan to achieve persistence on the device and deliver ads more aggressively.