Validating Machine Learning Detection of Mobile Malware with Zimperium’s z9
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.
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@example.com
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: firstname.lastname@example.org
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.
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.
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.);
Investigation of the CDN & discovery of the Ztorg Ads Plugin
The full list of interesting files present in the CDN is the following:
Other than the previously listed files there are other inaccessible files and folders related to logs (e.g. gplogs).
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;
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.
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”
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:
|com.film.filmprojector||500-1,000 → 1,000-5,000|
|com.funny.check.blood.weapon||500-1,000 → 1,000-5,000|
|com.magic.campus.cubecleaner||500-1,000 → 1,000-5,000|
|com.realistic.realisticfishwallpaper||500-1,000 → 1,000-5,000|
|com.beauty.photo.artist||1,000-5,000 → 5,000-10,000|
|com.collage.pic.editor||1,000-5,000 → 5,000-10,000|
|com.paper.exquisite.watch||1,000-5,000 → 5,000-10,000|
|com.optimizer.mybooster||1,000-5,000 → 5,000-10,000|
|com.star.tears.staroptimizerexpert||1,000-5,000 → 5,000-10,000|
|com.fog.magic.mycleaner||5,000-10,000 → 10,000-50,000|
|com.photo.optimize.master||5,000-10,000 → 10,000-50,000|
|com.shine.wind||5,000-10,000 → 10,000-50,000|
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.
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.
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.
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:
|core.clean.com.scanningapp||Gp1 Click fraud confirmed: Apps had been removed previously||15/09/2017 (last update pushed to the PlayStore on 14/09/2017)|
|com.life.read.physical.trian||Gp1 Click fraud confirmed: Apps had been removed previously||15/09/2017 (last update pushed to the PlayStore on 14/09/2017)|
|cn.clear.master||Gp1 Click fraud confirmed: Apps had been removed previously||15/09/2017 (last update pushed to the PlayStore on 14/09/2017)|
|com.easy.blood.test.instrument||Gp1 Facebook Click fraud confirmed: Apps had been removed previously||17/09/2017 (last update pushed to the PlayStore on 16/09/2017)|
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:
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:
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.
- 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
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.