Last week in our K7 Threat Control Lab we came across an Android ransomware “locker” sample with a difference. This one splashes a lockscreen that recommends to the user a list of free applications to install in order to continue using any already installed application as shown below:
However, if the user chooses to install one or all of the listed applications, the list seems endless since a new application is inserted for the one that is chosen for installation. This implies that the user may not be able to access his already installed applications or it might take a long time to exhaust the displayed list to access them. Interestingly, the applications installed from the lock screen list are free to open and are not blocked by the splash screen.
Now let us see how this malware actually works.
Analysis of this locker shows that the AndroidManifest.xml file of the package has RECEIVERS (net.fatuously.Unengaged and net.fatuously.Encephalitis) registered to receive the broadcasts BOOT_COMPLETED, USER_PRESENT, SCREEN_ON, NEW_OUTGOING_CALL, PHONE_STATE and DEVICE_ADMIN_ENABLED respectively. But the registered RECEIVER classes are not referenced in the corresponding classes.dex.
In addition when this locker sample is executed the application displays an additional custom explanatory message that is also not referenced in the top-level package, as shown in the picture below:
Digging further it is understood that the APK under study carries within itself an encrypted (XORed) ZIP file (test.dat) in the assets folder which in turn carries the classes.dex file that is loaded at run time.
The studied APK file loads the classes.dex from the encrypted ZIP using the dynamic loading feature as shown in the java source below:
The RECEIVERS registered in the top-level AndroidManifest.xml and the additional explanation in the Device Admin request screen are referenced in the dynamically loaded unzipped classes.dex file.
When the user tries to open any of the applications that is installed prior to the locker, the malware loads the splash screen by setting the splash screen content as the data to the intent “android.intent.action.VIEW” as seen in the following code:
This malware when run without an internet connection, or during application initialization, loads a different splash screen as shown below:
The corresponding code to load the above screen is:
And the contents of none.html are follows:
Base64 encoded data in this HTML contains the image (.PNG) content to be displayed.
A few of the websites to which this malware connects are:
Strangely the splash screen does not seem to demand any payment from the user. However, it proves to be malevolent as it does not allow the user to open any application that is installed earlier than the locker.
As we discussed in our VB2014 paper “Early launch Android malware: your phone is 0wned”, an updated boot and broadcast framework in the Android OS that allows the security products to load before any other application will help to keep these locker variants at bay. K7Mobile Security protects its users from this locker with the detection called “Trojan (004c2fc61).”
V.Dhanalakshmi, Senior Threat Researcher, K7TCL
If you wish to subscribe to our blog, please add the URL provided below to your blog reader: https://labs.k7computing.com/feed/