In our previous post, we looked at how malware can lock devices, as well as the scare tactics used to convince victims to pay the ransom. Now that we know what bad guys can do, we’ll discuss the detection and mitigation techniques that security vendors can use to stop them. By sharing these details with other researchers, we hope to improve the industry’s collective knowledge on mobile ransomware mitigation.
Detection and Mitigation
Looking at the technical features of mobile ransomware allows us to design and implement the appropriate detection and mitigation techniques. There are various ways to approach this problem: our view is that these malicious features must appear in the application’s code. We follow a static analysis approach, with some tricks to solve the typical corner cases (such as obfuscation through reflection).
Figure 1. Various mobile ransomware discovery approaches
The typical “threatening message” is clear and understandable, and includes detailed instructions to coerce the victim into paying. This can be detected through a machine-learning approach that automatically classifies text as “threatening” or “normal.” After a bit of pre-processing to remove stop words (e.g., “the,” “at,” “an”) and to reduce words to their basic form (e.g., “locked” becomes “lock”), we train a classifier on the remaining text, showing both samples of typically “threatening” text and samples of innocuous text. At the end of the day, the classifier will have learned how to distinguish safe from unsafe text.
The typical locking techniques are known and can be detected through lightweight symbolic execution. In particular, we search the app’s bytecode for all the subclasses of android.app.Activity that override the onKeyUp and onKeyDown methods. We then symbolically execute the code within these methods to find whether there are code paths that handle the home or back buttons (blue arrow in the figure below), and end up returning “true” (red arrow) which indicates that the event should not be propagated further. In turn, this means that no other apps (even the legitimate home-screen launcher) will be sent to the foreground.
Figure 2. Code paths handling buttons
To abuse the device administration API, an app needs to declare it in the manifest, linking to a separate file that defines the “policies” that are allowed for an administrator app. By focusing on the dangerous behaviors (e.g., reset password, force lock, wipe data and encrypt storage), we can explore the applications control-flow graph to spot whether there is a call to any of these methods without user intervention.
To this end, we use a customized version of FlowDroid, a powerful open-source tool for static analysis of Java and Android bytecode. Starting from all entry points, we visit the control-flow graph breadth first, looking for calls to lockNow() and other abused methods. If nothing is found, we give it a second chance and materialize the reflective calls, if any. We find all calls to the Java reflection API, and then work backward until we are able to reconstruct the name of the methods called “reflectively,” which are sometimes obfuscated. Once we identify the method names, we can include them as nodes in the control-flow graph, and draw edges accordingly. If the method names are obfuscated, we work our way up to the declaration of the String object that holds the (obfuscated) name, and then use reflection to re-execute all the subsequent statements until we reach the call to invoke().
Figure 3. Finding abuse of the device administration API
We detect unattended file encryption in a similar vein. More precisely, we’re interested in finding all the instances of the following pseudo-loop allowing, of course, for some variations:
For this we leverage FlowDroid’s flow analysis, configuring it to detect meaningful flows, for instance between listFiles() to CipherOutputStream(). In both encryption and device-administration API abuse analysis, we look for code paths that are not UI initiated, which means that no user intervention is necessary to activate such functionality. Otherwise we would detect (as false positives) all those legitimate apps for encrypting files on our devices.
Unfortunately, the whole process can take up to several minutes per app. By again using a machine-learning approach, we can pre-filter apps to determine, with good precision, which are absolutely safe. Those that are questionable can be further analyzed. This approach can cut the time required to process a batch of samples by one order of magnitude.
Trend Micro Solutions
Trend Micro keeps investing in advanced research techniques like the ones described in this post, to detect new ransomware variants quickly and provide protection to end users. For consumers, this is in the form of Trend Micro™ Mobile Security, which can block threats before they can be installed and cause damage to the user’s device or data.
Enterprise users should consider a solution like Trend Micro™ Mobile Security for Enterprise. This includes device management, data protection, application management, compliance management, configuration provisioning, and other features so employers can balance privacy and security with the flexibility and added productivity of BYOD programs.
Research Papers and Presentation
If this series of blog posts hasn’t satisfied your appetite for technicalities, here you can read the first research paper that presents the aforementioned detection and mitigation mechanisms.
- HelDroid: Dissecting and Detecting Mobile Ransomware Niccolò Andronio, Stefano Zanero, and Federico Maggi. In International Symposium on Research in Attacks, Intrusions and Defenses (RAID). Lecture notes in computer science. Kyoto, Japan, 382–404. DOI: http://dx.doi.org/10.1007/978-3-319-26362-5_18(October 2015) [PDF]
- Pocket-sized Badness: Why Ransomware Comes as a Plot Twist in the Cat-Mouse Game Federico Maggi and Stefano Zanero. Blackhat Europe (Peer-reviewed Talk), London, UK. (November 3, 2016) – Link: https://www.blackhat.com/eu-16/briefings.html[PDF]