Zimperium Discovers MobOk Malware Left Undetected by Mobile AV Industry for Months

zLabs researchers have uncovered a new variant of the MobOk campaign. The samples found evaded detection by AV vendors for months. Zimperium worked with Google to ensure removal from the Play Store. 

The new variant samples:

  • Hide themselves from mobile antivirus (AV) vendors;
  • Subscribe to premium mobile services;
  • Avoid image-based CAPTCHA;
  • Avoid two-factor authentication (2FA); and
  • Abuse the accessibility services to conduct malicious actions.

MobOk –  an Android malware campaign detected for the first time around June 2019 –  has constantly evolved to achieve total evasion of detection by the mobile AV industry. 

zLabs researchers noticed suspicious activities from a set of applications having similar code structures and functionality patterns. 

Upon investigation, we concluded the samples are improved variants of the MobOk campaign, many of which remained undetected by the anti-malware industry for months as can be seen with the VirusTotal coverage below.

Fig 1. Missing coverage of a sample as of June 2020

Fig 2. Low coverage of a sample, known since November 2019, as of June 2020


These new variants make use of the Tencent packer to hinder a plain static analysis and an improved native library containing the bulk of the malicious code. The Tencent packer decrypts some files from the assets at runtime and rebuilds a dex file that is then dynamically executed. For further investigation, our researchers dumped the dex files loaded at runtime and verified their maliciousness.

First Execution

After installation, the first launch of the application displays the following screen, asking access to the notifications permission.

Fig 3. The malware requesting the needed permission


After granting access to the notifications, the application exits immediately when launched a second time. A subsequent launch will finally load the malicious dex payload and start the communication with the command and control server.

Data Exfiltration

The malware makes a POST request to a malicious URL that varies from sample to sample (e.g. http[:]//ww[.]uyt1[.]de) with an encoded JSON payload having fingerprinting information about the device, such as: IMEI, IMSI, model and network configurations. 

Fig 4. Data being exfiltrated


In order to get the Accessibility Service permissions, the malware displays the following popup. When clicking the “OK” button the malware will open the below Accessibility settings “solemnly promising” about its legitimacy and asking the user to ignore those “nasty” privacy warnings.

Fig 5. The devious approach that the malware author used to request the Accessibility Service permissions

Evasion, CAPTCHA Bypass and Malicious Behaviors

These samples are very interesting because they use two simple, yet effective, techniques to evade detection by AV solutions:

  1. Packing via the Tencent Packer hides the code from plain static analysis and dynamically loads the malicious dex file.
  2. Embedding of a native library that exposes a set of JNI methods implementing the core malicious functionalities.

Fig 6. Structure of the packed APK

Subscription to Premium Mobile Services

The malicious dex file embeds the following code to turn off the Wi-Fi and connect to the mobile network in order to be able to charge for premium mobile services.

Fig 7. Code to turn off the Wi-Fi


The subscription to such services often requires a verification of the request either by using 2FA or Image-based CAPTCHA, specifically meant to thwart the usage of automated scripts. However MobOk is ingeniously capable of bypassing both the mentioned mechanisms.

To bypass the usage of the 2FA, it takes advantage of the notification access to steal the received SMS messages, post them to one of the C&C servers and further process them as needed, as shown below.

Fig 8. Code to steal the 2FA SMS messages

Image-based CAPTCHA Bypass

To bypass the Image-based CAPTCHAS, MobOk takes advantage of the advancements in the accuracy of image recognition services. In fact the analyzed samples send the captcha image to an external service using the uploadFile functionality, as can be seen in the image below.

Fortunately the file upload feature doesn’t seem to have been abused to steal any sensitive files on demand from the C&C, but strictly in order to upload the CAPTCHA image files.

Fig 9. Code to query the external image recognition service

Malicious Behaviors

The following code snippet shows some consistency with the previously known variants, where a WebView is used to load malicious URLs and execute harmful JavaScript code. The previously mentioned POST request to the C&C also contains additional information about the device including: screen height, screen width, model, brand, fingerprint, hardware, manufacturer, product and network operator name.

Some of these pieces of information are also used to aid the clicking functionality that abuses the Accessibility Service permissions.

Fig 10. Code to browse URLs received from C&C in a webview

JNI Functions and Accessibility Services Abuse

The usage of the Accessibility Service permissions by the malware relies heavily on the embedded native library named libfs.so (of which more or less feature-rich versions have been spotted in the analyzed samples). In fact, several JNI methods, part of the Java_com_flurry_sdk_zz_ namespace, are exposed to the Java side. Some of them use AES256 encryption (with the hardcoded key xS544RXNm0P4JVLHIEsTqJNzDbZhiLjk) to decrypt a set of sensitive strings that are then going to be used at runtime by the malicious code.

As previously stated, the MobOk samples have been evolving over the past few months, and that can be clearly noticed by the amount of core functionalities that have been shifted from the Java-land to the native-land. 

As a matter of fact, the newest samples moved the majority of the Accessibility Services and Intent spawning code to be implemented by the JNI methods and proceeded to encrypt all the sensitive strings too.

The list of decrypted strings for one of the samples that we analyzed is listed below:

  • 2032
  • 2037
  • 2005
  • setComponentEnabledSetting
  • com.android.vending
  • com.android.providers.downloads
  • android.settings.APP_NOTIFICATION_SETTINGS
  • android.provider.extra.APP_PACKAGE
  • android.intent.category.DEFAULT
  • http://play.google.com
  • https://play.google.com

To the attentive eye it’s clear those integer values have something interesting to tell, and in fact can be matched to their WindowManager.LayoutParams flags counterparts:

  • 2005 = 0x000007D5 = TYPE_TOAST
  • 2032 = 0x000007F0 = TYPE_ACCESSIBILITY_OVERLAY

In the analyzed malware samples, the JNI methods were responsible for:

  • Collecting information from the android.os.Build class (e.g. BRAND, FINGERPRINT);
  • Obtaining the network operator name from the android.telephony.TelephonyManager class;
  • Returning the aforementioned WindowManager.LayoutParams flags, to be later used in the crafting of ad-hoc Accessibility Service windows.;Adding a specific set of options to a newly created Intent, ending up with the perfect recipe to spawn a disguised malicious activity: FLAG_ACTIVITY_NEW_TASK, FLAG_ACTIVITY_CLEAR_TOP, FLAG_ACTIVITY_SINGLE_TOP, FLAG_ACTIVITY_NO_ANIMATION, FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS, FLAG_ACTIVITY_NO_HISTORY, FLAG_ACTIVITY_CLEAR_TASK;
  • Hiding or unhiding the application’s icon from the Android drawer; and 
  • Creating and spawning several activities to request access to the Accessibility Service permissions and to open a Google Play Store page on another specific sample related to the MobOk campaign.

The newest capability in the list is of particular interest because we noticed some samples immediately try to install a companion malicious application from the Google Play Store (10.000+ installations) by abusing the crafted Intents and the Accessibility Service API to hide the action from the user’s sight, as can be seen in the following screenshots.

Fig 11. Loading screen hiding the background installation of two companion apps related to the campaign

Fig 12. Both applications have more than ten thousands installations on Google Play Store


On the self-defense side we find that once again the malware abuses the Accessibility Service API to hinder its uninstallation by pressing the Home button if the option to uninstall the application is detected on the device screen.


To sum up, the MobOk samples are capable of the following:

  1. Switching from Wi-Fi to Data Connection;
  2. Subscribing to premium mobile services;
  3. Solving Image-based CAPTCHA using an external image recognition service;
  4. Stealing SMS used for 2FA; and 
  5. Using the accessibility services to carry-on malicious activities on the screen.


Google Play Store:



Not packed:































Special thanks to the entire Zimperium zLabs malware research team for their contributions to the analysis and this post and in particular, Matteo Favaro and Alex Calleja. You can follow me on Twitter.


The post Zimperium Discovers MobOk Malware Left Undetected by Mobile AV Industry for Months appeared first on Zimperium Mobile Security Blog.

Article Link: https://blog.zimperium.com/zimperium-discovers-mobok-malware-left-undetected-by-mobile-av-industry-for-months/