Ryuk is one of the most well-known ransomware variants in recent years. Since its first appearance in the summer of 2018, it has amassed , particularly in the business sector, which is its primary target.
1. General Information
This document contains an analysis of the Ryuk ransomware variant, as well as the loader responsible for delivering the malicious program to the system.
The Ryuk ransomware first appeared in the summer of 2018. One of the distinguishing features of Ryuk is its targeting of corporate environments.
In mid-2019, cybercriminal groups attacked a large number of Spanish companies using this ransomware.
Fig. 1: Extract from El Confidencial regarding the Ryuk ransomware attack [1]
Fig. 2: Extract from El País about the attack carried out with the Ryuk ransomware [2]
This year, Ryuk has targeted a significant number of companies across various countries. As shown in the figures below, the hardest-hit countries were Germany, China, Algeria, and India.
Comparing the number of cyber attacks, we can see that millions of users have been affected by Ryuk, compromising a vast amount of data and resulting in significant economic damage.
Fig. 3: Illustration of Ryuk's global activity.
Fig. 4: 16 countries most affected by Ryuk
Fig. 5: Number of users attacked by the Ryuk ransomware (in millions)
According to the usual operation principle of such threats, this ransomware displays a ransom notice to the victim after the encryption is completed, which must be paid in bitcoins to a specified address to regain access to the encrypted files.
This malicious program has evolved since its initial appearance.
The variant of this threat analyzed in this document was detected during an attempted attack in January 2020.
Due to its complexity, this malicious program is often attributed to organized cybercriminal groups, also known as APT groups.
Part of the Ryuk code shows a notable resemblance to the code and structure of another well-known ransomware, Hermes, with which it shares several identical features. This is why Ryuk was initially linked to the North Korean group Lazarus, which at the time was suspected of being behind the Hermes ransomware.
Subsequently, CrowdStrike's Falcon X noted that Ryuk was actually developed by the WIZARD SPIDER group [4].
There is several evidence supporting this assumption. Firstly, this ransomware was advertised on the exploit.in website, known as a Russian marketplace for malware and previously linked to several Russian APT groups.
This fact undermines the theory that Ryuk could have been developed by the Lazarus APT group, as it contradicts their operational methods.
Additionally, Ryuk was advertised as ransomware that would not operate on systems in Russia, Ukraine, or Belarus. This behavior is defined by a function found in some versions of Ryuk, which checks the system language when the ransomware is launched and halts its operation if the system is in Russian, Ukrainian, or Belarusian. Finally, during an expert analysis of the machine that was compromised by the WIZARD SPIDER group, several 'artifacts' were discovered, which were presumably used in the development of Ryuk as a variant of the Hermes ransomware.
On the other hand, experts Gabriela Nicolaou and Luciano Martins suggested that the ransomware may have been developed by the CryptoTech APT group [5].
This is derived from the fact that a few months before Ryuk appeared, this group posted on the same forum information that they had developed a new version of the Hermes ransomware.
Several forum users questioned whether CryptoTech really created Ryuk. Afterward, the group defended itself, claiming to have evidence that they developed 100% of this ransomware.
2. Characteristics
We start with the loader, whose purpose is to identify the system it is running on so that the 'correct' version of the Ryuk ransomware can be launched.
The loader's hash is as follows:
MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469
One of the features of this loader is that it does not contain any metadata, meaning the creators of this malware did not include any information in it.
Sometimes they include erroneous data to make the user think they are supposedly running a legitimate application. However, as we will see later, if the infection does not involve user interaction (as is the case with this ransomware), then the attackers do not deem it necessary to use metadata.
Fig. 6: Metadata of the sample
The sample was compiled in a 32-bit format, allowing it to run on both 32-bit and 64-bit systems.
3. Infection Vector
The sample that downloads and runs Ryuk entered our system via a remote connection, and the access parameters were obtained through a preliminary RDP attack.
Fig. 7: Attack Registry
The attacker was able to log into the system remotely. After that, they created an executable file with our sample.
This executable file was blocked by the antivirus solution before it could run.
Fig. 8: Sample Blocked
Fig. 9: Sample Blocked
When the malicious file was blocked, the attacker attempted to download an encrypted version of the executable file, which was also blocked.
Fig. 10: Set of samples the attacker attempted to launch
Finally, they tried to download another malicious file through an encrypted console
PowerShell to bypass antivirus protection. But it was also blocked.
Fig. 11: PowerShell with blocked malicious content
Fig. 12: PowerShell with blocked malicious content
4. Loader
When executed, it writes a ReadMe file to the folder %temp%, which is typical for Ryuk. This file is a ransom note containing an email address in the protonmail domain, which is quite common in this family of malware: msifelabem1981@protonmail.com
Fig. 13: Ransom Note
During the loader's execution, you may notice that it runs several executable files with random names. They are stored in a hidden folder PUBLIC, but if the operating system does not have the option activated "Show hidden files and folders", they will remain hidden. Moreover, these files are 64-bit as opposed to the parent file, which is 32-bit.
Fig. 14: Executable files run by the sample
As you can see in the figure above, Ryuk executes icacls.exe, which is used to change all access control lists (ACLs), thereby ensuring access and modification of the flags.
It gains full access under all users to all files on the device (/T), regardless of errors (/C) and without displaying any messages (/Q).
Fig. 15: Execution parameters of icacls.exe run by the sample
It is important to note that Ryuk checks which version of Windows is running. To do this, it
performs a version check using GetVersionExW, where it checks the value of the flag lpVersionInformation, indicating whether the current version of Windows is more recent than Windows XP.
Depending on whether you have a version later than Windows XP, the loader will write to the local user's folder — in this case, to the folder %Public%.
Fig. 17: Operating system version check
The file being written is Ryuk. It then executes it, passing its own address as a parameter.
Fig. 18: Executing Ryuk via ShellExecute
The first thing Ryuk does is obtain the input parameters. This time there are two input parameters (the executable file itself and the dropper address), which are used to erase its own traces.
Fig. 19: Creating a process
You can also see that as soon as it runs its executable files, it deletes itself, leaving no traces of its presence in the folder where it was executed.
Fig. 20: Deleting the file
5. RYUK
5.1 Presence
Ryuk, like other malware, tries to remain in the system for as long as possible. As shown above, one way to achieve this goal is through stealthily creating and executing files. For this, the most common practice is to modify the registry key CurrentVersionRun.
In this case, you can see that for this purpose the first executable file VWjRF.exe
(the file name is generated randomly) runs cmd.exe.
Fig. 21: Executing the VWjRF.exe file
Then, the command is entered RUN with the name "svchos". Thus, if you want to check the registry keys at any time, you can easily overlook this change, considering the similarity of this name to svchost. This key allows Ryuk to establish its presence in the system. If the system has not been infected yet, when you reboot the system, the executable will try again.
Fig. 22: Sample shows presence in the registry key
We can also see that this executable stops two services:
"audioendpointbuilder", which, as the name suggests, corresponds to the system audio,
Fig. 23: Sample stops the system audio service
and samss, which is the account management service. Stopping these two services is characteristic of Ryuk. In this case, if the system is connected to a SIEM system, the ransomware attempts to prevent any alerts from being sent to . Thus, it protects its next steps, as some SAM services will not be able to start properly after Ryuk has executed.
Fig. 24: Sample stops the Samss service
5.2 Privileges
Generally speaking, Ryuk begins with lateral movement within the network or it is triggered by another malware program, such as or , which, in cases of privilege escalation, pass these elevated rights to the ransomware.
Preliminary, as a prelude to the injection process, we see that it executes the process ImpersonateSelf, which means that the security content of the access token will be passed into the thread, where it will be immediately obtained using GetCurrentThread.
Fig. 25: Call to ImpersonateSelf
Then we see that it will link the access token to the thread. We also see that one of the flags is DesiredAccess, which can be used to control the access that the thread will possess. In this case, the value that edx will receive should be TOKEN_ALL_ACCESS or otherwise — TOKEN_WRITE.
Fig. 26: Creation of the thread token
It will then use SeDebugPrivilege and make a call to obtain debugging rights concerning the thread, resulting in specifying PROCESS_ALL_ACCESS, allowing access to any required process. Now, considering that the ransomware already has a prepared thread, it only remains to proceed to the final stage.
Fig. 27: Calling SeDebugPrivilege and privilege escalation function
On one hand, we have LookupPrivilegeValueW, which provides us with the necessary information about the privileges we want to elevate.
Fig. 28: Requesting privilege information for escalation
On the other hand, we have AdjustTokenPrivileges, which allows us to obtain the necessary rights for our thread. In this case, the most important is the NewState, whose flag will grant the privileges.
Fig. 29: Configuring rights for the token
5.3 Injection
In this section, we will demonstrate how the sample executes the injection process previously mentioned in this report.
The primary goal of the injection process, like that of escalation, is to gain access to shadow copies. To do this, it needs to operate with a thread that has higher rights than those of the local user. Once it obtains such elevated rights, it will delete the copies and make changes to other processes to ensure that it cannot revert to an earlier restore point in the operating system.
As is often the case with this type of malware, to perform injection it uses CreateToolHelp32Snapshot, allowing it to take a snapshot of currently running processes and attempt to access those processes using OpenProcess. Once it gains access to a process, it also opens a token with its information to retrieve the process parameters.
Fig. 30: Retrieving processes from the computer
We can dynamically see how it retrieves the list of running processes in subroutine 140002D9C using CreateToolhelp32Snapshot. After obtaining them, it iterates through the list, trying to open processes one by one using OpenProcess until it successfully does so. In this case, the first process it was able to open is "taskhost.exe".
Fig. 31: Dynamic execution procedure for obtaining a process
We can see that subsequently it reads the process token information, calling OpenProcessToken with the parameter "20008"
Fig. 32: Reading process token information
It also checks that the process it will inject into is not csrss.exe, explorer.exe, lsaas.exe or that it has the set of rights NT authority.
Fig. 33: Excluded processes
We can dynamically see how it first performs a check using the process token information in 140002D9C to determine whether the account whose rights are used to execute the process is an account NT AUTHORITY.
Fig. 34: Checking NT AUTHORITY
And later, outside the procedure, it checks that it is not csrss.exe, explorer.exe or lsaas.exe.
Fig. 35: Checking NT AUTHORITY
After taking a snapshot of the processes, opened the processes and checked that none of them are excluded, it is ready to write to memory the processes to be injected.
To do this, it first reserves an area in memory (VirtualAllocEx), writes to it (WriteProcessMemory), and creates a thread (CreateRemoteThread). To work with these functions, it uses the PIDs of the selected processes, which it previously obtained using CreateToolhelp32Snapshot.
Fig. 36: Code for injection
Here we can dynamically observe how it uses the process PID to call the function VirtualAllocEx.
Fig. 37: Calling VirtualAllocEx
5.4 Encryption
In this section, we will examine part of this sample related to encryption. In the next figure, you can see two subroutines called "LoadLibrary_EncodeString" and "Encode_Func", which are responsible for performing the encryption procedure.
Fig. 38: Encryption procedures
Initially, we can see how it loads a string that will later be used to deobfuscate everything necessary: imports, DLLs, commands, files, and CSP.
Fig. 39: Deobfuscation chain
In the next figure, the first import it deobfuscates is shown in the R4 register, LoadLibrary. This will be used later to load the required DLLs. We can also see another string in the R12 register, which is used alongside the previous string to perform deobfuscation.
Fig. 40: Dynamic deobfuscation
It continues to load commands that it will later execute to disable backups, restore points, and safe mode boot.
Fig. 41: Loading commands
Then it loads the location where it will drop 3 files: Windows.bat, run.sct and start.bat.
Fig. 42: File locations
These 3 files are used to check the privileges that each of the locations has. If the required privileges are not available, Ryuk halts execution.
It continues to load strings corresponding to the three files. The first, DECRYPT_INFORMATION.html, contains the information necessary for file recovery. The second, PUBLIC, contains the RSA public key.
Fig. 43: String DECRYPT_INFORMATION.html
The third, UNIQUE_ID_DO_NOT_REMOVE, contains an encrypted key that will be used in the next subroutine for encryption.
Fig. 44: UNIQUE ID DO NOT REMOVE
Finally, it loads the necessary libraries along with required imports and CSP (Microsoft Enhanced RSA and AES Cryptographic Provider).
Fig. 45: Loading libraries
After all deobfuscation is complete, it proceeds to perform the actions required for encryption: scanning all logical drives, executing what was loaded in the previous subroutine, enhancing its presence in the system, dropping the file RyukReadMe.html, encrypting, scanning all network drives, moving to discovered devices and encrypting them.
It all starts with loading "cmd.exe" and writing the public RSA key.
Fig. 46: Preparing for encryption
Then it retrieves all logical drives using GetLogicalDrives and disables all backups, restore points, and safe boot modes.
Fig. 47: Deactivating recovery tools
After that, it enhances its presence in the system, as we saw above, and writes the first file RyukReadMe.html downward API support (simultaneously with this in TEMP.
Fig. 48: Publish ransom notification
In the next figure, you can see how it creates the file, loads the content, and writes it:
Fig. 49: Loading and writing file content
To be able to perform these same actions on all devices, it uses
"icacls.exe", as we showed above.
Fig. 50: Using icacls.exe
And finally, it starts encrypting files except for "*.exe", "*.dll", system files, and other locations specified as an encrypted whitelist. For this, it uses imports: CryptAcquireContextW (where AES and RSA usage is specified), CryptDeriveKey, CryptGenKey, CryptDestroyKey etc. An attempt is also made to extend its action to discovered network devices using WNetEnumResourceW and then encrypt them.
Fig. 51: Encrypting system files
6. Imports and corresponding flags
Below is a table listing the most relevant imports and flags used by the sample:
7. IOC
Links
- usersPublicrun.sct
- Start MenuProgramsStartupstart.bat AppDataRoamingMicrosoftWindowsStart
- MenuProgramsStartupstart.bat
The technical report on the Ryuk ransomware was prepared by experts from the PandaLabs antivirus laboratory.
8. References
1. "Everis and Prisa Radio suffer a major cyberattack that hijacks their systems." https://www.elconfidencial.com/tecnologia/2019-11-04/everis-la-ser-ciberataque-ransomware-15_2312019/, Published on 11/04/2019.
2. "A Russian-origin virus attacks major Spanish companies." https://elpais.com/tecnologia/2019/11/04/actualidad/1572897654_251312.html, Published on 11/04/2019.
3. "VB2019 paper: Shinigami’s revenge: the long tail of the Ryuk malware." https://securelist.com/story-of-the-year-2019-cities-under-ransomware-siege/95456/, Published on 12/11/2019.
4. "Big Game Hunting with Ryuk: Another Lucrative Targeted Ransomware." https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Published on 01/10/2019.
5. "VB2019 paper: Shinigami’s revenge: the long tail of the Ryuk malware." https://www.virusbulletin.com/virusbulletin/2019/10/vb2019-paper-shinigamis-revenge-long-tail-r
Source: habr.com
