Mobile Ransomware: Pocket-Sized Badness
We delve into some of the technical aspects of prominent mobile ransomware variants, along with detection techniques to help mitigate these concerns.
Save to Folio
- 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 listAndroid 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 malwareWe 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 NougatThe 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 classAfter 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 cardMobile 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.