Mobile Ransomware: Pocket-Sized Badness
A few weeks ago, I spoke at Black Hat Europe 2016 on Pocket-Sized Badness: Why Ransomware Comes as a Plot Twist in the Cat-Mouse Game. While watching mobile ransomware from April 2015 to April 2016, I noticed a big spike in the number of Android ransomware samples. During that year, the number of Android ransomware increased by 140%. In certain areas, mobile ransomware accounts for up to 22 percent of mobile malware overall! (These numbers were obtained from the Trend Micro Mobile App Reputation Service.) One trend noticed during this time is that it closely mirrors the path paved by traditional ransomware: like other ransomware types, mobile ransomware is constantly evolving and growing.
This research began during my time at Politecnico di Milano (POLIMI), and Trend Micro’s mobile research team has contributed substantially to this research. Below are some of the technical aspects of prominent mobile ransomware variants, along with detection techniques to help mitigate these concerns.
What makes mobile ransomware tick? Locks and Fear
From what my colleagues and I have analyzed, locking the screen and scaring victims into paying to regain access to their devices is all it takes to be successful for mobile ransomware. Let’s take a look at the most interesting techniques for screen or device locking.
Locking the screen
The SMSLocker family (detected as ANDROIDOS_SLOCKER or ANDROIDOS_SMSLOCKER) was the beginning of what we now consider Android ransomware. Originally it didn’t use encryption, but simply hid targeted files beyond the reach of everyday users. The 2015 variant used encryption with per-device keys, which made it quite difficult to create a generic “unlocker.” It mostly uses SMS for command and control (C&C) communication; some variants use Tor. The biggest contribution that SLocker made to mobile ransomware was the abuse of the Android UI API to lock the device screen. This was the first time I saw malware taking control of a device using this technique, which can be summarized as follows based on the KeyEvent.Callback API call:
- Bind the callback onKeyDown() and/or onBackPressed() functions,
- Callbacks are triggered whenever the victim presses physical buttons,
- According to the API, by returning “true” to the next callback in the chain (which means, “do not propagate, the event has been handled already”), the app effectively prevents the current activity from moving into the background.
Figure 1. Documentation of the onKeyDown() function in the Android package index list
Android ransomware now commonly uses this technique to make the device unusable to an inexperienced user. Rebooting does not necessarily solve the problem, especially if the malware family uses persistency techniques. However, an experienced user can still uninstall the malicious app.
The current state-of-the-art locking technique is based on abusing the device-administration APIs. The attacker can leverage it to surreptitiously change the passcode with a randomly generated one to lock the device. While the device-administration APIs have a legitimate use case (that is, allowing enterprises to manage their employees’ devices) they offer an interesting attack surface.
For instance, the sample with the hash a6dedc5f639b2e1f7101d18c08afc66d (detected as ANDROIDOS_FAKETOKEN.FCA) uses this technique. The first place to inspect is the manifest, which must declare (and ask permission for) the usage of the API methods of interest:
Figures 2 and 3. Portions of example app manifest where the device-administration API permission and policy are requested.
The manifest above is sample code from the Android developer guide. If we dig into the (disassembled and decompiled) code of the aforementioned malware sample, we find this:
Figures 4 and 5. Code snippets from the malware
We find a call to the lockNow() function to lock the device, and, on another object method, a call to the removeActiveAdmin() function, which is needed to “remove” device-administering app (i.e., the malware). Before calling the lockNow() method, ransomware samples typically call the resetPassword() function, which forcefully change the passcode. LockDroid.E uses a randomly generated passcode, which is essentially the secret information that the criminal sends to victims upon receiving the payment.
The upcoming version of Android, Android 7.0 Nougat, has a countermeasure for this. Digging into the code reveals that Nougat checks whether there is a passcode already set by the user. If that is the case, no device-admin app—regardless of whether it is legitimate or not—is allowed to change or reset it.
Figure 6. Code from Android 7.0 Nougat
The above variants and techniques provide insight into how malware developers are able to lock mobile devices via modern ransomware. So how do attackers get their victims to pay?
How Mobile Ransomware Uses Fear to Win
When talking about how ransomware uses the fear factor, one interesting family to look at is Koler (detected as ANDROIDOS_KOLER). Although a fairly standard family from a purely technical perspective, it uses an extensive distribution network with localization for about 60 countries. The obligatory ransomware “warning” appears to the victim as if it were actually coming from local law enforcement agencies. This effort in creating well-localized campaigns is, of course, intended to persuade victims to pay the requested fee.
Figure 7. Ransomware warnings in various languages (Click to enlarge)
(Images provided by Kafeine)
The English version goes along the lines of the following example:
Figure 8. English-language ransomware warning (Image provided by Kafeine)
This ransom note is accompanied by the obligatory payment screen, similar to that seen here:
Figure 9. Ransomware payment screen (Image provided by Kafeine)
Another family that must be mentioned is Svpeng (detected as ANDROIDOS_SVPENG). It may have begun as a banking Trojan, but the 2,000 samples we analyzed now exhibit the classic features of modern mobile ransomware. For instance, here is how the encryption routine works:
Figure 10. Obtaining a Cipher class
After obtaining an instance of the Cipher class, the sample loops through all the files found on the SD card and encrypts them. This effect is similar to ransomware on the Windows platform: files that have been stored on the device are now inaccessible.
Figure 11. Searching for and encrypting files on the SD card
Mobile ransomware has adapted the very same tactics that made desktop ransomware such a potent threat, raking in millions of dollars for the persons responsible. How do we detect and block these threats? That is something we will discuss in our next blog post.
Incoming search terms