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
  • ACTION_ACCESSIBILITY_SETTINGS
  • ACTION_VIEW
  • com.android.vending
  • com.android.providers.downloads
  • android.settings.APP_NOTIFICATION_SETTINGS
  • android.provider.extra.APP_PACKAGE
  • android.intent.category.DEFAULT
  • 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
  • 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
  • 2039 = 0x000007F5 = TYPE_ACCESSIBILITY_OVERLAY|TYPE_TOAST

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.

Summary

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.

IOC

Google Play Store:

6e06c328cc48bb49e0d05871154fc3674dd8c6a00eed8299d7da98610ca4b432

5df83b5362fd86301eae1ae87fa1deff46a50d921ea04abbfc22db6fa4e21c9a

Not packed:

4b8f5491517cca354e48c1069a2e9dc5c14ba6e94b6083d2d8a34cab74d818b1

4faf17374f190cb9d1fd02b302428fa4d22c646eb1d9f974596fa8844aea931f

6b40ae94fb31a73420653577cbc0905bef995d1a14b3f96c780b8d09a6e0b82f

95ef331095d1787ac9436852972f542f34c5c62deaefb88ee5e00b60fa80a649

9236e705642b46d868b6a25a2b9324ec814c1741961576217d74a857e3d95d4c

55fc20b0b2cd58bb4e917381193de9c13064c5edec53d19b721f2c546a236788

07bcd2eb1be71c457c8a9132e617b331b7babd88b8130ce11252d770d800bd70

Packed:

3163d95516728ae0fb88b2a7a24c20097fb7b1a5060b0aeb4a488494ef947cf9

6d1b6df47442a5e5cc470d00ccf21d4cc18658ac08f810fbdfab462b96b9926c

017b48b642792953e909161f913d4769248e6ff7a94532dedb652245d33de0e9

1bbcb7eebb7605bb88aa8015ebf9ed2eceaf1caca3f68eec4d7d80f4977860d2

29a7fb8ce1bca87435a30bfd0a90c10d51531d5da92bea3f3b967c1ac9a255e1

117c7d1e20ae662817f1297aebc89fd15c4adeb152c164af640fffd88b0c9834

969fff903948507ca3725714bf0ab75fbbbdfaeaf00f2e569e6d0b243c0e702d

52e8581baa849172b9178207643d65e0f2c3d681e72458e1821dcccd54ada241

3c5a6b79776de78d9d33116bd9cc84290a84af3109eaceb9aef13c3df46d6117

db157bb38456fb2110435d87e675aee19c1617bec7cb438d2508c8a33c6e0f90

3de6fbf59da77e46620ce5cf404bcce8e1c90f3015b900cc164c3361354f233a

Dex:

30674ba8a63c757e9e2013bfc650234dab9dbb7ff02c1018df951b2b75cfaa42 

c14edf48ca13638f4cb290712f16f9dc1a9b39b95085fb87437c0b74ff348061

de5997e33f74a3fd3356509a986c10c8385eaf52b2da9ba39b06603190da51da 

25a4680cf9e7b5c44a0499e84ccd1a7d37a0bdcc1881242a00cb478374bd4e8a

C&C:

http[:]//52[.]221[.]7[.]34[:]8087

http[:]//hy[.]uyt1[.]de

http[:]//www[.]uyt1[.]de[:]8802

http[:]//hj[.]fawea[.]de

http[:]//ggg[.]koapkmobi[.]com

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/