Android Mobile Ransomware: Bigger, Badder, Better?
By Lorin Wu (Mobile Threat Analyst)
The mobile threat landscape isn’t just rife with information stealers and rooting malware. There’s also mobile ransomware. While it seems they’re not as mature as their desktop counterparts, what with the likes of WannaCry and Petya, the increasing usage of mobile devices, particularly by businesses, will naturally draw more cybercriminal attention to this type of threat.
Take for instance mobile ransomware on the Android platform. The variants we detected and analyzed during the fourth quarter of last year were thrice as many compared to the same period in 2015. And indeed, the surge is staggering. We already had over 235,000 detections for Android mobile ransomware in the first half of 2017 alone—that’s 181% of detections for all of 2016.
The recent spate of screen-locking and file-encrypting malware targeting Android devices also underscores the increasing prevalence of mobile ransomware. Some of these include SLocker copycatting WannaCry and abusing legitimate social networks, and LeakerLocker threatening to expose victims’ personal data. And now that SLocker’s decompiled source code was reportedly leaked on GitHub, we’re bound to see more of these threats.
So how is Android crypto-ransomware shaping up so far? What is its outlook in the mobile threat landscape?
From screen lockers to file-encrypting malware
A typical Android mobile ransomware was fairly simple back then. It locked the device’s screen and overlaid it with a ransom note. Its evolution into crypto-ransomware came in May 2014 in the form of Simple Locker (ANDROIDOS_SIMPLOCK.AXM), which was capable of encrypting files stored on the mobile device and its SD card. We’ve since seen similar threats—and some variants, which are just repackaged versions of the original malware—reappear in third-party app marketplaces. Others were actively pushed and updated to elude detection. In fact, we even saw how one malware author fixed a bug in his ransomware last May, updating an argument judgment related to how the ransom note is displayed and where to retrieve it.
Android Crypto-Ransomware and Its Evolution
But what exactly makes up an Android crypto-ransomware? Since the first crypto-ransomware turned up in May 2014, we have monitored and analyzed file-encrypting Android mobile malware and found several properties common among them.
Icon and Label. Most use ‘Adobe Flash Player,’ ‘Video Player,’ and many popular gaming apps’ names as their labels, and Android’s default icon or Adobe Flash Player’s for icons. The label and icon match their infection vectors: gaming and video-watching apps. Note though that Flash hasn’t been available on Android for at least five years now.
Package Name. Android apps consist of packages, and they must include a main package with a specified name. It’s a way to distinguish an app from others and even from versions of itself (i.e., when it’s upgrading/updating). We’ve found that package names for pre-installed apps such as Email, Calendar, and browsers, have been spoofed by many mobile crypto-ransomware. A typical package name would be ‘com.common.calendar.’ And since it’s associated with a legitimate app, it can dissuade users from uninstalling them.
Targets. Crypto-ransomware have a more global reach but are also pinpointing targets. They even have custom user interfaces (UI), especially when they’re distributed in Middle Eastern countries. Based on decompiled code and sandboxing analyses, we saw how these threats are becoming more specific with their targets. The Simple Locker we detected in May 2014, for instance, was written in Russian, but the ransom it demanded was in hryvnias, Ukraine’s currency. It’s fair to assume that this malware targeted Android device users in that country. There was also the WannaCry-mimicking Android ransomware which preferred payment via Alipay, WeChat, and QQ, suggesting it primarily targeted Chinese users.
Another case in point: the crypto-ransomware we found in United Arab Emirates, Saudi Arabia, and Iran. The malware retrieves the device’s system language and network operator in order to choose the right UI to display. It misused the Extensible Messaging and Presence Protocol (XMPP) for communication.
Encryption. The algorithm typically employed is AES because of performance. The targeted file types have also increased over time. It was 13 back in May 2014 but has grown into 78 by the end of that year. Before, ciphers were hardcoded programs or stored in shared_pref (where application preferences are retrieved), so it was fairly easy to decrypt scrambled data. Now, most of the ciphers can be customized and stored in remote servers.
Decryption Channel. While the ways scrambled files are decrypted have also evolved over the years, they share a certain process: remote server verification. A short message with the strings “stop” or “stopper” in the content will be received via network communication and gets verified by the remote server.
Command and Control (C&C) Communication. C&C communication in mobile crypto-ransomware has also expanded to using HTTP/S, TOR, and XMPP. In HTTP/S, an encryption key is first retrieved from the C&C before encryption is triggered. This is a disadvantage for bad guys, as these C&C servers can be easily detected and blocked. Tor’s hidden service was employed to anonymize their activities.
The use of XMPP, a common instant messaging protocol, has increased among mobile crypto-ransomware. Using XMPP makes it more challenging to trace C&C communication because of how it blends with legitimate XMPP traffic. It also makes it difficult to block traffic by monitoring suspicious URLs. Messages are also encoded with customized keys.
Routines Beyond File Encryption. By mid-2015, many Android ransomware added malicious functionalities beyond file encryption so cyberattackers can cash in more on their victims. The first of these were sending SMS and calling attacker-specified numbers. Attackers also kept the devices on silent mode so they can perform the actions without the victim’s knowledge or consent.
Table 1: Set of commands from a sample Android mobile ransomware
These added functionalities are losing traction though, as these need user permissions and call/invoke-related application program interfaces (APIs), which can be detected by Android’s system itself and by security products (if there’s any installed). Users can also identify these malicious routines, especially if they ask for unrelated/suspicious permissions.
Figure 10: Code snippets showing SMS and dialing behaviors on a sample we analyzed last December 2014
Figure 11: Snippet showing SMS and dialing behaviors removed by July 2015 (note the strings in the code)
Persistence. Many malware are coded to persist within the infected system or device to maximize its impact, and Android mobile ransomware aren’t an exception. Posing as system icons and spoofing legitimate packages are some examples, but the most notable technique we saw is requesting device administrator privileges. This feature is typically used in enterprise applications, such as BYOD management apps. The uninstall process for apps with device administration permission is lengthy and complicated, which is probably why cybercriminals have misused device administrator privileges as a persistence mechanism. This is compounded by how attackers can hijack the lock screen as well as Back, Home, and Menu buttons.
Evasion. Code obfuscation was an unfamiliar feature back then, but now we’re seeing more sophistication in how cybercriminals obscure the ransomware’s source code. Many of the malware we’ve analyzed now have useless invokes/calls inserted into every code string as well as encoded parameters. Configurations are also customizable and encrypted to further obfuscate the malware.
Ransomware is bound to be a staple in mobile platforms as its user base becomes a more viable, cybercriminal cash cow. And based on its evolution since first cropping up in 2014, mobile crypto-ransomware will add other attack vectors into the mix—the use of API vulnerability exploits, for instance. Thankfully, new security features are being rolled out in Android Oreo, particularly Google Play Protect, which analyzes apps for behaviors such as malicious file encryption. Downloader apps, for example, will now be required to have permissions; users must directly permit the installation of Android Application Packages per source.
As Android crypto-ransomware become bigger and badder, businesses and everyday users stand to lose more than access to corporate and personal data. Keep your OS patched and updated, or ask your OEM for patch availability. Adopt best practices for mitigating mobile ransomware and securing your mobile device, especially when working in a Bring Your Own Device environment. App developers and OEMs should do the same by incorporating security in their applications.
Trend Micro Solutions
End users and enterprises can also benefit from multilayered mobile security solutions such as Trend Micro™ Mobile Security for Android™ (available on Google Play). Trend Micro™ Mobile Security for Enterprise provides device, compliance and application management, data protection, and configuration provisioning, as well as protects devices from attacks that leverage vulnerabilities, preventing unauthorized access to apps, as well as detecting and blocking malware and fraudulent websites.