blog.zimperium.com Zimperium’s core machine learning engine, z9, has a proven track record of detecting zero-day exploits. We recently announced an extension of the framework that detects previously unknown mobile malware. This extension is known as “z9 for Mobile Malware”, and was officially announced in September 2017. Internally, the code name has been “Cogito”, so this research blog will use that name throughout.

On a pool of approximately 1800 samples collected from the Play Store1, Cogito detected two of them as malicious in a matter of seconds. This post outlines the process our team took to validate Cogito’s behavioral detection of the two malicious apps.

Checking the behavioural information extracted by Cogito we noticed that those samples are really aggressive on Ad displaying. In fact, fullscreen Ads are displayed each time:

• An application is installed, updated or uninstalled;
• A flag on Accessibility Services is triggered;
• The screen is unlocked;
• The user navigates from a page to another of the application.

One of the two applications also contained really suspicious code to auto-click Ads issued by Facebook.

Applications metadata

The updated application information was the following (right before being removed by Google):

Application Name: Phone Cleaner Dev
Package Name: com.life.read.physical.trian
Play Store Link: (removed from Play) play.google.com/store/apps/details?id=com.life.read.physical.trian
Download Count: 10.000-50.000
Developer Email: [email protected]
Privacy Link: https://dxirlpbjoseri.cloudfront.net/products/h6skoorpc/privacy.html

Application Name: Best Junk Clean
Package Name: core.clean.com.scanningapp
Play Store Link:(removed from Play) play.google.com/store/apps/details?id=core.clean.com.scanningapp
Download Count: 100.000-500.000
Developer Email: [email protected]
Privacy Link: https://d2c1shkqljaenk.cloudfront.net/products/xhaj052dn/privacy.html

What caught our attention were the developers emails and the privacy links. At first sight, the two applications appear to be uploaded by different developers, with different email addresses and with different privacy links.

Investigation start

A proper investigation of the com.life.read.physical.trian package revealed code designed to trick the Facebook Ads SDK and generate fake clicks on the advertisements spawned by the application. At the time of the initial analysis (September 4 2017), the Facebook Ads IDs used by the application were already revoked because, during the fetching phase of the Ads, a “No fill” response was generated by the server.

The code used to generate clicks on the advertisements is really simple and consists of using the MotionEvent API to create a fake touch event with random coordinates in the Ads box and with a random click time. The touch event is then dispatched to the Ads view using the dispatchTouchEvent() method. Our team produced a little PoC to show that the technique can be developed further to generate a fake touch event almost similar to a real touch event generated by the user touching the screen.

During the analysis of the core.clean.com.scanningapp package, a method to display the “Privacy Policy” to the user was referencing the same privacy link present in the Google Play Store page. So we decided to take a look into it, mostly because something about the shape of the email and the link were suspicious.

After a quick check of the privacy links from the two applications, some things were clear:

• the file listing of the CloudFront URL from the privacy link found in the core.clean.com.scanningapp package is revealing the presence of some interesting files and folders distributed by the CDN (e.g. Ad/, Ad/su.apk, Ad/404_c.txt, etc.);
• both URLs are showing the same files and folders structure, hinting that although the Play Store is showing two different developers, the applications somehow rely on the same CDN for fetching the privacy policy document.

Investigation of the CDN & discovery of the Ztorg Ads Plugin

The full list of interesting files present in the CDN is the following:

• Ad/404_c.txt
• Ad/47001_0.txt
• Ad/ban.txt
• Ad/conf_ban.txt
• Ad/conf_lis.txt
• Ad/inner.txt
• Ad/ss.apk
• Ad/start_inner.txt
• Ad/su.apk

Other than the previously listed files there are other inaccessible files and folders related to logs (e.g. gplogs).

Let’s start with the Ad/ss.apk and Ad/su.apk files. The two files have the same size, but the hash is different. After a quick inspection of the ss.apk file, it was clear that part of it was encoded in some way; in fact, it wasn’t a valid APK file. Comparing the su.apk and ss.apk files byte by byte, it’s easy to see that only the first 2048 bytes of the ss.apk file are encoded. To be precise, a single-byte XOR encoding with key = 0xFF is applied to the first 2048 bytes of ss.apk. After decoding, we can see that ss.apk is equal to su.apk and the content is just a single classes.dex file. The code is slightly obfuscated with meaningless class/field names and encoded strings. After the analysis, we can see that the code implements Ads auto-clicking and Ads auto-subscription features; the implementation uses a 1×1 pixels WebView and employs the addJavascriptInterface(“android”) to register a bridge between Java and the Javascript code executed by the loaded URL.

The code relies on configuration downloaded from an URL which is not alive anymore: kmd.phaishey.com/ft/ and uses the IMSI of the phone to fetch the correct configuration file (e.g. MCC_c.txt, IMSI_0.txt or IMSI_1.txt). Looking at the list of interesting files distributed by the CDN, we noticed the 404_c.txt and the 47001_0.txt files. They are clearly the two configuration files requested by the code, but they are hosted on the CloudFront CDN (e.g. 47001 is the Bangladesh IMSI, 404 is the India MCC).

• 404_c.txt file contains the values for some variables used by the Java code;
• 47001_0.txt file contains a list of Base64 encoded subscription URLs and the respective Javascript code to automatise the subscription.

To recap, the code connects to a server to get the configuration files (using the IMSI, so probably the subscriptions are location based), and after spawning the WebView, the Javascript code is executed in loop to subscribe the user to the different offers fetched from the server. Given the fact that the su.apk only contains a classes.dex file, it’s clear that it is supposed to be loaded and executed at runtime by an application, so we classified the file as a plugin.

During the analysis we checked the configuration URL to understand why it was down and we noticed that KasperskyLab managed to find a piece of code connecting to the same domain (but different sub-domain): c.phaishey.com/ft/. The research2 shows really similar code to what we found (same use of IMSI, same C&C domain and similar auto-clicking code) and it’s clear the applications are related to each other.

Investigation continues

KasperskyLab researchers said that the code is related to the Ztorg campaign, and during the months, they noticed that several times Ztorg droppers have been available on the Play Store. So we decided to go further and understand if other infected applications have been uploaded and published.

Our investigation started where we left it: on the CDN and privacy links. In fact, searching Google with some specific queries gave us good results:

• intext:cloudfront.net/products/ intext:privacy.html intext:”Magic Browser”
• intext:cloudfront.net/products/ intext:privacy.html intext:”Noise Detector”

As expected, both applications analysed on previous researches have the privacy link pointing to the same CDN. The connection is now stronger and with little effort, we managed to find a lot more applications with the privacy link pointing to CloudFront. All the privacy policy documents share the same structure so we decided to check other places for something resembling it, and with some luck we found different github.io accounts hosting that same file (except the application name which obviously changes from app to app).

All the files are hosted on the same Amazon S3 bucket:

• all the privacy.html files: hxxps://pajhdf.s3.amazonaws.com/?prefix=products
• all the folders: hxxxps://pajhdf.s3.amazonaws.com/?delimiter=/

Unluckily, some interesting files and folders are not accessible (e.g. program, tmp), but all of the folders related to the privacy.html file are accessible and we had a way to collect all the packages relying on the CDN for the privacy link. With no surprise, both Magic Browser and Noise Detector are on the list.

At this point, we prepared some scripts to fetch all the possible packages from the Play Store, all of their information and we started to analyse them.

Analysis of the applications

We started to monitor the applications on the Play Store on a daily basis. Some of them are often updated, but most of the time the changes to the code are almost non-existent (e.g. only the application version or some variable name was changed). But monitoring the download count, we noticed high spikes of downloads in few days. Summing these weird spikes, the randomly generated emails of the developer and the strange link to the same CDN, it’s clear that something is off with every package part of this “network”.

As an example, during September 14th, the package com.well.bestlight, last updated on August 24th, had its downloads counter increased from 10.000-50.000 to 50.000-100.000 in a few hours despite the app is not usually in the top trending list, very suspicious.

The same happened to other non top trending packages of the same network:

In the previous months, Ztorg related applications used a simple trick to hide from the Play Store detection: a legit application is uploaded and updated with legit code for some time, then a malicious version is pushed and removed in a matter of hours; just the time needed to infect some devices.

Other than just collecting the packages being updated on the Play Store we managed to retrieve previous versions of the same packages and it was clear that sometime a legit application included malicious code. The investigation is still ongoing but three significative packages have been discovered available on the Play Store and containing potentially malicious code: com.funny.tzfe, com.hot.mini.goo.wwer.poer and com.optimizer.mybooster.

com.funny.tzfe

The com.funny.tzfe package contains a file named sql.data in the assets: it’s an encoded file (single-byte XOR with key = 0xF) referenced from the Java code. After decoding, it is dynamically loaded and executed by the application. The malicious code is a variant of the su.apk found on the CDN which uses the http://lmk.phaishey.com/ze/ URL to get the configurations. The code also contains what seems to be an anti-emulator trick, the following URL is contacted: a.erdfojrmfs.com. Using Cogito behavioral comparison, we can see how the su.apk and sql.data files share almost all of the same code:

Some APIs are different (as we can see from the green and red bars that respectively mean added and removed code) but the whole behavioural structure is kept between the two files; this is enough to say that both are connected, being Ztorg plugins.

com.hot.mini.goo.wwer.poer

The com.hot.mini.goo.wwer.poer package contains two files named custom1.text and custom2.text in the resources folder; both files are used to decode strings and resources. The code connects to a server, hxxp://customgo.aavhgoogr.com/homefile/, and downloads a file named customtext2.ttf which is then saved as customtext2.jar and unzipped. The obfuscated code also contains what seem to be anti-emulator checks, in particular the following domains are contacted: custom1.weiojiore.com and custom2.weiojiore.com. With the supposed C&C domain offline, we weren’t able to download the customtext2.ttf file for inspection.

com.optimizer.mybooster

On September 27th, the com.optimizer.mybooster package has been uploaded to the Play Store with some differences from the previous versions. In particular, two files (FastBoosterLite3.txt and OaceOaT8w5Xda6wa) has been added to the assets and one Java class has been injected. The FastBoosterLite3.txt file is not a text file but apparently it’s the “lite” version of the same package. The txt extension has probably been added as a weak form of extension hiding. While the OaceOaT8w5Xda6wa file is a GZip package, there is no reference about it in the Java code (nor in the native code), so it looked strange. After a quick search, it’s clear that the new injected Java code and the OaceOaT8w5Xda6wa file are part of the VirtualApp3 framework, which allows the developer to create a virtual space to install and run an APK on it. The injected Java code shows how the virtual space is created and that if the configuration file downloaded (from the following URL: hxxp://parl.kuxwmuzuz.com/app/fastbooter/conf.txt) by the application contains the option isStartVA set to 1, then the FastBoosterLite3.txt must be installed and executed. Given the amount of permissions requested by the package, if a malicious application is installed instead of FastBoosterLite3, than the game is done and this should be considered application sideloading.

As a side note, after extracting the OaceOaT8w5Xda6wa GZip file we got a binary file undetected by libmagic, but binwalk revealed the presence of ZIP headers at specific offsets. The file was a scrambled ZIP package, splitted in pieces and reassembled in the wrong order. Luckily, at the end of each scrambled block, a byte representing the original position has been appended. After fixing it with an hex editor, we got a fully working ZIP archive. The ZIP contains an obfuscated classes.dex file which apparently implements advertisements display logic for a Chinese company named Youmi. As said before, the file doesn’t seem to be referenced anywhere in the code so it’s probably unused and unrelated to the investigation.

Behavioral comparison of the monitored packages

Following the comparison done for the sql.data and su.apk files, we decided to behaviourally correlate all the packages collected during the monitoring. With no surprise, a lot of them had very similar results. In fact, during the analysis, we clearly saw the same structure adopted in different APKs (e.g. similar names, similar Java packages structures, similar assets or resources). The following is a comparison with some randomly picked packages in the set of the analysed applications:

As can be noted, the applications with the same behaviours are part of a specific color group; as the application name suggests the games are all alike one with the other, the same applies to photo applications and phone cleaners (although this latest group has been split in two because of the cleaning and boosting capabilities).
Overall, we have a set of applications which aggressively display Ads to the user, try to take advantage of the Accessibility Services and sometimes switch from legit applications to potentially unwanted ones, including new Java code, encoded assets and connecting to different URLs to download additional files or configurations (e.g. aavhgoogr.com, kuxwmuzuz.com, phaishey.com). Summing up the fake developer address, policy link, comments and ratings on the Play Store, the randomly generated name given to each package, the evidence of the same code in different APKs and the presence of real malicious applications (e.g. the two APKs reported by KasperskyLab and the packages we analysed) part of the same network, we can conclude that it’s likely that all the applications are from the same developer which uses this network of APKs to spread malicious code once an app got enough downloads.

Connections between the applications

Testing some of the applications on an emulator, we noticed that each of them contains a fake market (called “Ad market”) which shows a list of applications to be downloaded. Most of them are part of the list coming from the CDN, so once again there is a connection even if apparently each application is uploaded on the Play Store by a different developer account.

In the following videos, we can see how in the fake market there is a high frequency of connected applications, and the second video shows how an application takes advantage of the Accessibility Service power to identify and click on alert windows with an embedded “OK” button (e.g. this kind of capability has been found in different samples, particularly in the phone booster and cleaner ones).

Google & Facebook

During the investigation, we managed to get in contact both with the Google Play Protect and with the Facebook Traffic Quality and Fraud teams.

The Google Play Protect team confirmed the presence of Ads click fraud in a set of packages we sent as acknowledgment and proceeded to remove them from the Play Store:

Of all the packages we collected from the CDN, some have been removed from the Play Store before and during our analysis. Of the list of packages we were monitoring, the following are not accessible anymore:

• com.sweet.pop
• com.star.dota
• com.game.free.happyslots
• com.game.online.pops.beauty
• com.making.spell.photo
• com.editor.photodrawer
• cn.clear.master
• core.clean.com.scanningapp
• com.life.read.physical.trian
• com.tolat.sns.myphonecleaner
• com.fog.magic.mycleaner
• com.expect.blue.superoptimizerpro
• com.well.bestlight
• com.music.counter.pro
• com.hot.mini.goo.wwer.poer
• com.easy.blood.test.instrument
• com.media.player.all
• com.hjb.cool.gallery.color
• com.cherish.timerwallpaper
• com.art.editor
• com.kong.star.dota
• com.funny.tzfe
• com.kong.sweet.pop
• com.pop.music.green.manage
• com.myfaster.cooloptimizer.cooloptimizer
• com.music.x.player

The Facebook Traffic Quality and Fraud team instead confirmed that some of the packages we provided them were actually implementing auto-click tricks on Facebook Ads. They also confirmed that the Facebook Ads account behind several packages is the same, even if the Play Store developer account is different. This is the confirmation that somehow the developer behind the whole network is the same.

List of packages still alive on the Play Store:

• com.photo.optimize.master
• com.collage.pic.editor
• com.hot.fflmachine
• com.player.kmplayer
• com.heartful.heartfulpuzzle
• com.ocean3d.paper.dynamic
• com.jiubang.fastestflashlight
• com.pop.leisure.plan.user.love
• com.gray.timer.phonecleanerpro
• com.funny.check.blood.weapon
• mglobals.mobile.centernews
• com.pond3d.wall.paper
• com.plus.personality.master
• com.paper.exquisite.watch

Conclusion

Our manual validation confirmed Cogito’s behavioral detection of the two malicious apps.  From time to time, we will document other detection / validation examples that we feel that the mobile security community will benefit from understanding.

References

1. The downloaded APKs have been taken from the daily top chart generated by 42matters: https://42matters.com/docs/app-market-data/file-dump/top-google-charts
2. https://securelist.com/ztorg-from-rooting-to-sms/78775/
3. https://github.com/asLody/VirtualApp

Special thanks to zLabs researchers Matteo Favaro (@fvrmatteo), Simone Margaritelli (@evilsocket), Gianluca Braga (@Matrix86_), Nicolas Trippar (@ntrippar), Tamir Zahavi-Brunner (@tamir_zb), Rani Idan (@raniXCH), and Ziv Zeira for help in the process.

source : https://blog.zimperium.com/validating-machine-learning-detection-mobile-malware/#.WeYhMKMmbJs.linkedin