FortiGuard Labs Threat Research
Royal Ransomware Targets Linux ESXi Servers
FortiGuard Labs has repeatedly warned organizations about ransomware developers' increased targeting of Linux systems. So it came as no surprise when it was reported that a new Royal Ransomware variant has started targeting Linux machines. In this blog post, you will learn about the technical details of this new Linux version.
Affected Platforms: Linux, Unix, ESXi
Impacted Users: Linux and Virtual Machine Users
Impact: Most files on the compromised machines are encrypted, including virtual machines
Severity Level: Medium
Command Line Parameters
The functionality of the Linux version of Royal Ransomware looks pretty similar to the Windows version. However, it includes some additional functionality to target virtual machines. The sample we analyzed provided the following command line parameters:
-id <32 character string>: A 32-character identification string added to the URL in the ransom note identifies the target. This is a compulsory parameter, and the ransomware does not run without it.
-ep <percentage>: This parameter defines the portion of each targeted file to be encrypted. Many ransomware operators implement performance optimization strategies that do not encrypt an entire file, thus allowing the ransomware to run faster. In this sample, we found a straightforward implementation of such a strategy. Files smaller than 5,245,000 bytes are always encrypted 100%. For larger files, if the -ep parameter is used then plain and encrypted sections alternate in a way to reach the pre-chosen encryption percentage.
-stopvm: This function stops virtual machines from running on the target system, probably to allow the ransomware to release the locking of related files and encrypt them.
-vmonly: The name of this parameter indicates it only encrypts virtual machines. However, in the analyzed sample, this parameter did not do anything. This may be a feature that is currently being implemented.
-fork: This parameter defines whether the main process should fork itself and allow the child process to do the rest of the work.
-log: Sends logs to stdout.
Interaction with Virtual Machines
The Linux version's ability to interact with virtual machines seems to be the primary difference from the Windows versions. Currently, only the -stopvm function is implemented. However, the unfinished -vmonly parameter indicates there is more to come. When -stopvm is chosen, the stop_vm() function (Figure 1) is called, which executes the following actions before encryption is started:
Figure 1 - Code snippet from the stop_vm() function.
1) It lists the virtual machines using the following shell command:
esxcli vm process list > list
2) It then opens the created file called ‘list’ and parses out the listed ‘World IDs’.
3) In a child process, it then executes the following command with each World ID:
esxcli vm process kill --type=hard --world-id=%s
This process shuts down all running virtual machines, allowing the ransomware to encrypt these machines as well.
Execution
The ransomware is deployed using the following command:
# ./sample <target folder> -id <32 character ID> [other command line parameters]
A target folder must be selected. Otherwise, the sample will exit before encryption. The sample we examined does not have a folder exclusion list, meaning that running the ransomware on the root folder with root privileges would corrupt the operating system. These attributes suggest that the ransomware is executed either manually or by a dropper program that specifies which folders should be encrypted. A simple execution flow looks like this:
1) Encryption test: The program runs an encryption test before doing anything else. This is probably a quality assurance function to ensure that file encryption will be clean and not corrupt the files. This could indicate that the threat actor is serious about the business and wants to ensure that recovery is possible.
2) Command line parameters: The program parses the command line parameters and stores their values for the rest of the execution.
3) Initializing a thread pool (Figure 2): A thread pool is created to execute encryption later. A separate thread is created for every online CPU core the machine has. Each thread runs the same thread_func() function.
Figure 2 - Function to initialize thread pool.
4) Searching target files: search_files()function starts from the selected root directory and recursively searches for files. The exclusion list shown in Figure 3 ensures that files that were previously encrypted are not encrypted again and that the ransom note (readme) is not encrypted. The full path of allowed files is put in a queue to enqueue them for the worker threads.
Figure 3 - Encryption exclusion list.
5) Encryption: Threads in the thread pool monitor the queue of target files. When something is in the queue, a worker thread will pop the file from there and start encryption. The encryption is described in detail in the next section.
6) Renaming: As a final step, files are renamed to include the .royal_u postfix (Figure 4).
Figure 4 - .royal_u postfix is added to the filenames.
Encryption
The worker threads perform the encryption. Once a thread pops a new file from the queue, it starts the encryption process on that file as follows:
1) An RSA public key is loaded: An RSA public key was hardcoded in the sample we analyzed. The key is used to encrypt the AES keys that encrypt the files.
2) Random values are generated: For each file, a 32-byte random value is generated that serves as the AES file key and a 16-byte value that serves as the initialization vector for the AES encryption.
3) The file key is encrypted: The generated file key is encrypted using the RSA public key.
4) The file is encrypted: The file key is then used to encrypt the file using the AES CBC algorithm. If the file is bigger than 5245000 bytes (~5 MB), and the -ep parameter was set, then only the preselected percentage of the file is encrypted alternatingly, as shown in Figure 5.
Figure 5 - 50% encrypted file. The black part is the original unencrypted content (0x0 bytes).
5) The key is concatenated to the encrypted file: Once the encryption is finished, the following three values are concatenated to the file:
a. Encrypted file key: The decryptor probably loads and decrypts this key to decrypt the file content.
b. Original file size: The file is resized to accommodate this additional information, thereby preserving the original file size for recovery.
c. -ep value: The percentage of the file that was encrypted is also preserved for recovery.
Figure 6 - Hex dump of an encrypted file, showing the added values at the end.
Figure 6 shows the hex dump of a file filled with 0x0 that was encrypted by the ransomware. The -ep value was set to 50% (0x32 in hexadecimal is 50% in decimal). At the end, we see the concatenated encrypted file key, the original file size, and the encryption percentage. All this information may be needed for the decryptor to decrypt this file.
The ransom note (Figure 7) is dropped in every folder under the name readme.
Figure 7 - Ransom note.
Victimology
Our FortiRecon Adversary-Centric Intelligence service is currently tracking 103 active victims of the Royal Ransomware group, primarily targeting the United States.
Figure 8 - Top sectors targeted by the Royal Ransomware
Figure 9 - Top Countries Targeted
Conclusion
This report shows that threat actors are actively pivoting to attack Linux/Unix environments. Although the sophistication of this sample is not comparable to state-of-the-art Windows ransomware—it doesn’t include defensive evasion, anti-analysis, etc.—it is still very effective. We expect further development from this actor and more ransomware operators turning towards targeting Linux systems.
Fortinet Protections
Fortinet customers are already protected from this malware through FortiGuard’s AntiVirus, FortiMail, FortiClient, and FortiEDR services, as follows:
The following (AV) signature detects the malware samples mentioned in this blog
Linux/Filecoder_Royal.A!tr
FortiEDR also detects and mitigates the execution of ransomware through a combination of behavioral analysis and integration with machine learning and threat intelligence feeds.
Fortinet has multiple solutions designed to help train users to understand and detect phishing threats:
The FortiPhish Phishing Simulation Service uses real-world simulations to help organizations test user awareness and vigilance to phishing threats and to train and reinforce proper practices when users encounter targeted phishing attacks.
We also suggest that organizations have their end users undergo our FREE NSE training: NSE 1 – Information Security Awareness. It includes a module on Internet threats designed to help end users learn how to identify and protect themselves from various types of phishing attacks.
If you think this or any other cybersecurity threat has impacted your organization, contact our Global FortiGuard Incident Response Team.
Learn more about Fortinet’s FortiGuard Labs threat research and intelligence organization and the FortiGuard AI-powered security services portfolio.
IOCs
b57e5f0c857e807a03770feb4d3aa254d2c4c8c8d9e08687796be30e2093286c – SHA256 hash of the analyzed sample
hxxp://royal2xthig3ou5hd7zsliqagy6yygk2cdelaxtni2fyad6dpmpxedid[.]onion – Royal Ransomware Portal
