{ "id": "a3d75c97-c23c-492e-9899-3faa7e70258c", "created_at": "2026-04-06T00:13:54.75494Z", "updated_at": "2026-04-10T13:12:50.18316Z", "deleted_at": null, "sha1_hash": "bd9f4def8f0f234140fea5849fee3d8255426052", "title": "Malware reverse engineering (Ryuk Ransomware)", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 3416911, "plain_text": "Malware reverse engineering (Ryuk Ransomware)\r\nBy Hamad Alnakal\r\nPublished: 2021-11-17 · Archived: 2026-04-05 23:00:55 UTC\r\n10 min read\r\nNov 17, 2021\r\nExecutive Summary\r\nThe malware is a form of ransomware identified as the Ryuk ransomware. When the ransomware is run it kills a\r\nlist of processes and drops readme files in several directories and encrypts most files. The readme contains\r\ninstructions on how to make a bitcoin payment in exchange for decrypting the machine’s files. There is a lot of file\r\nsystem activity between dropping the readmes, encrypting files, and dropping a few files in C:/Users/Public\r\nincluding an RSA public key, a unique id file, and a batch file. The malware reads and updates many registry keys,\r\nthe most noticeable being the key that adds the executable to the registry\r\nHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\svhos, giving it persistence. To kill running processes,\r\nthe malware starts many instances of conhost.exe and net1.exe using the imported ShellExecuteA function. It does\r\nnot seem like the program employs anti-debugging however there is a point at which it tries to allocate memory\r\nusing the VirtualAllocEX function on a running process then tries to write into that memory using\r\nWriteProcessMemory. If it selects x64dbg as the process to inject into it will kill the debugger. There did not seem\r\nto be any attempted network connections. The dropped batch file will run repeatedly trying to delete any backups\r\non the infected computer.\r\nStatic Analysis\r\nVirus Total\r\nAfter performing some precursory static analysis, the ransomware was hashed and uploaded to VirusTotal. The\r\nransomware was run against many antivirus engines with 48 out of 60 recognizing it as malware and a few\r\ncorrectly identifying it as the Ryuk malware.\r\nPress enter or click to view image in full size\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 1 of 15\n\nBasic Static Analysis\r\nPEStudio provides a detailed overview of the contents of portable executable files. The malware’s compiler stamp\r\nis August 14th, 2018 which seems unlikely to have been modified because it is a relatively recent date, and it\r\nwould be odd to modify the compiler stamp but leave the path to the debug information in the strings.\r\nPEStudio does not find a signature for this executable, normally this would give information about how it was\r\ncompiled or a signature for a packer.\r\nStrings and Imports\r\nPEStudio reveals many interesting imports for this ransomware, including ShellExecute, LoadLibraryA, and\r\nVirtualAllocEx. ShellExecute is used to execute an operation in a thread. LoadLibraryA may be used to import a\r\nlibrary that is not shown in the imports of the executable. VirtualAllocEx is often used in obfuscation techniques.\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 2 of 15\n\nPress enter or click to view image in full size\r\nPress enter or click to view image in full size\r\nPress enter or click to view image in full size\r\nThe imports QueryPerformanceCounter and IsDebuggerPresent are sometimes used for anti-debugging.\r\nPress enter or click to view image in full size\r\nThe strings section is extremely revealing of the purpose and identity of this ransomware. The name of the\r\nmalware, “Ryuk”, is found in the strings section multiple times, with one being in the debug symbols path and\r\nanother in a file name for some “RyukReadMe.txt”.\r\nPress enter or click to view image in full size\r\nPress enter or click to view image in full size\r\nPress enter or click to view image in full size\r\nThere are also some very long strings which are identified, the first of which is made up of random letters which\r\nmay be obfuscated somehow. The second long string contains several commands which can delete system backups\r\nand backup files.\r\nPress enter or click to view image in full size\r\nThere are number of strings that contain the word stop followed by the name of a process, suggesting the malware\r\nprobably tries to stop these processes if they are running. There is also a number of strings which start with “/IM”\r\nfollowed by an executable, it is unclear as to what the malware is doing with these executables.\r\nPress enter or click to view image in full size\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 3 of 15\n\nPress enter or click to view image in full size\r\nThere is a registry key in the strings which suggests the malware will modify the HKCU CurrentVersion\\Run\r\nregistry, which malware will use to achieve persistence.\r\nA few other interesting strings are “No system is safe”, “BTC wallet:”, PUBLIC,\r\nUNIQUE_ID_DO_NOT_REMOVE, and paths to a few different directories.\r\nPress enter or click to view image in full size\r\nPress enter or click to view image in full size\r\nPress enter or click to view image in full size\r\nProgram Sections, Packing, and Obfuscation\r\nBased on the entropy of the sections it seems unlikely that this program is packed, there is no section with an\r\nentropy between 7 and 8. The program also has many revealing imports and strings meaning it is very unlikely\r\nthat the executable has been packed.\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 4 of 15\n\nPress enter or click to view image in full size\r\nThe program sections of this executable are largely uninteresting.\r\nAnti-Disassembly\r\nDisassembly was done using Ghidra, no anti-disassembly techniques were encountered while analyzing this\r\nransomware.\r\nDynamic Analysis\r\nProcess Behaviors\r\nRunning the malware executable has no immediately visible behavior, however using process explorer it is\r\npossible 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.\r\nAnalysis of this code in Ghidra shows that these sub-processes are being created by ShellExecuteA which is being\r\ncalled on the list of processes and executables that were found in the strings during static analysis.\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 5 of 15\n\nA while after the malware has been executed the screen flashes black and a User Access Control (UAC) prompt is\r\ndisplayed.\r\nPress enter or click to view image in full size\r\nClicking “Show more details” reveals that this UAC prompt is for a batch file in C:\\Users\\Public, clicking no on\r\nthis prompt just causes it to prompt again.\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 6 of 15\n\nAround the same time as the UAC prompts show, most of the files on the system get encrypted and ReadMe files\r\nget dropped. The ReadMe files contain a few of the strings found in static analysis: “BTC wallet:”, “Ryuk”, and\r\n“No system is safe”.\r\nPress enter or click to view image in full size\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 7 of 15\n\nNetwork Activity\r\nAnalysis of network traffic was done using REMnux with the accept-all-ips script to redirect outgoing traffic and\r\nwireshark to capture the traffic. No traffic related to the malware was logged, suggesting it does not attempt to\r\nmake any network connections.\r\nRegistry Activity\r\nUsing Process Monitor (ProcMon) it was possible to log the activity of running processes and identify malicious\r\nbehavior. There was a lot of registry activity that was caused by the malware, however, most of it did not seem to\r\nserve an identifiable purpose. The most recognizable registry change is in the\r\nHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\svhos registry, used to achieve persistence as suggested\r\nby the static analysis.\r\nPress enter or click to view image in full size\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 8 of 15\n\nThe value of this registry is set to the location of the malware executable, this registry contains processes for\r\nwindows to run at startup.\r\nPress enter or click to view image in full size\r\nEarly in the execution of the malware it sets these keys in the Internet Settings ZoneMap registry, it is unclear as\r\nto why because there did not seem to be any network activity. These are the default settings for these registries.\r\nPress enter or click to view image in full size\r\nThe remaining registry activity seems to be mostly noise and not much directly malicious activity.\r\nFilesystem Activity and Deeper Analysis\r\nThere was a lot of filesystem activity that was performed by the malware. The most noticeable was the creation of\r\nthe ReadMe files that get dropped in directories where encryption occurred. This action was logged in ProcMon,\r\nand interestingly is not performed by the original malware process itself.\r\nPress enter or click to view image in full size\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 9 of 15\n\nThe malware also drops four files besides the ReadMe in the C:/Users/Public directory, “Public”,\r\n“UNIQUE_ID_DO_NOT_REMOVE”, “sys”, and “window.bat”.\r\nPress enter or click to view image in full size\r\nPress enter or click to view image in full size\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 10 of 15\n\nThe sys file is empty, and its purpose is unknown. The Public file, by name and contents, is likely an RSA public\r\nkey used for decryption.\r\nPress enter or click to view image in full size\r\nThe UNIQUE_ID file name suggests that it may also be used in the decryption process, and its contents are very\r\nunreadable, though interestingly it starts with the same characters as the PUBLIC file. The file also has angle\r\nbrackets, parenthesis, curly braces, and square brackets that appear to have not been ecnrypted, giving it a\r\nstructure that seems like it could be html with script tags or php.\r\nPress enter or click to view image in full size\r\nThe window.bat file is hard to catch because it does not exist for long. However, the contents of the batch are the\r\nsame as one of the long strings found in static analysis. The batch file is what is running to find and delete\r\nbackups, which generates a lot of file activity.\r\nPress enter or click to view image in full size\r\nGetting the contents of these files was difficult because windows blocks copying files that are being used by\r\nprocesses and attempting to delete them was blocked by a prompt saying the file was in use. Using Resource\r\nMonitor it was possible to find what process was using the files. The Public file is an RSA key so it seems likely\r\nthat whatever process was using it was doing the encryption. Resource Monitor identified which process was\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 11 of 15\n\nusing the file and attempting to end that process would just result in a new process using the file. The processes\r\nthat were using it were normal processes, which suggested that the malware injected code into these processes.\r\nPress enter or click to view image in full size\r\nUsing Ghidra to find the VirtualAllocEX function it was not difficult to find where this injection was occurring.\r\nBy setting a breakpoint on the allocate call it was possible to stop before the malware injected and see which\r\nprocess it was going to inject into. After allocating memory in the process, it called WriteProcessMemory to write\r\nthe malicious code.\r\nPress enter or click to view image in full size\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 12 of 15\n\nBecause I could identify which process was going to be injected, I attached an instance of x64dbg to that process\r\nto see what got written. Looking at the memory map and sorting by protection, there was a section of the process\r\nmemory which had ERW permissions which is usually suspicious.\r\nPress enter or click to view image in full size\r\nLooking at the strings section for this memory section reveals that it is in fact the injected code. Dumping this\r\nmemory section is possible and can allow for further analysis though I was unable to locate the encryption\r\nmethod.\r\nPress enter or click to view image in full size\r\nAnti-Debugging and Anti-Virtual-Machine\r\nThere are several functions imported that could be used for anti-debugging however, none of them seemed to be\r\nused to do so. The main issues with debugging is that when the malware tries to inject into processes it will\r\nsometimes choose x64dbg as a process to inject into and when it fails it will kill the program. Another potentially\r\nunintentional barrier to debugging is that when attaching to the processes it injects into it will hit a debugging\r\nbreakpoint which causes the process to end, it seems that this is normal behavior of the particular proceses.\r\nGet Hamad Alnakal’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 13 of 15\n\nRemember me for faster sign in\r\nNo Anti-Virutal-Machine techniques were found when analyzing this ransomware with Ghidra and x64dbg.\r\nIndicators of Compromise\r\nHost Based:\r\nMD5 8819d7f8069d35e71902025d801b44dd\r\nSHA-1 5af393e60df1140193ad172a917508e9682918ab\r\nSHA-256 98ece6bcafa296326654db862140520afc19cfa0b4a76a5950deedb2618097ab\r\nExistence of this registry:\r\nHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\svhos\r\nSet to the path of the malware executable.\r\nExistence of these files:\r\nC:/Users/Public/sys C:/Users/Public/PUBLIC\r\nC:/Users/Public/UNIQUE_ID_DO_NOT_REMOVE C:/Users/Public/window.bat\r\nNetwork Based:\r\nNo network-based indicators identified.\r\nYARA Rule:\r\nrule Ryuk\r\n{\r\nmeta:\r\nfile_md5 = “8819d7f8069d35e71902025d801b44dd”\r\nfile_sha1 = “5af393e60df1140193ad172a917508e9682918ab”\r\nfile_sha256 =\r\n“98ece6bcafa296326654db862140520afc19cfa0b4a76a5950deedb2618097ab” author = “N\\A”\r\ncompilation date = “08/14/2018”\r\nstrings:\r\n$name = “ryuk” ascii wide nocase\r\n$debug = “C:\\Users\\Admin\\Documents\\Visual Studio 2015\\Projects From\r\nRyuk\\ConsoleApplication54\\x64\\Release\\ConsoleApplication54.pdb” ascii wide nocase\r\nCondition:\r\n$name and $debug\r\n}\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 14 of 15\n\nSource: https://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nhttps://0xchina.medium.com/malware-reverse-engineering-31039450af27\r\nPage 15 of 15", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://0xchina.medium.com/malware-reverse-engineering-31039450af27" ], "report_names": [ "malware-reverse-engineering-31039450af27" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434434, "ts_updated_at": 1775826770, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/bd9f4def8f0f234140fea5849fee3d8255426052.pdf", "text": "https://archive.orkl.eu/bd9f4def8f0f234140fea5849fee3d8255426052.txt", "img": "https://archive.orkl.eu/bd9f4def8f0f234140fea5849fee3d8255426052.jpg" } }