Malware reverse engineering (Ryuk Ransomware)
Executive Summary
The malware is a form of ransomware identified as the Ryuk ransomware. When the ransomware is run it kills a list of processes and drops readme files in several directories and encrypts most files. The readme contains instructions on how to make a bitcoin payment in exchange for decrypting the machine’s files. There is a lot of file system activity between dropping the readmes, encrypting files, and dropping a few files in C:/Users/Public including an RSA public key, a unique id file, and a batch file. The malware reads and updates many registry keys, the most noticeable being the key that adds the executable to the registry HKCU\Software\Microsoft\Windows\CurrentVersion\Run\svhos, giving it persistence. To kill running processes, the malware starts many instances of conhost.exe and net1.exe using the imported ShellExecuteA function. It does not seem like the program employs anti-debugging however there is a point at which it tries to allocate memory using the VirtualAllocEX function on a running process then tries to write into that memory using WriteProcessMemory. If it selects x64dbg as the process to inject into it will kill the debugger. There did not seem to be any attempted network connections. The dropped batch file will run repeatedly trying to delete any backups on the infected computer.
Static Analysis
Virus Total
After performing some precursory static analysis, the ransomware was hashed and uploaded to VirusTotal. The ransomware was run against many antivirus engines with 48 out of 60 recognizing it as malware and a few correctly identifying it as the Ryuk malware.
Basic Static Analysis
PEStudio provides a detailed overview of the contents of portable executable files. The malware’s compiler stamp is August 14th, 2018 which seems unlikely to have been modified because it is a relatively recent date, and it would be odd to modify the compiler stamp but leave the path to the debug information in the strings.
PEStudio does not find a signature for this executable, normally this would give information about how it was compiled or a signature for a packer.
Strings and Imports
PEStudio reveals many interesting imports for this ransomware, including ShellExecute, LoadLibraryA, and VirtualAllocEx. ShellExecute is used to execute an operation in a thread. LoadLibraryA may be used to import a library that is not shown in the imports of the executable. VirtualAllocEx is often used in obfuscation techniques.
The imports QueryPerformanceCounter and IsDebuggerPresent are sometimes used for anti-debugging.
The strings section is extremely revealing of the purpose and identity of this ransomware. The name of the malware, “Ryuk”, is found in the strings section multiple times, with one being in the debug symbols path and another in a file name for some “RyukReadMe.txt”.
There are also some very long strings which are identified, the first of which is made up of random letters which may be obfuscated somehow. The second long string contains several commands which can delete system backups and backup files.
There are number of strings that contain the word stop followed by the name of a process, suggesting the malware probably tries to stop these processes if they are running. There is also a number of strings which start with “/IM” followed by an executable, it is unclear as to what the malware is doing with these executables.
There is a registry key in the strings which suggests the malware will modify the HKCU CurrentVersion\Run registry, which malware will use to achieve persistence.
A few other interesting strings are “No system is safe”, “BTC wallet:”, PUBLIC, UNIQUE_ID_DO_NOT_REMOVE, and paths to a few different directories.
Program Sections, Packing, and Obfuscation
Based on the entropy of the sections it seems unlikely that this program is packed, there is no section with an entropy between 7 and 8. The program also has many revealing imports and strings meaning it is very unlikely that the executable has been packed.
Anti-Disassembly
Disassembly was done using Ghidra, no anti-disassembly techniques were encountered while analyzing this ransomware.
Dynamic Analysis
Process Behaviors
Running the malware executable has no immediately visible behavior, however using process explorer it is possible to see some interesting behavior. The malware exists as a process for some time creating many short-lived instances of conhost.exe, net.exe, and net1.exe.
Analysis of this code in Ghidra shows that these sub-processes are being created by ShellExecuteA which is being called on the list of processes and executables that were found in the strings during static analysis.
A while after the malware has been executed the screen flashes black and a User Access Control (UAC) prompt is displayed.
Clicking “Show more details” reveals that this UAC prompt is for a batch file in C:\Users\Public, clicking no on this prompt just causes it to prompt again.
Around the same time as the UAC prompts show, most of the files on the system get encrypted and ReadMe files get dropped. The ReadMe files contain a few of the strings found in static analysis: “BTC wallet:”, “Ryuk”, and “No system is safe”.
Network Activity
Analysis of network traffic was done using REMnux with the accept-all-ips script to redirect outgoing traffic and wireshark to capture the traffic. No traffic related to the malware was logged, suggesting it does not attempt to make any network connections.
Registry Activity
Using Process Monitor (ProcMon) it was possible to log the activity of running processes and identify malicious behavior. There was a lot of registry activity that was caused by the malware, however, most of it did not seem to serve an identifiable purpose. The most recognizable registry change is in the HKCU\Software\Microsoft\Windows\CurrentVersion\Run\svhos registry, used to achieve persistence as suggested by the static analysis.
The value of this registry is set to the location of the malware executable, this registry contains processes for windows to run at startup.
Early in the execution of the malware it sets these keys in the Internet Settings ZoneMap registry, it is unclear as to why because there did not seem to be any network activity. These are the default settings for these registries.
The remaining registry activity seems to be mostly noise and not much directly malicious activity.
Filesystem Activity and Deeper Analysis
There was a lot of filesystem activity that was performed by the malware. The most noticeable was the creation of the ReadMe files that get dropped in directories where encryption occurred. This action was logged in ProcMon, and interestingly is not performed by the original malware process itself.
The malware also drops four files besides the ReadMe in the C:/Users/Public directory, “Public”, “UNIQUE_ID_DO_NOT_REMOVE”, “sys”, and “window.bat”.
The sys file is empty, and its purpose is unknown. The Public file, by name and contents, is likely an RSA public key used for decryption.
The UNIQUE_ID file name suggests that it may also be used in the decryption process, and its contents are very unreadable, though interestingly it starts with the same characters as the PUBLIC file. The file also has angle brackets, parenthesis, curly braces, and square brackets that appear to have not been ecnrypted, giving it a structure that seems like it could be html with script tags or php.
The window.bat file is hard to catch because it does not exist for long. However, the contents of the batch are the same as one of the long strings found in static analysis. The batch file is what is running to find and delete backups, which generates a lot of file activity.
Getting the contents of these files was difficult because windows blocks copying files that are being used by processes and attempting to delete them was blocked by a prompt saying the file was in use. Using Resource Monitor it was possible to find what process was using the files. The Public file is an RSA key so it seems likely that whatever process was using it was doing the encryption. Resource Monitor identified which process was using the file and attempting to end that process would just result in a new process using the file. The processes that were using it were normal processes, which suggested that the malware injected code into these processes.
Using Ghidra to find the VirtualAllocEX function it was not difficult to find where this injection was occurring. By setting a breakpoint on the allocate call it was possible to stop before the malware injected and see which process it was going to inject into. After allocating memory in the process, it called WriteProcessMemory to write the malicious code.
Because I could identify which process was going to be injected, I attached an instance of x64dbg to that process to see what got written. Looking at the memory map and sorting by protection, there was a section of the process memory which had ERW permissions which is usually suspicious.
Looking at the strings section for this memory section reveals that it is in fact the injected code. Dumping this memory section is possible and can allow for further analysis though I was unable to locate the encryption method.
Anti-Debugging and Anti-Virtual-Machine
There are several functions imported that could be used for anti-debugging however, none of them seemed to be used to do so. The main issues with debugging is that when the malware tries to inject into processes it will sometimes choose x64dbg as a process to inject into and when it fails it will kill the program. Another potentially unintentional barrier to debugging is that when attaching to the processes it injects into it will hit a debugging breakpoint which causes the process to end, it seems that this is normal behavior of the particular proceses.
No Anti-Virutal-Machine techniques were found when analyzing this ransomware with Ghidra and x64dbg.
Indicators of Compromise
Host Based:
MD5 8819d7f8069d35e71902025d801b44dd
SHA-1 5af393e60df1140193ad172a917508e9682918ab
SHA-256 98ece6bcafa296326654db862140520afc19cfa0b4a76a5950deedb2618097ab
Existence of this registry:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\svhos
Set to the path of the malware executable.
Existence of these files:
C:/Users/Public/sys C:/Users/Public/PUBLIC
C:/Users/Public/UNIQUE_ID_DO_NOT_REMOVE C:/Users/Public/window.bat
Network Based:
No network-based indicators identified.
YARA Rule:
rule Ryuk
{
meta:
file_md5 = “8819d7f8069d35e71902025d801b44dd”
file_sha1 = “5af393e60df1140193ad172a917508e9682918ab”
file_sha256 =
“98ece6bcafa296326654db862140520afc19cfa0b4a76a5950deedb2618097ab” author = “N\A”
compilation date = “08/14/2018”
strings:
$name = “ryuk” ascii wide nocase
$debug = “C:\Users\Admin\Documents\Visual Studio 2015\Projects From Ryuk\ConsoleApplication54\x64\Release\ConsoleApplication54.pdb” ascii wide nocase
Condition:
$name and $debug
}
