As already discussed in previous reports and publications about banking malware and malware in general, both for mobile devices and for computers, one of the most popular threats today is ransomware.
In corporate environments, ransomware is giving companies a very hard time, who are witnessing how overnight all of the files on their computer systems become encrypted due to the action of some of the most popular types of ransomware, such as Maze, REvil, Ragnar Locker and CLOP.
This isn't the first time that malware writers have migrated their business model to take advantage of mobile devices. For example, Cerberus, GINP or Anubis Bankbot are currently some of the most popular Android banking malware families. This same trend is also beginning to be seen in ransomware, which is beginning to migrate towards mobile devices.
The modus operandi of malware for Android platforms varies from the malware that's designed for personal computers. In the case of ransomware, it is especially interesting to analyze these variations with respect to ransomware directed at other platforms so that we can fully adapt to this new context, be prepared, and improve the tools used for its identification and containment.
This report focuses on the analysis of MalLocker.B, a sophisticated ransomware trojan detected by Microsoft, which blocks access to the user's device and asks for a ransom so that they can continue to use it, for which it implements a new strategy.
The most interesting code protection strategy used by this malware consists of the use of Android Intents to make it difficult to read the code in charge of decrypting the text strings, which are encrypted in the code.
The use of Intents as an obfuscation measure is uncommon among other samples of Android malware, although it's a technique used to throw off analysts that may begin to be seen more frequently in the near future.
Code in charge of decrypting one of the text strings
In the previous image, you can see how the VfUdWt function creates a new Intent before decrypting the text string, which after being decrypted is used as an Intent action (using the setAction function).
Finally, the getAction method is called to obtain the decrypted string, storing it in the dcGsyDlOdlWg variable. The function that decrypts the string is actually XqNMSKlCmaxBQD, but by including the code to start an Intent, the idea is to throw off the analyst and make them waste their time.
In addition to the string encryption, the application includes the encrypted payload among the APK assets. As soon as execution begins, the encrypted file is loaded, decrypted, and execution of the malicious code begins.
In the following image you can see two functions that are used to read the content of the file in which the encrypted code is located, and that after being decrypted is saved in a new DEX file to be loaded and executed.
Functions to decrypt the code and save it as a .DEX file
As for blocking the device to request a ransom, this ransomware doesn't encrypt the files stored on the device, but instead blocks the device by displaying a message to the user with the instructions they must follow to make the payment and regain control of the device.
Blocked device message in Russian
This strategy to block access to devices is reminiscent of the strategies used by banking malware to show its injections, in which it shows a window with phishing web pages as soon as the user opens the app of the affected bank to steal their credentials. However, in this case, certain functionalities are used that allow this trojan to keep the window with the blocked screen message placed over every other window without the user being able to close it.
Specifically, the following image shows the code that allows this malware to keep the window with the blocked device message open, taking advantage of the notifications functionality to show a "call" type notification, which has the highest priority.
Furthermore, the use of ‘setFullScreenIntent’ allows the blocked device message to be displayed in full screen mode when the user interacts with the notification.
Code in charge of constantly displaying the blocked device window
To prevent the user from closing the ransomware screen, the ransomware uses the ‘onUserLeaveHint’ function, which is called by the system as soon as the user tries to close the window, allowing the attacker to show the message again and again.
The onUserLeaveHint function is called to prevent the user from closing the window
Android malware tends to follow the same path that malware for desktop systems has followed in recent years, systems for which ransomware is one of the main threats today.
Similar to desktop systems, malware developers have found ransomware to be a very lucrative new form of investment, allowing them to earn higher returns with less effort.
In this case, we are faced with a malicious application that implements ransomware functionality without encrypting the files of its victims; instead, access to the device is blocked using a pop-up window that the user can't close with instructions of how to pay the ransom.
In order to prevent the user from closing the blocked device window, it uses a functionality related to the management of notifications, something new that hadn't been seen before in other samples of this type.
The tricks used by this malware to hide its operations could be used by banking malware in the future to show the phishing injections that they usually use to steal the credentials of their victims, meaning it's important that we be on the lookout for new strategies that attackers may incorporate into their creations.