Lucy’s Back: Ransomware Goes MobileApril 28, 2020
Research by: Ohad Mana, Aviran Hazum, Bogdan Melnykov, Liav Kuperman
Ransomware attacks have been a part of the security landscape for a long time. We are familiar with infamous malware such as CryptoLocker, WannaCry and Ryuk, all of which have caused enormous damage to organizations and private assets globally. And while ransomware has just started to take its first steps in the mobile world, it’s evolving fast as malware developers and attackers apply the experience they have gained to create disruptive mobile ransomware attacks.
An example is the ‘Black Rose Lucy’ malware family, originally discovered in September 2018 by Check Point. Lucy is a Malware-as-a-Service (MaaS) botnet and dropper for Android devices. And now, nearly two years later, it is back with new ransomware capabilities that allow it to take control of victims’ devices to make various changes and install new malicious applications.
When downloaded, Lucy now encrypts files on the infected device and displays a ransom note in the browser window which claims to be an official message from the US FBI, accusing the victim of possessing pornographic content on his device. The message also states that as well as locking the device, the user’s details have been uploaded to the FBI Cyber Crime Department’s Data Center, accompanied by a list of legal offenses that the user is accused of committing. The victim is then instructed to pay a US$500 “fine” – unusually, by providing their credit-card information, and not via the more common method of using BitCoin.
In this follow-up research, Check Point researchers have discovered more than 80 samples that were distributed mainly via social media links and IM apps associated with this new active Lucy variant in the wild.
At First Glance
The Android operating system only allows users to carry out a manual configuration to enable an application to have device administrator privileges. It explicitly asks for user consent in a pop-up window, or asks the user to navigate through a series of system settings before such privileges are granted.
However, the Android accessibility service, which mimics a user’s screen clicks and has the ability to automate user interactions with the device, could be used by malware to get around these security restrictions. Accessibility services are normally used to allow users to automate and simplify certain repeated tasks. With Lucy, it’s the Achilles Heel in the Android’s defensive armour.
Lucy uses a cunning method to slip inside the Android device and take down its defenses. It displays a message asking the user to enable SVO (Streaming Video Optimization). By clicking ‘OK’, the user grants the malware the permission to use the accessibility service. Now Lucy is ready to initiate its malicious plan to encrypt the data on the victim’s device.
Figure 1. The malware’s popup message tricks the victim into enabling the accessibility service.
Taking A Closer Look: Technical Analysis of the Lucy Ransomware
When we got a lead from a tweet by Tatyana Shishkova (@sh1shk0va), an Android malware researcher stating that the Black Rose Lucy is back, we sprung into action. We collected samples and started our research and analysis.
We found that the samples we acquired disguised themselves as a harmless-looking video player application, primarily leveraging Android’s accessibility service to install their payload without any user interaction and created an interesting self-protection mechanism.
The malware starts by registering a receiver called “uyqtecppxr” to run BOOT_COMPLETE and QUICKBOOT_POWERON to check if the country code of the device is from a former Soviet state.
Lucy then tries to trick the victim into enabling the Accessibility Service by initiating an Alert Dialog that asks the user to take action.
Inside the MainActivity module, the application triggers the malicious service, which then registers a BroadcastReceiver that is called by the command action.SCREEN_ON and then calls itself. This is used to acquire the ‘WakeLock’ service, which keeps the device’s screen on, and ‘WifiLock’ service, which keeps the WIFI on.
The malware has 4 encrypted command and control (C&C) servers in its code. Unlike previous versions of the malware, the C&C is a domain and not an IP address. Therefore, although the server can be taken down, it can easily be resolved into a new IP address, which makes it much harder to neutralize the malware.
The C&C servers are held as a long string which is a concatenation of all C&Cs hardcoded in the malware’s code, followed by a bulk of unused data.
Figure 2. The concatenation of all C&C servers in the malware’s code followed by a bulk of unused data.
Figure 3. The malware’s C&C servers.
The malware rotates between the C&Cs and each one is called by a different API with a different URI.
Figure 4. The malware shifts between C&C servers and URIs.
Command & Control:
The C&C server can send different commands for the malware to iterate and execute on the victim’s device. The list of commands that this malware recognizes can be seen in the table and screenshot below:
|Call||Initiates a phone call to a number it gets from the C&C server.|
|GetCrypt||Collects a string called “key” from the C&C response.
It then calls another service that tries to fetch an array of all the device’s directories.
|Similar to ‘GetCrypt’ but used for decryption.|
|GetCont||Declines previous payment – shows a message that the payment was declined.|
|GetApp||Sends a list of all installed applications to the C&C server.|
|Delloc||Empties the variable used in the request to the C&C server (on the sample we investigated, there was no assignment for this variable, so no actual functionality was seen).|
|DelKey||Empties all variables that contain encryption keys|
|Deleted||The malware deletes itself from the device.|
|StartShell||Opens a remote shell on the device with the commands as arguments.|
The malware receives a string called ‘Key’ as a response from the C&C server. This string is divided into 2 segments by this delimiter: //
Next, a new service is called, which initially tries to fetch an array of all the device’s directories. In the case of failure, it tries to fetch the directory /storage. As last resort, it tries to fetch the /sdcard directory.
Figure 5 The malware tries to fetch the victim’s device directories.
The encryption process begins by iterating over the files in the directory array it received at the previous stage.
Before encrypting the files, the malware performs a few checks, such as length and permissions, to make sure the file can be encrypted\decrypted. It also later checks if the file was successfully encrypted.
One interesting action that Lucy performs during the encryption process is initiating a key generator with a (false) key using an AES algorithm with a constant seed of 0x100. This action later appears to be a false lead, as the result is not even saved in a variable.
We prefer to give the actor behind this malware the benefit of the doubt, and assume this is a decoy action, designed as bait for anyone trying to analyze the malware’s mechanism. However, we cannot ignore the possibility that this might just be a careless mistake.
Figure 6. Generating the false key.
The actual encryption key is composed of the first segment of the ‘SecretKeySpec’ string, which is the ‘key’ string mentioned in the first stage, together with another string, called ‘Key’ that is fetched from SharedPreferences.
These keys, together with the directory array and a Boolean variable which acts as a switch between encryption and decryption modes, are later joined as parameters that are sent to the encryption/decryption function.
Figure 7. The malware’s encryption/decryption function.
When the malware has finished encrypting the desired files on the device and performed all the checks to verify that the files were encrypted successfully, it displays a ransom note in the browser window.
The ransom note pretends to be an official message from the US Department of Justice Federal Bureau of Investigations (FBI) and accuses the victim of possessing pornographic content on his device. As a result, all content on the device is encrypted and locked.
In addition, the message states that the victim’s details are now uploaded to the FBI Cyber Crime Departments Data Center, followed by a list of legal offenses that the victim is accused of committing.
Figure 8. Lucy’s ransom note.
The encryption and decryption processes are very similar, except for minor changes such as adding (encryption) or removing (decryption) the .Lucy extension from the end of the file, as well as the value of the Boolean parameter that is called with the function.
In both the encryption and the decryption processes, we see the role of every key component we previously encountered.
The ‘SecretKeySpec’, which is the first part of the encryption key and taken from the C&C server’s response in the first stage, together with the ‘key’ string that is fetched from the SharedPreferences, make up the encryption/decryption key.
When the decryption process is complete, the malware sends logs to inform that all of the files were decrypted successfully. The malware then changes the current command to “Delete” and proceeds to delete itself.
Although we have not yet seen many mobile ransomware out there, we have observed an evolution. Mobile ransomware is getting more and more sophisticated and efficient, as shown by Lucy, and this represents an important milestone in the evolution of mobile malwares. Sooner or later, the mobile world will experience a major destructive ransomware attack.
Stay Protected from Mobile Threats
Check Point SandBlast Mobile is A Mobile Threat Defense (MTD) solution, providing the widest range of capabilities to help you secure your mobile workforce. SandBlast Mobile provides protection for all mobile vectors of attack, including the download of malicious applications and applications with malware embedded in them. Learn more.
- C&C Servers: