{
	"id": "bd35641c-4f45-467c-8e4c-fae895d2770e",
	"created_at": "2026-04-06T02:11:10.104036Z",
	"updated_at": "2026-04-10T03:22:08.359389Z",
	"deleted_at": null,
	"sha1_hash": "9abe15d2d3e51cb02dc879930dcb64fb1d077ee7",
	"title": "Reversing Ryuk: A Technical Analysis of Ryuk Ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 356849,
	"plain_text": "Reversing Ryuk: A Technical Analysis of Ryuk Ransomware\r\nPublished: 2020-04-19 · Archived: 2026-04-06 01:37:08 UTC\r\nRyuk has been in operation since mid-2018 and is still one of the key ransomware variants operating in 2020. The\r\nthreat actors behind Ryuk have been known to target a wide range of industries, and they typically demand\r\nsubstantial ransom amounts.\r\nLately, given the ongoing COVID-19 situation, the actors behind Ryuk have been taking advantage of this and\r\ntargeting the most vulnerable – hospitals and the health care industry. In light of this (and because I am personally\r\ninterested in how Ryuk functions), here is a technical analysis of Ryuk’s key functionalities.\r\nNote: The Ryuk sample I used for this analysis is:\r\nfeafc5f8e77a3982a47158384e20dffee4753c20\r\nCarbon Copies\r\nThe first thing Ryuk does upon execution is the creation of two “hidden” executable files that are placed on the\r\ndesktop or one of the user’s temporary directories, depending on where the Ryuk sample was executed from.\r\nRyuk hidden executables.\r\nThese executables are actually copies of the primary Ryuk executable, and seem to be used for a few different\r\npurposes – most notably persistence and spawning additional instances of itself for more threads and faster\r\nencryption of the filesystem.\r\nRyuk child processes (executables) running.\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 1 of 10\n\nRyuk is extremely fast in its encryption process. This is possible due to the way Ryuk behaves in regards to\r\nthreads. The two executables and associated processes that were created, along with the process injection\r\ntechniques I will outline below, all serve as hosts for multi-threaded encryption. More on this later.\r\nProcess Injection\r\nAfter the creation of its child processes, Ryuk will attempt to inject itself into additional processes running on the\r\nvictim’s system.\r\nRyuk utilizes the Windows functions CreateToolHelp32Snapshot, Process32First, and Process32Next in order to\r\nenumerate processes running on the victim’s system and search for a feasible target process for injection:\r\nRyuk enumerating system processes.\r\nRyuk is only able to inject code into processes that are running at the same (or lower) privilege level as the Ryuk\r\nsample itself. So if Ryuk is running as Administrator or System (hopefully not the case!) it will be able to inject\r\ninto System-level processes.\r\nAn important note is that Ryuk will not inject into csrss.exe, explorer.exe, or lsass.exe. This safeguard is likely\r\nused to prevent system instability, but this is just an educated guess. (Please let me know if you have additional\r\ninformation about this.)\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 2 of 10\n\nRyuk process-injection safeguards.\r\nAfter enumeration and selection of a target process, Ryuk utilizes a typical process injection technique:\r\nFirst, the OpenProcess and GetModuleHandleA functions are called in order to get a handle to the target process.\r\nRyuk getting a handle to the target process.\r\nVirtualAllocEx is then called in order to allocate memory within the address space of the target process, followed\r\nby WriteProcessMemory, which is called in order to write code into this new memory space. Finally,\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 3 of 10\n\nCreateRemoteThread is called to create a new thread in the context of the victim process, which will subsequently\r\nexecute the injected code.\r\nRyuk writing memory and creating a thread.\r\nThis injection process can also be seen in an excerpt from API Monitor:\r\nRyuk process injection – API Monitor.\r\nThe injected code is actually just another copy of the original Ryuk process. (See my post on unpacking Ryuk if\r\nyou are interested in learning one method of leveraging this process injection technique in order to unpack Ryuk.)\r\nWhen I ran Ryuk in my Windows VM, code was injected into dwm.exe, taskhost.exe, and even the VirtualBox\r\nTray process (VBoxTray.exe). Interestingly, two of these processes crashed a few minutes after injection, so it\r\nappears that Ryuk can cause some incidental system instability.\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 4 of 10\n\nRyuk code injection crashes VBoxTray.exe.\r\nCommand Execution\r\nRyuk leverages Windows command line tools for most of its supporting functionalities. Some of these commands\r\ncan be seen in the below code:\r\nRyuk executing various command-line commands.\r\nDuring my analysis, the following command were run by Ryuk:\r\nnet.exe stop \"audioendpointbuilder\" /y\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 5 of 10\n\nThis command kills the “audio endpoint builder” Windows service, which causes audio to malfunction on the\r\nvictim system. I am still unsure why Ryuk executes this command, and I have no good suggestions.. Other than\r\nperhaps to infuriate the end user.\r\nnet.exe stop \"samss\" /y\r\nStops the Security Accounts Manager. This technique may be used to prevent security alerts being triggered and\r\nsent to a SIEM.\r\ncmd.exe /c \"WMIC.exe shadowcopy delete\"\r\nThis command clears the Windows Volume Shadow Copies so that they cannot be used to recover files.\r\ncmd.exe /c \"vssadmin.exe Delete Shadows /all /quiet\"\r\nThis command is used as another method of removing shadow copies of files.\r\ncmd.exe /c \"bcdedit /set {default} recoveryenabled No \u0026 bcdedit /set {default}\"\r\ncmd.exe /c \"bootstatuspolicy ignoreallfailures\"\r\nThese commands are used to disable Windows error recovery and associated boot options so it is more difficult to\r\nrecover the system.\r\nicacls \"C:*\" /grant Everyone:F /T /C /Q\r\nicacls \"D:*\" /grant Everyone:F /T /C /Q\r\nicacls \"Z:*\" /grant Everyone:F /T /C /Q\r\nThese commands attempt to assign the group Everyone full permissions to the C, D,and Z drives. This is used\r\nbefore the encryption process begins, to ensure Ryuk has permissions to modify files.\r\ncmd.exe \" /C REG ADD \"HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\" /v \"EV\" /t REG\r\nThis command is used to add Registry persistence. Essentially, this will ensure the Ryuk sample will run again\r\nupon system bootup. Ryuk will only encrypt files once, however. Speaking of that… on to encryption!\r\nEncryption – A Multi-Threaded Operation\r\nThe file encryption process runs once the above command line commands have been executed. As previously\r\nmentioned, Ryuk encrypts the filesystem using multiple threads, spread amongst the primary Ryuk executable, the\r\nsecondary executables, and the processes Ryuk was able to inject into. Ryuk creates a new thread for each file\r\nbeing encrypted:\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 6 of 10\n\nRyuk encryption threads.\r\nRyuk utilizes the functions FindFirstFileW and FindNextFileW in order to iterate through the files on the victim\r\nsystem. Once a file has been found, Ryuk will call CreateThread in order to start a new encryption thread.\r\nIt is notable how quickly Ryuk is able to enumerate the files on the victim system and encrypt them. In my initial\r\ntests (running on a virtual machine with 50+ GB hard drive) files were encrypted within a matter of 120 seconds\r\nor so, including files on network-attached drives.\r\nRyuk will also create a “readme” file (RyukReadme.htm) in every directory that contains encrypted files. This\r\nreadme file instructs the victim to contact the email address mentioned for further instructions on how to pay the\r\nransom:\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 7 of 10\n\nRyuk readme file.\r\nI originally wanted to go a bit more in depth into how Ryuk encrypted files and the encryption algorithms used.\r\nHowever, after a bit of research and code review, I realized that Ryuk is not doing anything incredibly new or\r\nnote-worthy in terms of the encryption process. According to this research, Ryuk is utilizing RSA-4096 and AES-256 encryption algorithms, which are extremely strong and, at this point in time, “unbreakable”. I put unbreakable\r\nin quotes because, technically, no encryption algorithms are completely unbreakable and all will eventually be\r\nbroken 😉\r\nNetwork Enumeration\r\nRyuk performs some rudimentary network enumeration in order to discover other network drives and adjacent\r\nsystems to encrypt. In my tests, and according to the Ryuk code in the sample I analyzed, Ryuk is able to\r\nenumerate the network in a few different ways.\r\nFirst, Ryuk obtains the ARP table from the victim machine (using the GetIpNetTable function) and attempts to\r\nping those connected systems to see if they are online:\r\nRyuk pinging connected systems.\r\nIf these systems are “alive”, Ryuk will attempt to connect to and mount SMB shares on these systems:\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 8 of 10\n\nRyuk attempting to connect to SMB network shares.\r\nRyuk will then attempt to encrypt any file system it is able to, given the victim system has the correct permissions\r\nand network capabilities to mount these devices.\r\nIn addition, Ryuk grabs the network adapter IP addresses (using the GetAdapterAddresses function) from the\r\nvictim system:and attempts to send WOL (Wake-On-LAN) packets to these systems in order to wake them up.\r\nRyuk will only send WOL packets to addresses that start with 10, 172, or 192.\r\nRyuk Wake-on-LAN attempts.\r\nDefending Against Ryuk\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 9 of 10\n\nRyuk MITRE ATT\u0026CK matrix.\r\nSince Ryuk (and other modern ransomware) is incredibly efficient and will encrypt an entire filesystem and\r\nattached network drives very quickly (likely within minutes), it is best to detect Ryuk as early in the Kill\r\nChain as possible, ideally in the Delivery phases and before Installation.\r\nRyuk is typically delivered via other malware and droppers, such as Trickbot, Dridex, and Cobalt Strike\r\nBeacons. Developing detections and mitigating controls against these malware variants in order to detect\r\nan infection before the deployment of Ryuk is optimal.\r\nIn the event that Ryuk is deployed and encryption occurs, a sound business continuity and backup plan will\r\nbe very helpful. Ensure offline backups are kept available.\r\nConsider very carefully before paying the ransom for the purchase of the Ryuk decryptor software. This\r\ndecryptor software has been well-researched by several threat intelligence vendors, and is said to be very\r\npoorly programmed and tends to crash during the decryption process, or worse, permanently destroys\r\nencrypted files.\r\nAs always, thanks for reading! If you enjoyed this post, follow me on Twitter (@d4rksystem).\r\nSource: https://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nhttps://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://securityliterate.com/reversing-ryuk-a-technical-analysis-of-ryuk-ransomware/"
	],
	"report_names": [
		"reversing-ryuk-a-technical-analysis-of-ryuk-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775441470,
	"ts_updated_at": 1775791328,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9abe15d2d3e51cb02dc879930dcb64fb1d077ee7.pdf",
		"text": "https://archive.orkl.eu/9abe15d2d3e51cb02dc879930dcb64fb1d077ee7.txt",
		"img": "https://archive.orkl.eu/9abe15d2d3e51cb02dc879930dcb64fb1d077ee7.jpg"
	}
}