Machine Learning vs Signatures, Round N: Once Again, Zimperium Detects Machine Learning vs Signatures, Round N: Once Again, Zimperium Detects | Sirin Labs
USD
English
Home / medium import / Machine Learning vs Signatures, Round N: Once Again, Zimperium Detects Malware No One Else Does

Machine Learning vs Signatures, Round N: Once Again, Zimperium Detects Malware No One Else Does

Malicious Learning

Analysis & Post By:

Alex Calleja (@alximw)

Matteo Favaro (@fvrmatteo)

 

 

Advertising and click fraud campaigns are one of the most common mobile malware-based monetization techniques. Although they are considered a lawful income source in most app markets, they can put the user’s privacy at risk and even cause economic damage.

Once again, Zimperium’s machine-learning based solution, specifically the z9 on-device detection of malware, has proved its effectiveness against these novel malware samples – without prior sample knowledge and without signatures.

Since early January 2019, zLabs has been receiving alerts about a new privacy-threatening advertising and click fraud campaign targeted at Chinese users. While these campaigns remained unseen to most vendors, z9 allowed our researchers at zLabs to detect them and deliver the proper countermeasures. In fact, the sample that triggered Zimperium’s z9 detection has zero industry detections by third party vendors.

So it begins

On January 8th, researchers at zLabs received an alert from z9 regarding a new sample surpassing the detection threshold. A brief analysis revealed some uncommon and suspicious features such as the lack of an intent filter tagged with the android.intent.action.LAUNCHER category.

After further analysis, our researchers confirmed a clearly anomalous sample: empty MainActivity and an obvious use of strings obfuscation. Also, a service (NickService) and a receiver (MicReceiver), both launching an embedded component, were found in the manifest. After confirming the service and receiver were not launched from the sample or automatically triggerable because of the missing action filters, dynamic analysis was in order.

 

Figure 1 – com.xksx.tosiok manifest file

Our analysts manually triggered the service and analyzed common indicators such as the network traffic or the file system activity, noticing how different JSON configuration files were downloaded from a remote endpoint.

A particularly interesting JSON contained a URL pointing to a suspicious file, path_gn_qid19_update12.dat. Further inspection revealed this BLOB contained a dynamically loaded encrypted dex file. Obtaining the deobfuscated file was quite simple since the developers hardcoded the seeds used in the initialization of the SecretKeySpec object used in the decryption:

The entry-point of this new payload was also weakly obfuscated, so it was easy to move forward with the analysis. To have a broader view of the “dropper” capabilities, our researchers concurrently reversed different samples noticing how the entry package1 had the same structure and only the URL to fetch the first dropped payload changed. This strongly suggests that it may be a customizable and injectable package, maybe sold on a black-hat forum and advertised as monetization malware.

The dropped payload is started via reflection by the main package and shows a common entry method with signature void run(Context ctx) whose purpose is to start several Ads and statistics-related SDKs. It was further noticed how some of them can pose a privacy risk to the user, as described in the following section.

 

 

Figure 2 – comparison between the run methods in two dropped payloads.

Payloads hierarchy

The following diagram depicts the hierarchy of the dropped payloads and main loaded packages for the com.xksx.tosiok sample, which resembles a Matryoshka dolls set.

Figure 3 – Tosiok’s dropping hierarchy; other samples relies on different payloads.

Targeted Ads and privacy risks

As can be observed in Fig.2, the main objective of the first dropped payload is to start several advertisement and statistic SDKs.

The following abuses and privacy risks have been identified:

  • A lot of statistics-gathering packages are collecting information related to the device (IMEI, IMSI, MAC, OS version, model, brand, screen size), the mobile operator (MCC, MNC, CID, LAC), the geolocalization (timezone, latitude, longitude) and user installed packages.
  • Several packages contain code to spawn a hidden WebView with JavaScript support, cookies and access to the file system. Advertisement and information gathering URLs are subsequently loaded in the WebViews. Usually an empty TrustManager class is registered too, probably to enable the usage of an SSL connection (but without the security provided by a proper trust manager implementation).
  • Some information gathering and advertisement SDKs are explicitly triggering some of their behaviours only if running on a Chinese ROM (e.g. EMUI, FLYME, MIUI, OPPO, QIKU, SMARTISAN, VIVO) or if a Chinese APN configuration is detected.

The most curious and worrisome behavior our analysts found is the implementation of targeted advertisements which abuse user-installed applications. Dynamic analysis allowed our researchers to discover a JSON configuration file being collected from one of the backend servers supporting the campaign. The retrieved JSON file contains several package names and related URIs, presumably used to abuse the Ad-displaying capabilities of legit apps by crafting new Intents using the mentioned information. Once again, evidence of a highly-targeted campaign emerged as most of the package names present in the document were related to popular apps in China. Package names of the Baidu and Taobao Apps together with other social media and video sharing apps such as TikTok and Youku were found in said file.

 

Figure 4 – Creation of the Intent related to the targeted Advertisements.

Industry detection (or lack thereof)

While verifying the coverage of the samples and dropped payloads, our researchers couldn’t help but notice how the detections were heavily inconsistent on famous malware comparitive services such as  VirusTotal and Koodous. Specifically, the payloads labeled as ddms tool and app_cache, even if slightly differing from one another, were detected by many AV vendors (e.g. 20+ VirusTotal detections) while others were often undetected (e.g. less than 4 VirusTotal detections).

Zimperium’s z9 on-device machine learning engine correctly detected and classified the threat with high confidence, specifically labeling the main APK as Trojan family (given it’s stealthy dropping capabilities) and the collected payloads as Riskware family (as expected from a privacy risky package), without leveraging signatures.

Curiosities

During the investigation, our researchers managed to collect a total amount of 150 dropped plugins being distributed in a time span ranging from December 2017 to February 2019. While most of them had the same exact structure, 5 of them had unique resource files, mostly related to new Ads SDKs. This shows that the malware campaign is not new and, most importantly, that it’s still actively being developed.

As was mentioned in the introduction, the sample that triggered Zimperium’s z9 alert has zero industry detections. In fact, it’s highly likely that this was caused by the fact that the malicious actions couldn’t be automatically triggered in an analysis environment. The com.xksx.tosiok APK has a single exported service and receiver that can be triggered manually, unlike the other samples that are exposing a service with a lot of intent filter actions (see Fig.5). This led our researchers to label this as a test sample that the malware author uploaded to VirusTotal to verify the detection rate. Once again, Zimperium’s z9 engine proved to be instrumental in discovering previously unknown threats.

 

Figure 5 – Manifest of a dropper APK different from com.xksx.tosiok

IOCs and hashes

Original APK samples with the common dropper package:

  • af148157aa22bd7099c7d672b69c02b3ac81e248657ce1114d4922e58074fd79
  • d5078d5df439dff6f12c5adda8f23a5f70e70ea79185538679add4e9fcade01a
  • 11eca4021be623f3270c6b7e253ada274d24227a27bb50bfb88d7dcba10a9eea
  • f88783132f611738e937684ca76e562155497ade4f0affb9a6c75f86819dbdd9
  • 6744e5c156d12f34d64d482d358c35581ab8cd0a19adcb3b25081bb1b3b66156

Payloads dropped during the analysis:

  • 3323003.jar (d19d2f3e6a678d63b3c44d5010d3a13068a4e03d14be1a07642311eb40a399f3)
  • 3018798.jar (3a5c0a64b634b2df3bb7a1addd8965dbf3ee70bcde5974977c2b506dd03b6985)
  • 101510.jar (a0c9a0e615e7cff0eeaf1ccfae2d3517202ad8905dc844d2ce1c35c69586f6f4)
  • android-util.ttf (c4cc944333e559b5f385dd16ddebebe843897c78667c628f53896782978a5f46)
  • app_launcher_ic.png (69176cb60ff0dc3b529319ead630bbffbf7e36ef38031e1e23044c8f6e69fb04)
  • sc_160 (e0ec4ea86dafc746d111d8ecbf3ab3eacaf357b4e1f3d7bcbce5b29cbd0240c6 )
  • bdco (d9751bc5d98132c400304902b89b1d915da33447bdfe6810c47d2507026783d3)
  • snap.png (1d4922502ac642f8bc67b8e92903f2b1a4f95d03b03f968a0a544cad723e4bcb)
  • mures.dex (b90ae4f3ba86f9bdf58b815ae798982af580b7c54828d42b6677cba79315c808)
  • EventDex.dex (74e9690c37b8f7090a20c9b3b06efad508b5e06c3a3fcd275bfecc2fa4f14093)

Special thanks to the entire Zimperium zLabs malware research team for their contributions to the analysis and this post.

The post Machine Learning vs Signatures, Round N: Once Again, Zimperium Detects Malware No One Else Does appeared first on Zimperium Mobile Security Blog.