🐍 🌛 ☄️ How does Ryuk ransomware that attacks enterprises 🤙🏾 🌉 🚴🏽

Ryuk is one of the most well-known ransomware options in the last few years. Since he first appeared in the summer of 2018, he has compiled an impressive list of victims , especially in the business environment, which is the main target of his attacks.

1. General information

This document contains an analysis of the Ryuk ransomware option, as well as the bootloader responsible for downloading the malware to the system.

Ryuk ransomware first appeared in the summer of 2018. One of the differences between Ryuk and other ransomware is that it aims to attack corporate environments.

In mid-2019, cyber-crime groups attacked a huge number of Spanish companies with the help of this cryptor.

Fig.

Figure
1: Excerpt from El Confidencial regarding Ryuk ransomware attack [1] 2: Excerpt from El País about an attack by Ryuk ransomware [2]
This year, Ryuk attacked a large number of companies in different countries. As you can see in the figures below, Germany, China, Algeria and India suffered the most.

Comparing the number of cyber attacks, we can see that millions of users were affected by Ryuk and the huge amount of data was compromised, resulting in serious economic damage.

Fig. 3: Illustration of Ryuk's global activity.

Fig. 4: 16 countries most affected by Ryuk

Fig. 5: The number of users attacked by Ryuk ransomware (in millions)

According to the usual principle of the operation of such threats, this ransomware after encryption shows the victim a ransom notification that must be paid in bitcoins to the specified address to restore access to encrypted files.

This malware has changed since it first appeared.
A variant of this threat analyzed in this document was discovered during an attempt to launch an attack in January 2020.

Due to its complexity, this malware is often attributed to organized cybercriminals, also known as APT groups.

Part of the Ryuk code has a noticeable resemblance to the code and structure of another well-known Hermes cryptographer, with which they have a number of identical functions. That is why Ryuk was initially associated with the North Korean group Lazarus, which at that time was suspected of being behind the Hermes ransomware.

Subsequently, CrowdStrike’s Falcon X noted that Ryuk was actually created by WIZARD SPIDER [4].

There is some evidence to support this assumption. Firstly, this ransomware was advertised on the exploit.in website, which is a well-known Russian malware market and was previously associated with some Russian APT groups.
This fact excludes the theory that Ryuk could be developed by the Lazarus APT group, as this does not match the way the group acts.

In addition, Ryuk was touted as an encryptor that will not work on Russian, Ukrainian and Belarusian systems. This behavior is determined by the function found in some versions of Ryuk, where it checks the language of the system in which this encryptor is running and stops its operation if the system has Russian, Ukrainian or Belarusian. Finally, when conducting an expert analysis of a machine that was hacked by the WIZARD SPIDER group, several “artifacts” were discovered that were supposedly used in the development of Ryuk as a variant of the Hermes ransomware.

On the other hand, experts Gabriela Nicolao and Luciano Martins suggested that the cryptographer might have been developed by the CryptoTech APT team [5].
This follows from the fact that a few months before the appearance of Ryuk, this group posted information on the forum of the same site that they had developed a new version of the Hermes ransomware.

Several forum users have wondered if CryptoTech really created Ryuk. After that, this group defended itself and stated that it had evidence that they had developed 100% of this encryptor.

2. Characteristics

We start with the bootloader, whose task is to identify the system in which it is located, so that you can run the “correct” version of the Ryuk encryptor.
The bootloader hash is as follows:

MD5 A73130B0E379A989CBA3D695A157A495
SHA256 EF231EE1A2481B7E627921468E79BB4369CCFAEB19A575748DD2B664ABC4F469

One of the features of this bootloader is that it does not contain any data - the creators of this malware did not include any information in it.

Sometimes they include erroneous data in order to make the user think that he is allegedly launching a legitimate application. However, as we will see later, in the event that the infection does not involve interaction with the user (as is the case with this encryptor), then the attackers do not consider it necessary to use meta-data.

Fig. 6:

Sample meta data The sample was compiled in 32-bit format so that it can be run on both 32-bit and 64-bit systems.

3. Penetration vector

The sample that downloads and launches Ryuk entered our system through a remote connection, and the access parameters were obtained thanks to a preliminary RDP attack.

Fig. 7: Attack Registry An

attacker managed to log into a system remotely. After that, he created an executable file with our sample.
This executable file was blocked by an antivirus solution before launch.

Fig. 8: Blocking the sample

Fig. 9: Sample Lock

When a malicious file was blocked, the attacker tried to download an encrypted version of the executable file, which was also blocked.

Fig. 10: A set of samples that an attacker tried to run

Finally, he tried to download another malicious file through an encrypted console
PowerShell in order to bypass anti-virus protection. But he was also blocked.

Fig. 11: PowerShell with the blocked malicious content

Fig. 12: PowerShell with blocked malicious content

4. Bootloader

When it is executed, it writes the ReadMe file to the % temp% folder , which is typical of Ryuk. This file - a ransom demand, containing e-mail address protonmail domain, which is quite common in this family of malware: msifelabem1981@protonmail.com

Fig. 13: Redemption requirement

During the execution of the bootloader, you can see that it launches several executable files with random names. They are stored in a hidden PUBLIC folder , but if the option “Show hidden files and folders” is not active in the operating system , they will remain hidden. Moreover, these files are 64-bit unlike the parent file, which is 32-bit.

Fig. 14: Executable files launched by the sample

As you can see in the above figure, Ryuk launches icacls.exe, which will be used to modify all ACLs (Access control list), thus guaranteeing access and changing flags.

It gets full access under all users to all files on the device (/ T) regardless of errors (/ C) and without showing any messages (/ Q).

Fig. Figure 15: Execution options for icacls.exe launched by the sample.

It is important to note that Ryuk checks which version of Windows is running. To do this, it
checks the version using GetVersionExW , in which it checks the value of the lpVersionInformation flagshowing whether the current version of Windows is later than Windows XP .

Depending on whether you are running a later version than Windows XP, the bootloader will write to the local user folder - in this case, the % Public% folder .

Fig. 17: Checking the operating system version The

recorded file is Ryuk. Then it launches it, passing its own address as a parameter.

Fig. 18: Running Ryuk through ShellExecute

The first thing Ryuk does is get the input parameters. This time there are two input parameters (the executable file itself and the dropper address), which are used to remove their own traces.

Fig. 19: Creating a process

You can also see that as soon as he launched his executable files, he deletes himself, thus leaving no trace of his presence in the folder where he was executed.

Fig. 20: file deletion

5. RYUK

5.1 Presence
Ryuk, like other malware, tries to stay on the system for as long as possible. As shown above, one way to achieve this goal is to secretly create and run executable files. For this, the most common practice is to modify the CurrentVersion \ Run registry key .
In this case, you can see that for this purpose, the first executable file VWjRF.exe
(the file name is randomly generated) launches cmd.exe .

Fig. 21: Executing the VWjRF.exe file

Then a RUN command is entered with the name " svchos"Thus, if you want to check the registry keys at any time, you can easily not notice this change, given the similarity of this name with svchost. Thanks to this key, Ryuk ensures its presence in the system. If the system has not yet been infected then when you reboot the system, the executable will try again

Fig. 22: The sample ensures the presence of the registry key

We can also see that this executable stops the two services:
" audioendpointbuilder ", which, as its name implies, matches the system audio,

Figure 23: Sample stops system audio

and samss service, which is an account management service. Stopping these two services is a characteristic of Ryuk. In this case, if the system is connected to the SIEM system, the encryptor tries to stop sending any warnings to SIEM . Thus, he defends his next steps, as some SAM services will not be able to start their work correctly after Ryuk is executed.

Fig. 24: The sample stops the Samss service

5.2 Privileges

Generally speaking, Ryuk starts with horizontal movement within the network or is launched by another malicious program, such as Emotet or Trickbot , which in case of privilege escalation transfers these elevated rights to the encryptor.

In advance, as a prelude to the implementation process, we see that it runs the ImpersonateSelf process , which means that the security content of the access token will be transferred to the stream, where it will be immediately received using GetCurrentThread .

Fig. 25: Calling ImpersonateSelf

Then we see that it will associate the access token with the stream. We also see that one of the flags is DesiredAccess , which can be used to control the access that the stream will have. In this case, the value that edx will receive must be TOKEN_ALL_ACESS, or else TOKEN_WRITE .

Fig. 26: Creating a stream token

Then it will useSeDebugPrivilege will make a call to get Debug debugging rights with respect to the stream, as a result of which, by specifying PROCESS_ALL_ACCESS , it will be able to access any required process. Now, given that the encryptor already has a prepared stream, it remains only to proceed to the final stage.

Fig. 27: Calling SeDebugPrivilege and the function of escalating rights

On the one hand, we have LookupPrivilegeValueW, which provides us with the necessary information about the privileges that we want to raise.

Fig. 28: Requesting information about privileges for their escalation

On the other hand, we have AdjustTokenPrivileges , which allows us to obtain the necessary rights to our stream. In this case, the most important is NewState.whose flag will grant privileges.

Fig. Figure 29: Setting rights for the token

5.3 Deployment

In this section, we will show how the sample performs the deployment process previously mentioned in this report.

The main goal of the implementation process, as well as escalation, is to gain access to shadow copies . To do this, he needs to work with the stream with rights higher than that of the local user. As soon as he obtains such higher rights, he will delete the copies and make changes to other processes in order to make it impossible to return to an earlier restore point in the operating system.

As is usually the case with this type of malware, it uses CreateToolHelp32Snapshot to complete the implementation, so it takes a snapshot of the currently running processes and tries to access these processes using OpenProcess . As soon as he gets access to the process, he also opens a token with his information to obtain process parameters.

Fig.

Figure 30: Receiving processes from a computer We can dynamically see how it receives a list of running processes in routine 140002D9C using CreateToolhelp32Snapshot. After receiving them, he goes through the list, trying to open processes one by one using OpenProcess until he can do it. In this case, the first process he was able to open was “taskhost.exe” .

Fig. 31: Dynamic execution of a procedure to obtain a process

We can see that he subsequently reads the token of the process, so it is OpenProcessToken with the " 20008 "

Fig. 32: Reading process token information

It also checks that the process into which it will be embedded is not csrss.exe , explorer.exe, lsaas.exe or that it has a set of NT authority permissions .

Fig. Figure 33: Excluded processes.

We can dynamically see how it first checks using the process token information in 140002D9C to find out if the account whose rights are used to execute the process is an NT AUTHORITY account .

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 he took a snapshot of the processes, opened the processes and verified that none of them are excluded, he is ready to write down the processes that will be implemented into memory.

To do this, he first reserves a region in memory ( VirtualAllocEx ), writes to it ( WriteProcessmemory ) and creates a stream ( CreateRemoteThread ). To work with these functions, he uses the PIDs of the selected processes, which he previously obtained using CreateToolhelp32Snapshot .

Fig. 36: Embed Code

Here we can dynamically observe how it uses the process PID to call the VirtualAllocEx function .

Fig. Figure 37: Invoking VirtualAllocEx

5.4 Encryption
In this section, we will look at part of this sample related to encryption. In the following figure, you can see two routines called " LoadLibrary_EncodeString " and " Encode_Func ", which are responsible for performing the encryption procedure.

Fig. 38: Encryption Procedures

At first we can see how it loads a string that will later be used to de-obfuscate everything that is needed: imports, DLLs, commands, files, and CSPs.

Fig. 39: Deobfuscation chain

The following figure shows the first import that it deobfuscates in the R4 register, LoadLibrary . This will be used later to load the necessary DLLs. We can also see another line in register R12, which is used together with the previous line to perform deobfuscation.

Fig. 40: Dynamic deobfuscation.

He continues to load commands that he will execute later to disable backups, restore points, and safe boot modes.

Fig. 41: Downloading 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 location has. If the required privileges are not available, Ryuk stops execution.

It continues to load lines corresponding to three files. The first, DECRYPT_INFORMATION.html , contains the information needed to restore files. The second, PUBLIC , contains the RSA public key.

Fig. 43: String DECRYPT INFORMATION.html

Third, UNIQUE_ID_DO_NOT_REMOVE , contains the encrypted key that will be used in the next routine to perform encryption.

Fig. 44: UNIQUE ID DO NOT REMOVE String

Finally, it loads the required libraries along with the required imports and CSP ( Microsoft Enhanced RSAand AES Cryptographic Provider ).

Fig. 45: Downloading libraries

After all the deobfuscation is completed, he proceeds to perform the actions required for encryption: iterate over all logical drives, perform what was loaded in the previous subroutine, strengthen the presence in the system, drop the RyukReadMe.html file, encrypt, enumerate all network drives, switching to discovered devices and their encryption.
It all starts with downloading " cmd.exe " and writing the RSA public key.

Fig. 46: Preparing for Encryption

It then retrieves all logical drives using GetLogicalDrives and disables all backups, recovery points, and safe boot modes.

Fig. 47: Deactivating recovery tools

After that, he strengthens his presence in the system, as we saw above, and writes the first RyukReadMe.html file to TEMP .

Fig.

Figure 48: Publishing a buyback notification. In the following figure, you can see how it creates a file, downloads the contents and writes it:

Figure. Figure 49: Downloading and recording the contents of a file.

In order to be able to perform the same actions on all devices, it uses
" icacls.exe " as we showed above.

Fig. 50: Using icalcls.exe

And finally, it starts encrypting files with the exception of the "* .exe", "* .dll" files, system files, and other locations specified as an encrypted white list. For this, it uses imports: CryptAcquireContextW (where the use of AES and RSA is indicated), CryptDeriveKey, CryptGenKey , CryptDestroyKey , etc. An attempt is also being made to expand its effect on detected network devices using WNetEnumResourceW and then encrypt them.

Fig. 51: System File Encryption

6. Imports and related flags

The following is a table listing the most relevant imports and flags used by the sample:

7. IOC

References

users \ Public \ run.sct
Start Menu \ Programs \ Startup \ start.bat AppData \ Roaming \ Microsoft \ Windows \ Start
Menu \ ProgramsStartup \ start.bat

Ryuk ransomware technical report compiled by PandaLabs antivirus lab experts.

8. References

1. “Everis y Prisa Radio sufren un grave ciberataque que secuestra sus sistemas.” Https: // www. elconfidencial.com/tecnologia/2019-11-04/ everis-la-ser-ciberataque-ransomware-15_2312019 /, Publicada el 04/11/2019.

2. “Un virus de origen ruso ataca a importantes empresas españolas.” Https: //elpais.com/ tecnologia / 2019/11/04 / actualidad / 1572897654_ 251312.html, Publicada el 04/11/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 /, Publicada el 11 /

12/2019 4. “Big Game Hunting with Ryuk: Another Lucrativebased Ransomware.” Https: // www. crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/, Publicada el 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

How does Ryuk ransomware that attacks enterprises