How CrowdStrike Can Prevent Ryuk
By using the behavioral patterns of ransomware, the Falcon platform can detect Ryuk and prevent him from being executed. Falcon prevents Ryuk from being executed by turning off suspicious process blocking. CrowdStrike’s machine-learning (ML) algorithm also provides additional protection against this malware family. As illustrated below.
These are the characteristics that have not changed over time:
- Use AES-256 and RSA-2048 to encrypt files
- Keys stored in executable using Microsoft SIMPLEBLOB format
- Remote hosts and mounted devices can be encrypted
- To mark/check if a file is encrypted, use a file marker
Ryuk and Hermes have a distinct difference in how encryption keys are created. Hermes initiates encryption initialization by creating an RSA public key and private key pair. This is known as a victim key. The victim’s RSA private key is encrypted using AES-CBC mode. The attacker-controlled public RSA keys are used to encrypt AES keys (previously used for RSA private keys of victims). An AES key is then generated for each file that is encrypted. This key is used to encrypt that file. The victim’s RSA Public Key is used to encrypt the AES keys for each file. These keys are then saved at the end of each file.
Ryuk uses the same logic but does not generate the victim-specific RSA keys pair. Ryuk instead has two public RSA keys embedded within the executable. The victim’s RSA private key is also encrypted and embedded within the executable. Ryuk doesn’t generate a victim-specific RSA pair so all hosts can decrypt the executable with the same key. Although this may seem like a design flaw, Ryuk generates a unique key for every executable.
A single executable can be used to attack a victim environment. If the private keys are not leaked, there will be no consequences. Ryuk will likely pre-generate the RSA keys for each victim. This is arguably safer as the victim’s system won’t have access to the unencrypted RSA keys pair parameters and will not pay the ransom. This approach is similar to INDRIK SPIDER’s BitPaymer ransomware, which generates a victim-specific sample with a hard-coded public key.
Ryuk Functionality: A Technical Analysis
There are two types of Ryuk binaries. One is the Ryuk executable payment load, and one is the dropper. Because the Ryuk executable payload deletes the Ryuk dropper after execution, recovery of Ryuk droppers is rare. The dropper creates an installation path upon execution. The folder path is created by calling
GetWindowsDirectoryW and then inserting a null byte at the fourth character of the path. This is used for creating a string that includes the drive letter path. The string will be added to the drive path if the host operating system uses Windows XP. If the host is Windows Vista or newer, the string is appended to the drive letter path. Windows XP would use C: Documents, Settings, Default User as an example folder path, while Windows Vista and higher would use C: UsersPublic.
The executable file is then named randomly. The executable file is then created by calling _srand using a seed value from GetTickCount. _rand continues to be called until five alphabetic letters are combined. The extension is then added. The dropper checks whether the host is 32-bit or 64-bit by calling and writes one of two embedded payload executables corresponding to the host’s architecture. The newly written executable is then run by calling
ShellExecuteW. The Ryuk payload executable that was dropped by the dropper contains the core logic to encrypt files on the host.
Ryuk is constantly being developed. The Ryuk binaries have been deviating from the original Hermes source codes over the past months. Threat actors are adding and removing functionality frequently. Falcon Intelligence discovered new functionality in Ryuk, which included an anti-analysis infinite loop and a ping-like request for an IP address after encryption was complete. Also, there was an appended file extension to encrypted files. Only the file extension was present in the executable that was compiled on Dec. 20, 2018.
Compared to other families of ransomware, Ryuk has very few safeguards to ensure the stability of the host by not encrypting system files. Ryuk does not encrypt files with extensions Exe, DLL, or HRMLOG. This is because ransomware families often have extensive lists of file extensions and folder names that should not (whitelisted) be encrypted. The last extension is a filename for a debug log created by Hermes’ original developer. Not included in this list are sys (system driver), ocx, and other executable files. These files can be encrypted to make the most unstable. In and link files were whitelisted in Ryuk’s early versions. These have since been removed from Ryuk’s latest builds. These folder names are whitelisted but not encrypted.
This is only a subset of folder names that should not be whitelisted to ensure stability on your host. While doing dynamic analysis, it was not uncommon to observe Ryuk attempting to encrypt files related to the Windows Bootloader (
C:\Boot) or other critical files and folders. Infected machines can become unstable and unbootable over time if there is no proper whitelisting.
Ryuk uses a combination of symmetric (AES), and asymmetric encryption to encrypt files, as described in the Hermes section. The files can’t be decrypted without the WIZARD SPIDER private key and they are not recoverable. Each file is encrypted using its own AES key. A thread is created to allow for encryption. A file extension of
.RYK will is added to each file after it has been encrypted. All directories will have a ransom note of (
RyukReadMe.txt) written to the directory.
Ryuk attempts encryption on all mounted drives and hosts with Address Resolution Protocol (ARP), entries (IP addresses). It then enumerates all mounted drives by calling GetLogicalDrives. For each mounted drive, Ryuk calls to determine the drive’s type. Files on the drive that are not CD-ROMs will be encrypted if the drive type isn’t CD-ROM. To retrieve IP addresses that have ARP entries, Ryuk calls
GetIpNetTable. It will go through each entry and attempt to decrypt files and folders on remote hosts.
Ryuk’s current builds no longer include persistence functionality. To make the most persistent, Ryuk previously created a registry entry using Windows shell. The following command line was used to write to the Registry Run Key name svchos to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run with the value being the path to the Ryuk executable.
Ryuk doesn’t encrypt files within its own process memory space. Instead, Ryuk injects into remote processes. Before injecting into a remote process, Ryuk attempts to adjust its token privileges to have the
SeDebugPrivilege. If the token privileges are not adjusted correctly, Ryuk does not take any action. Before injecting into a remote process, Ryuk also calls to enumerate all running processes. Ryuk will inject itself into any process that isn’t named csrss.exe or explorer.exe. The developers assume that the process isn’t running under NT AUTHORITY and can therefore be written to. Ryuk injects itself into remote processes using a combination VirtualAlloc and WriteProcessMemory.
Anti-Recovery and Process/Service Termination
Ryuk is not like other ransomware families. It does not include anti-recovery and process/service termination functionality. These capabilities were present in Ryuk in the past but have since been removed. They are now contained within two batch files.
kill.bat the batch file contains commands to stop services, disable services, and kill processes. To ensure that files encrypted with the process and service are not accessible by others, they are stopped. Below is a partial list of all commands.
Figure 1. Process/Services Termination
CrowdStrike has observed another batch file, named, which makes file recovery more difficult on the victim’s machine. The threat actors can change file names arbitrarily. Figure 2 shows the contents of the batch files.
Figure 2. Anti-Recovery
These anti-forensic recovery commands are quite interesting and appear to make use of an undocumented feature of the
vssadmin resize command. The ransomware commonly uses Figure 2 to delete shadows, but the command option, vssadmin remove shadow storage, is seldom used. Vssadmin may display an error and delete backups even if shadow copies were not created directly by vssadmin. One error is: “Snapshots found, but they were not within your permitted context.” You can remove them using the backup application that created them. The vssadmin shadow storage command, a hack that requires sysadmin’s permission to delete storage after shadow copies have been resized, is an example of such a hack. This command forces shadow copies to be deleted regardless of their context. This command changes the default shadow volume size to 401MB. The minimum size is 300MB. Next, the shadow storage option is set to unlimited. This allows it to take advantage of all available disk space. You can then delete the shadow copies by calling the command a second time.
The last set of commands deletes files according to their folder location or extension. Command arguments can be used to del delete files from all sub-directories in quiet mode (/q), without asking for user confirmation, and to force (/f), the deletion of a particular file. File extensions are available for Virtual Hard Disk, Avantrix Backup Plus (.VHD), backup copy (.bak), Windows Backup Utility File. bfk), setting (.set), Windows Backup File. win), Disk Images. desk, and all folders that begin with Backup. The del command doesn’t securely delete files (i.e. it overwrites a file before deletion), but some file recovery may be possible with forensic tools. The last del %0 command deletes the executable.bat file.
Ryuk’s anti-recovery commands are much more comprehensive than those used by most ransomware groups. These commands are not used by any other ransomware families. This shows that threat actors are well-versed in enterprise backup software.
Open-source reporting has claimed that the Hermes ransomware was developed by the North Korean group STARDUST CHOLLIMA (activities of which have been publicly reported as part of the “Lazarus Group”), because Hermes was executed on a host during the SWIFT compromise of FEIB in October 2017. The compromise is possible in Table 1. RSW7B37.tmp and bitsran.exe are the executables that relate to Hermes.
Bitsran.exe is the first executable. RSW7B37.tmp, which is Hermes ransomware, is the second executable. The goal of the dropper is to spread the Hermes executable across a network using scheduled tasks via SMB sessions with hard-coded credentials. The Hermes executable encrypts files on the host. It is worth noting that Hermes’ compiler and linker are different from the rest of the executables. Visual Studio 10 was used to compile all executables, except Hermes. Visual Studio 10 also provided a linker. Hermes was, however, compiled using Visual Studio 9 with an unknown linker.
The time stamps show that the executables bitsran.exe (and RSW7B37.tmp), were both compiled in less than four hours and three minutes, respectively. Falcon Intelligence believes that Hermes was bundled in an executable that was hard-coded using credentials from the FEIB network. Falcon Intelligence also suggests that STARDUST CHOLLIMA had likely access to the Hermes source code or that a third party compiled and created a new version. Unlike other variants of Hermes,
RSW7B37.tmp does not append the exported and encrypted AES key to the end of the file. Figure 5 shows a file encrypted with Hermes. The exported AES key is appended as a footer to the file’s end.
Figure 5. Figure 5.
Figure 6 is the end of a file encrypted by the Hermes variant used in the SWIFT attack. The footer contains only the
HERMES marker, but not the exported EES key.
Figure 6. Figure 6.
The encrypted AES key that was attached to encrypted files cannot be decrypted without it. Even if the private key used for encryption was recovered, files cannot be decrypted without the key. The Hermes executable in the FEIB SWIFT attacks appears not to have been used for ransom, but to destroy the victim’s data.
Russia is home to criminal actors
Falcon Intelligence is confident that the WIZARD SPIDERS threat actors are operating from Russia. Hermes was originally advertised on
exploit[.]in. This Russian-speaking forum is well-known for its ability to sell malware and other related services to the criminal threat actor. If Hermes were indeed related to STARDUST CHOLLIMA it would imply nation-state threat agents are selling their services through Russian-speaking forums. This is unlikely.
An early advertisement for Hermes supports the Russian threat actor attribution theory. It stated that their software “did not work” and would only work on RU, UA, or BY [sic]. This is functionality that Hermes implements to verify the host system to make sure it’s not running on a Russian or Ukrainian system. To check the host language, it queries the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language\ and the value InstallLanguage. If the machine has the value 0419 (Russian), 0422 (Ukrainian), or 0423 (Belarusian), it calls to stop executing. To reduce the risk of being caught by local authorities and to avoid criminal prosecution, malware sellers and developers often include this functionality.
Falcon Intelligence discovered files related to an incident response investigation in Ryuk’s case. They were uploaded to a file scanning website via an IP address from Moscow, Russia. This file was a variant kill.bat with commands that were previously only seen executed by Ryuk using ShellExecute. The files could have been uploaded by a victim in Russia, but the time frame between the functionality being removed from Ryuk binaries and included in was very short. The most likely scenario is that threat actors were testing whether would be detected by antivirus engines.
CrowdStrike Services also found artifacts that had Russian filenames during an investigation of a WIZARD SPIDER-compromised network. One file was called code >!!! files dlya raboty !! files dlya raboty!!