Ztorg: money for infecting your smartphone
22.5.2017 Kaspersky Mobil
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
https://play.google.com/store/apps/details?id=mobi.appcoins
com.smarter.superpocket
https://play.google.com/store/apps/details?id=com.smarter.superpocket
com.moneyreward.fun
https://play.google.com/store/apps/details?id=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:
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).
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.
Then it redirects to track.iappzone.net.
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
Yeahmobi (global.ymtracking.com) 41%
Mobvista (next.mobvista.com) 34%
Avazu (postback.apx.avazutracking.net) 18%
Supersonicads (track.supersonicads.com) 7%
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.
Folder’s name Type Detection %*
DownloadProvider Malware 81%
TF47HV2VFKD9 Malware 56%
snowfoxcr AdWare 51%
nativedroid Malware 48%
.walkfree AdWare 33%
ceroa AdWare 20%
sysAndroid Malware 16%
.googleplay_download Malware 15%
* 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:
com.equalizer.goods.listener trantienfariwuay@gmail.com
com.ele.wall.papers nguyenduongsizang@gmail.com
com.game.free.plus.prefect liemproduction08@gmail.com
com.green.compass.star longhahoanghuong@gmail.com
com.voice.equalizer.musicssss baoanstudio@gmail.com
com.amusing.notes.done trunggapin@gmail.com
com.booster.ram.app.master.clean lakonmesminh@gmail.com
com.game.puzzle.green zentinlong@gmail.com
com.listen.music.pedometer tramhuyenthoai9a@gmail.com
com.live.paper.watch.analog nguyenthokanuvuong@gmail.com
When I started to search for them, I found that most of the emails are related to Vietnam.
For example:
trantienfariwuay -> tran tien [fariwuay] – Vietnamese singer
liemproduction08 -> liem production [08] – Thuat Liem Production, company from Ho Chi Minh City, Vietnam
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
File name Tool name MD5
data/files/.zog/.a chattr 9CAE8D66BE1103D737676DBE713B4E52
data/files/.zog/.a chattr 1E42373FA7B9339C6C0A2472665BF9D4
data/files/.zog/supolicy supolicy cdceafedf1b3c1d106567d9ff969327a
data/files/.zog/busybox busybox 3bc5b9386c192d77658d08fe7b8e704f
data/files/.zog/.j Patched su 8fb60d98bef73726d4794c2fc28cd900
Exploits, exploit packs, exploit droppers
File Name Name MD5 Detection name
data/files/.Ag/Agcr Agcr32 D484A52CFB0416CE5294BF1AC9346B96 Exploit.AndroidOS.Lotoor.bv
data/files/.Ag/Agcr Agcr64 B111DD21FD4FCEFDC8268327801E55CE Exploit.AndroidOS.Lotoor.bv
data/files/.zog/.ag/bx Bx 70EBFA94C958E6E6A7C6B8CD61B71054 Exploit.AndroidOS.Lotoor.bu
data/files/.zog/.ag/cx cx 892E033DA182C06794F2B295377B8A65 Exploit.AndroidOS.Lotoor.bu
data/files/.zog/exp exp 6E17234C57308012911C077A376538DC Exploit.AndroidOS.Lotoor.bz
data/files/.zog/.ag/nn.zip maink.apk/boy ab9202ccfdd31e685475ba895d1af351 script
data/files/.zog/.ag/nn.zip maink.apk/bx 70ebfa94c958e6e6a7c6b8cd61b71054 Exploit.AndroidOS.Lotoor.bu
data/files/.zog/.ag/ym ym32 F973BAA67B170AB52C4DF54623ECF8B3 Exploit.AndroidOS.Lotoor.bu
data/files/.zog/.ag/ym ym64 807A6CF3857012E41858A5EA8FBA1BEF Exploit.AndroidOS.Lotoor.bu
data/files/.zog/.aa mainp.apk/r1 c27e59f0f943cf7cc2020bda7efb442a Exploit.AndroidOS.Lotoor.bh
data/files/.zog/.aa mainp.apk/r2 368df668d4b62bdbb73218dd1f470828 Exploit.AndroidOS.Lotoor.bi
data/files/.zog/.aa mainp.apk/r3 fb8449d1142a796ab1c8c1b85c7f6569 Exploit.AndroidOS.Lotoor.bh
data/files/.zog/.aa mainp.apk/r4 04dd488783dffcfd0fa9bbac00dbf0f9 Exploit.Linux.Enoket.a
data/files/.zog/.ad mainmtk.apk b4b805dc90fa06c9c7e7cce3ab6cd252 Exploit.AndroidOS.Lotoor.bi
data/files/.zog/.ag/np np 1740ae0dc078ff44d9f229dccbd9bf61 Exploit.Linux.Enoket.a
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
File Name MD5 Path after infection Detection name
data/files/.zog/.am b30c193f98e83b7e6f086bba1e17a9ea /system/xbin/.gasys Backdoor.AndroidOS.Ztorg.j
data/files/.zog/.an 41ab20131f53cbb6a0fb69a143f8bc66 /system/lib/libgstdsys.so Backdoor.AndroidOS.Ztorg.j
data/files/.zog/.b ae822aed22666318c4e01c8bd88ca686 /system/xbin/.gap.a Backdoor.AndroidOS.Ztorg.c
data/files/.zog/.k 5289027ca9d4a4ed4663db445d8fc450 /system/bin/debuggerd Backdoor.AndroidOS.Ztorg.c
data/files/.zog/.m 5af47875666c9207110c17bc8627ce30 /system/bin/ddexe script
data/files/.zog/.c d335ac148f6414f0ce9c30ac63c20482 /system/xbin/.gap Backdoor.AndroidOS.Ztorg.c
All of these files can only be dropped from the Trojan’s body. They are not downloaded.
Malicious apps
File Name Name MD5 Path after infection Detection name
data/files/.zog/.l mains.apk 87030ae799e72994287c5b37f6675667 /system/priv-app/dpl.apk Trojan-Dropper.AndroidOS.Agent.cv
data/files/.zog/.o mains2.apk 93016a4a82205910df6d5f629a4466e9 /system/priv-app/.gmq.apk Trojan.AndroidOS.Boogr.gsh
data/files/.zog/.n mainm.apk 6aad1baf679b42adb55962cdb55fb28c /system/priv-app/.gma.apk Backdoor.AndroidOS.Ztorg.a
data/files/.zog/.al .al 7d7247b4a2a0e73aaf8cc1b5c6c08221 /system/priv-app/.gmtgp.apk Trojan.AndroidOS.Hiddad.c
.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.
Package Name Detection Md5 Ad modules
co.uhi.tadsafa Trojan-Downloader.AndroidOS.Rootnik.g d1ffea3d2157ede4dcc029fb2e1c3607 mobvista, batmobi
com.friend.booster Trojan.AndroidOS.Ztorg.bo 5c99758c8622339bffddb83af39b8685 mobvista, batmobi
sq.bnq.gkq Trojan-Downloader.AndroidOS.Rootnik.g 10272af66ab81ec359125628839986ae mobvista, batmobi
main.ele.com.blood Trojan.AndroidOS.Ztorg.bo 8572aec28df317cd840d837e73b2554a mobvista
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.