Zimperium's Mobile Security Blog

How Zimperium’s z9 Detected Unknown Mobile Malware Overlooked by the AV Industry

How Zimperium’s z9 Detected Unknown Mobile Malware Overlooked by the AV Industry


Thousands of new malicious apps are being released for mobile devices every day. And thousands more variations of older malware are being released too. Unfortunately, many of these new/old threats are not being detected by the existing mobile malware technology. Organizations need next generation machine learning-based solutions that can effectively detect these unknown malware variants without updates and protect their devices and users.

Zimperium is the only mobile security solution delivering on-device, machine learning-based detection of malicious apps and has become the benchmark standard for machine learning-based detection of mobile malware.

Yes, that is a bold statement… but we stand ready to prove it.

What is the single best way to prove the effectiveness of a machine learning-based mobile anti-malware engine? Detecting mobile malware variants that have never been seen before.

This post documents a series of malicious apps that were detected by z9… samples (including ones of well known families that have been around for years, such as Anubis and BankBot) that were publicly unknown. We conducted a webinar to provide additional context, which can now be viewed on-demand

Frequently, security researchers and vendors focus on the latest malware family that hit the news while forgetting about older campaigns that continue to pose a real risk to the end user. In this post, we will highlight recycled and evolving malware families bypassing existing mobile anti-malware technology (ie. signatures, cloud-based analysis) to reinforce the importance of having an advanced malware detection engine, such as z9.

Malware family correlation and identification

The strength of Zimperium’s z9 for malware engine is its ability to detect unknown malware using its on-device machine-learning classifiers. ​As unknown detections are triggered, the samples and their metadata are thoroughly analyzed in our systems. While performing our analysis on some of the unknown samples we noticed a strong correlation between the new, unknown samples and previously known, well-covered malware samples. This prompted us to dig deeper.

We extracted a subset of samples that were not known to the industry or resident in public malware repositories. The samples were then run through our z9 for malware family classification engine and grouped into SMS Fraud, Banker, Dropper,Riskware and Locker families. More precisely, we linked the unknown samples to known samples that are part of the following known malware campaigns:

  • SMS Fraud (Avito)
  • Banker (Anubis/Bankbot older non-obfuscated versions)
  • Banker (Anubis/Bankbot updated obfuscated versions)
  • Dropper/Banker (HQWar trojan dropping Bankbot payloads)
  • Riskware/Dropper (Hidden Adware, Triada and spyware payloads)
  • Locker/Ransomware (Chinese lockscreen locker)

In the following section, we will briefly analyze the attack vectors and behaviors found in the malware samples.

Involved Actors

Far from being simple malvertising families, the analyzed campaigns pose a real and serious security risk to users:

SMS fraud – Avito:

E-commerce apps are also a profitable target for malware authors. During this research, we found several samples targeting clients of the Avito market app, a Russian classified advertising platform with presence in several countries such as Morocco and Egypt. In the past, malware authors have used the information posted in this online store to distribute malware via SMS [1]. 

The campaign we found seems to be closely related with this group of old samples as they share parts of its implementation, such as the string decryption routines or the network communication logic. Among the malicious capabilities of the fake Avito family, it is possible to find SMS stealing techniques, installation of rogue device administration policies or device information exfiltration. Despite the fact that many blog posts discussing this family date from 2016-2017, our findings showed that an early and much simpler strain of fake Avito samples is still in the wild. During analysis, some clear differences came up:

  • Device administration capabilities: While the main entry point of recent samples of the fake Avito family leads to the installation of a device administration privilege, the sample we analyzed requires manually triggering one of the services exposed in the manifest to display its malicious behavior. Although it also contains the logic to install a device administrator, its policy group is empty. 
  • Network traffic: The found samples generated far less traffic during analysis than the reported examples. During our research, we discovered how it retrieved a JSON document containing templates of what seems to be 2FA SMS. Such file is retrieved from which, according to VirusTotal, was used to host several domains whose URL have been found in other Avito samples.

z9 detection results:

2e2cac6f6e55d1eab273b73cf5b3b787d26b26eff101b6ee2fd9ab2ebb470d91: Confidence: 100.00, Family: malware

0b4b9b25180b18f973d58b49bd6c8a2ef94d19ab0a884e6dfcac525b161e0c14: Confidence: 100.00, Family: malware

Some of the related samples are:





Ransomware / Lockers:

In the last few years, ransomware and lockers (apps that encrypt data on the device) have rapidly become one of the most prevalent and harmful malware threats for both mobile and desktop devices. Malware authors take advantage of inexperienced users, luring them to installing malicious programs that block/brick the device or encrypt all its contents, asking for a ransom before allegedly taking the device to usable state. 

During our research, some of the app lockers stood out. After a brief inspection, we found no special efforts were made to hinder analysis (i.e no obfuscation or anti-analysis techniques). In fact, we noticed the samples were some very basic versions of the old “SLocker” malware family, initially reported by TrendMicro some years ago [2] but yet unknown to online analysis platforms and AV vendors. As is common in Android lockers, the sample abuses the device administration API to gain control over the locking screen of the device, forcing the user to pay a fee to recover the access to the device. 

Screenshots of the requested device administration policies and the screen locking applied by the sample.


As depicted in the above images, the device is completely locked once the device administration policies have been activated and solely displays an EditText field with the hint 这里输入密码 (Enter your password). From a technical point of view, the sample does not  feature any sophisticated or advanced characteristics. In fact, the algorithm employed to locking the screen is quite easy to reverse and eventually bypass. The authors employed two different techniques to lock the user away from the device: manipulating the layout settings and changing the unlocking password using the gained device administration capabilities. Both locks are easy to bypass as they both rely on the same logic. Roughly, the method that checks the user input takes the contents of the correspondent files (gdmm.txt in the case of the layout lock and pin.txt in the case of the device Administration lock), using its content as a parameter for the function depicted in the following snippet:


As can be seen, most of the content of the function can be ignored. It just performs replacements and just after, it undoes such substitutions. At the end of the day, the logic can be stripped to: 

  • Decode from Base64 the parameter string.
  • Reverse it and decode from Base64 again.

Following these steps, both unlocking codes can be easily retrieved:  000316 & qqqq. It also seems this sample belonged to an early batch of SLocker samples.

z9 detection results:

113efd6c1956eb9e1f94ea04ff6ef63aaca912e3930acf8346d3696fd3736f23: Confidence: 100.00, Family: trojan

e6be2b3c3e89a314c4247ebfbf56b511ac38aba4acda7e300cdc50e6342c465d: Confidence: 100.00, Family: trojan

Some of the related samples are:






The analyzed banker samples are part of (or derived from) Anubis, Bankbot and HQWar malware families. In particular, some samples were dropping very old versions of the first Bankbot payload. Generically speaking, all of them have been repurposed on several occasions during the years and tailored to different tasks.

Anubis has been spotted in cyberespionage, ransomware and banker scam campaigns, every time featuring updated or improved evasion mechanisms (e.g. at the start of 2019 it used a motion-sensor based anti-emulation technique). The main malware features are:

  • Disable Google Play Protect
  • Complete access to the SMS
  • Take screenshots, record audio or lock the screen
  • Monitor applications and open overlays with custom URLs
  • Complete access to the Device Administrator configurations
  • Complete access to the files with the possibility to encrypt them
  • Using Twitter and Telegram as covert communication channels
  • Steal device’s information like contacts, unique identifiers, processes list, GPS location

HQWar has been active since early 2016, had a peak in 2018 and is still alive in 2019, acting as an infection vector for many malicious campaigns. It implements a wrapper that decrypts and dynamically loads an embedded payload. The malicious actor relying on HQWar can sign the sample with different certificates: randomized, Google or private one.

Bankbot is one of the most famous banking trojans that has plagued Android users since 2016. During the years, it evolved to add an ever-growing list of targeted bank (and other) applications and greatly improved the string and class obfuscation used by the main payload. The principal attack vector is abusing Device Administrator and Accessibility services to trick the user into giving additional permissions. Once a bank application is launched by the user, the malware spawns an overlay on top of the legit activity mimicking the official app’s user interface. Once the victim inserts their credentials, they are sent to the C&C and the malware usually shows an error message saying that the bank services are not currently available.

Screenshot showing how some of the Anubis banker samples were not string-obfuscated


z9 detection results:

26ace4765f2837a67c9158aa840698338593a35f217b5ea1f617153d4c98179f: Confidence: 100.00, Family: banker

ca0dad8c0d7daecd12de79f6ebabc33979e4c3dee688418b56efc01fe9b65bfc: Confidence: 100.00, Family: banker/malware

8322d5c6766fe87375afb32f48539bdf234c1adaacf889434dbaf059e2823095: Confidence: 99.96, Family: banker

Some of the related samples are:











A sample should be considered “riskware” when it poses risks that may be unacceptable in certain environments. In the filtered set of samples, we found applications loading aggressive or hidden advertisements, collected unique information about the device and loaded paid subscription URLs without the user knowing about it. 

It’s not uncommon to find legit applications embedding a lot of third-party advertisement SDKs that at some point turn malicious. Many advertisement SDKs turned malicious without changing their code. One of the most common attack vectors consists of loading a Javascript script downloaded from an external server and executing it inside a hidden WebView to control the actions on the loaded page (e.g. faking the clicks on ads or paid subscriptions). Based on some conditions (e.g. GPS location, usage of the device, time), the malicious behaviors may or may not show.


z9 detection results:

b93fae996fc9d6ded5f201627ed09c736a98eba7db2dfb53c65b33f7bb759e63: Confidence: 91.22, Family: riskware

Related hashes:






Droppers are one of the most common families of malware targeting the Android platform and are very similar to the method that is found on desktop platforms.

The purpose of this kind of sample is to download and place a malicious payload in any folder inside the device storage space to be later loaded and executed. This allows the sample to leverage a secondary payload that may go undetected by security vendor detection methods. During our research, two samples were found that remain unknown to AV vendors according to VirusTotal data – despite vendors detecting earlier samples of the sample families. However, our correlation process and detection engine allowed us to link them to other known droppers already detected by our AI-based detection engine.

z9 detection results:

837541c220f0eb9e2e83e9aea81ad1a83b53a857c48646fc1e9905d1a6fe7d45: Confidence: 100.00, Family: trojan

9d05a4eebe1dfa6a6caf8926e4e63a0d00a20a112adb5860ff3d057bd3b61365: Confidence: 100.00, Family: trojan

Some of the related sample hashes are:




The Main entry point for both droppers is a BroadcastReceiver listening for the android.intent.action.BOOT_COMPLETE and android.net.conn.CONNECTIVITY_CHANGE events – these are “callback” notifications that cause the app to run when the device is restarted, or there is a change in network connectivity.  When any of these events are triggered, the sample will start a service whose first action is to load a native library. 

The native library registers a couple of native methods implementing the dropping, decryption and dynamic load of the payload contained in the assets folder. Interestingly, the analyzed droppers tend to use over-complicated approaches to obtain particular system information or performing common tasks. 

For instance, both samples read /proc/pid/maps to check if any 64 bit libraries are loaded and find out it is running in a 64-bit capable system or use ZipFile and ZipEntry classes to load native libraries using the System.load(String path) instead of just issuing a simpler call to System.LoadLibrary(String libname) despite the fact that they are in the proper lib directory.

Once the payload is loaded, an instance of one of the classes contained in the dropped file is natively created using the reflection API. The instantiated class implements the Handler.Callback interface, which allows it to handle Message objects containing parcelable objects. The natively created object is returned to the dropper, which transfers the control to the payload by calling the handleMessage function of the object and passing a Message object with a specific code and a hashmap with some information about the dropper. The dropped payload is not too different from other trojans/backdoors in the wild, and includes some of the common behavior:

  • Capabilities to install/update new applications and load other components in runtime; this feature includes the complete logic to handle installation errors.  


  • Checks for toolsets such as toolbox or busybox (indicated a rooted device) and attempts to abuse them to remount the root filesystem and modify system files.


  • The sample uses several mechanisms to achieve persistency: periodic checks of the process list to check if the dropper service is running, deployment of a native component that silently launches the dropper service using the pm and am commands.

After our own analysis, we checked what other vendors know about the dropped payload. It seems it is labeled as a known trojan but there is no consistency among vendor labels. While some vendors claim this belongs to the Triada family, others label it as a generic backdoor. What it is definitely true is that it contains advanced capabilities commonly found in aggressive trojans and it poses a real risk to infected users.

Why are these samples still in the wild?

The success of a threat actor is often to cast widely and quickly. In order to do that, threat actors reuse old malware code to deploy new malware campaigns by modifying malicious features and applying different kinds of obfuscation layers and techniques. Obtaining the source code is not difficult. Several families, including Zeus, Bankbot, Maza-in have been leaked and are available in underground forums, accelerating the proliferation of lookalike malware (e.g. Anubis) that are rebranded versions of the original sample(s).

Threat actors prey on easy and vulnerable targets to distribute their malware. A common and effective way to distribute their malware is by targeting users and devices that are not protected by the app vetting processes offered by official app stores. Instead, threat actors rely on third-party app stores, enticing “free” and cracked games and apps, and phishing campaigns to distribute their malware. 

Combining the ease of access to malware source code and the ability to modify its features, including the various distribution channels to seed their campaigns, it’s clear how threat actors are bypassing outdated AV signatures of “known” malware. 

Staying ahead of the problem

We’ve proven through third-party testing and from the adoption of our engine by industry leading organizations (stay tuned for announcements on both the testing and industry endorsements) that Zimperium is a key threat intelligence source.  And we are the solution for providing on-device detection and classification of zero-day malware. The ability to use behaviors coming from known sources to find similar features in unknown sources, and to cluster the malicious samples in malware families, are important traits to its success.

We constantly train our models with new data to be able to detect unknown, and also common and well-known malware families. Being able to quickly identify the most malicious samples in a bigger set of applications and divide them by family is fundamental for a proactive research environment and effective remediation policies.

As this research showed, we constantly correlate older unclassified samples with the latest threats to be able to spot similarities and eventually identify the early stages of known malicious campaigns that evolved during the time. This proved true for several of the samples, and we can speculate that some of the early stages were released by malicious actors to measure the efficiency of the spreading vector mechanisms and the AV detection coverage. Before Zimperium, the actors must have been pleased with the results.


In this blogpost, we showed again the outstanding detection capabilities of our machine learning-based detection engine, z9. This case also illustrates how z9 is highly resistant to common flaws of machine learning. 

For instance, several machine learning approaches used in malware detection and other domains whose target changes along time, may suffer from concept drift, the difference between the statistical properties of the concept the classifier is trained to predict and the actual properties of the data it uses to make a decision. 

This translates into a loss of accuracy as time passes. Periodic retraining using fresh data and a statistical analysis of the feature set are proper countermeasures to prevent these kind of issues.

The findings presented in our article prove our machine learning-based solution is resilient to these kinds of problems, and it is capable of making accurate decisions on both cutting edge malware campaigns and N-day threats.

We will be conducting a webinar on November 20th at 10am Central, where will be providing additional context. 



SMS fraud (Avito)[1]




















Banker trojan (Bankbot/Anubis variant)[3]









Banker trojan (Bankbot/Anubis variant)[4]






Banker trojan (HQWar dropping BankBot)[5][6]