{
	"id": "69938d6f-2839-4685-b3dd-19e616fbfbe9",
	"created_at": "2026-04-09T02:24:04.608038Z",
	"updated_at": "2026-04-10T03:38:19.553157Z",
	"deleted_at": null,
	"sha1_hash": "d4994d6af99268e34998650645f0b8adf5b963f3",
	"title": "Ryuk Ransomware: A Targeted Campaign Break-Down",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 97690,
	"plain_text": "Ryuk Ransomware: A Targeted Campaign Break-Down\r\nBy deugenio\r\nPublished: 2018-08-20 · Archived: 2026-04-09 02:21:20 UTC\r\nResearch by: Itay Cohen, Ben Herzog\r\nOver the past two weeks, Ryuk, a targeted and well-planned Ransomware, has attacked various organizations\r\nworldwide. So far the campaign has targeted several enterprises, while encrypting hundreds of PC, storage and\r\ndata centers in each infected company.\r\nWhile the ransomware’s technical capabilities are relatively low, at least three organizations in the US and\r\nworldwide were severely hit by the malware. Furthermore, some organizations paid an exceptionally large ransom\r\nin order to retrieve their files. Although the ransom amount itself varies among the victims (ranging between 15\r\nBTC to 50 BTC) it has already netted the attackers over $640,000.\r\nCuriously, our research lead us to connect the nature of Ryuk’s campaign and some of its inner-workings to the\r\nHERMES ransomware, a malware commonly attributed to the notorious North Korean APT Lazarus Group,\r\nwhich was also used in massive targeted attacks. This leads us to believe that the current wave of targeted attacks\r\nusing Ryuk may either be the work of the HERMES operators, the allegedly North Korean group, or the work of\r\nan actor who has obtained the HERMES source code.\r\nIn the below analysis we review the highly targeted attacks that Ryuk has been involved in and make a detailed\r\ncomparison between it and the notorious HERMES ransomware used in other operations. We also address the\r\nfinancial aspects of the campaign and illustrate how, through tracking the money trail, Ryuk’s authors seem to\r\nwant to disguise their received payments by dividing and transferring them among multiple wallets.\r\nAn Overview of Ryuk\r\nUnlike the common ransomware, systematically distributed via massive spam campaigns and exploit kits, Ryuk is\r\nused exclusively for tailored attacks. In fact, its encryption scheme is intentionally built for small-scale operations,\r\nsuch that only crucial assets and resources are infected in each targeted network with its infection and distribution\r\ncarried out manually by the attackers.\r\nThis, of course, means extensive network mapping, hacking and credential collection is required and takes place\r\nprior to each operation. Its alleged attribution to Lazarus Group, discussed later in this post, may imply that the\r\nattackers are already well experienced in the targeted attacks domain, as seen by attacks such as the breach of\r\nSony Pictures in 2014.\r\nRyuk’s Ransom Note\r\nWhile no differences were found in the collected samples, two versions of ransom notes were sent to victims; a\r\nlonger, well-worded and nicely phrased note, which led to the highest recorded payment of 50 BTC (around\r\n$320,000), and a shorter, more blunt note, which was sent to various other organizations and also led to some fine\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 1 of 15\n\nransom payments ranging between 15-35 BTC (up to $224,000). This could imply there may be two levels of\r\noffensive.\r\nFigure 1: Ransom Note #1; a pleasant, well-phrase note.\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 2 of 15\n\nFigure 2: Ransom Note #2; a shorter, less detailed note.\r\nRyuk vs HERMES\r\nThe HERMES ransomware first gained publicity in October 2017 when it was used as part of the targeted attack\r\nagainst the Far Eastern International Bank (FEIB) in Taiwan. In that attack, commonly attributed to the Lazarus\r\nGroup, a hefty $60 million was stolen in a sophisticated SWIFT attack, though was later retrieved. In this case, it\r\nseems the HERMES ransomware was delivered to the bank network as a diversion.\r\nIn the case of Ryuk, however, there is no doubt that the latest ransomware attacks seen over the past two weeks\r\nare by no means just a side-show but rather the main act. Indeed, with ransom payment as high as those already\r\npaid, Ryuk is definitely getting hitting the right note amongst its audience, or rather its victims.\r\nThe following technical comparison of Ryuk and HERMES leads us to believe that whoever wrote the malware\r\nwas either in possession of the HERMES ransomware source code or is possibly even the same threat actor\r\nreusing code for yet another round of targeted attacks.\r\nMalware Comparison\r\nAn interesting finding that arises when inspecting Ryuk’s code is that its encryption logic resembles that found in\r\nthe HERMES ransomware, as outlined previously by Malwarebytes.\r\nIndeed, if we compare the function that encrypts a single file, we see much similarity in its structure, as depicted\r\nin the following call flow graphs:\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 3 of 15\n\nFigure 3: Call flow graphs of the encryption functions in Ryuk and Hermes.\r\nIn fact, it seems that the author of Ryuk did not even bother to change the marker in the encrypted files as the code\r\nused to generate, place and verify this marker in order to determine if a file was already encrypted are identical in\r\nboth malwares:\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 4 of 15\n\nFigure 4: Marker generation in Ryuk and Hermes.\r\nFigure 5: Marker check in Ryuk and Hermes.\r\nAdditionally, the function that invokes the aforementioned routine conducts very similar actions in both cases. For\r\ninstance, both whitelist similar folders (e.g. “Ahnlab”, “Microsoft”, “$Recycle.Bin” etc.) to avoid file encryption\r\nof files stored in them. Also, both write a batch script named “window.bat” in the same path, with a similar script\r\nused to delete shadow volumes and backup files. Likewise, in both cases there are files dropped to disk\r\n(“PUBLIC” and “UNIQUE_ID_DO_NOT_REMOVE”) which resemble in name and purpose.\r\nIt should also be noted that all the above logic is preserved in both the 32 and 64 bit versions of Ryuk that we had\r\nsamples of. Such similarity of code across different architectures might well be a sign of an underlying identical\r\nsource code.\r\n Technical Analysis\r\nThe Dropper\r\nThe dropper of Ryuk is simple and fairly straightforward. It contains 32 and 64 bit modules of the ransomware,\r\nembedded one after the other in the dropper’s binary. At the beginning of its execution, the dropper generates a 5-\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 5 of 15\n\nlettered random file name using the srand function and GetTickCount for seed generation.\r\nThe aforementioned payload files are then written to a directory, depending on the version of Windows on victim’s\r\ncomputer. If the version is Windows XP or Windows 2000, the file is created in the directory “\\Documents and\r\nSettings\\Default User\\”, otherwise it is created in “\\users\\Public\\”.\r\nIf the file creation fails, the dropper attempts to write it in its own directory, using its own name and appending the\r\nletter ‘V’ as the last character.\r\nAfter creating the file, the dropper then checks whether the process is run under Wow64, and writes the suitable\r\npayload (32 or 64 bit) depending on the result of the check.\r\nFinally, before terminating, the dropper calls ShellExecuteW to execute the Ryuk ransomware payload it has just\r\nwritten.\r\nRansomware Binary\r\nUpon execution, the Ryuk ransomware conducts a Sleep of several seconds and then checks whether it was\r\nexecuted with an argument. If such was passed, it will use it as a path to a file that is deleted using DeleteFileW.\r\nBased on the malware’s dropper code, this argument would be the path to the dropper itself. Following this, the\r\nransomware will kill more than 40 processes and stop more than 180 services by executing taskkill and net stop on\r\na list of predefined service and process names. These services and processes are mostly belonging to antivirus,\r\ndatabase, backup and document editing software.\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 6 of 15\n\nFigure 6: Partial list of killed processes and services.\r\nPersistence \u0026 Process Enumeration\r\nTo make sure the malware is executed after reboot, Ryuk uses a straight forward persistence technique, whereby it\r\nwrites itself to the Run registry key using the following command:\r\n‘reg add /C REG ADD “HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run” /v\r\n“svchos” /t REG_SZ /d’\r\nIt will then try to elevate to SeDebugPrivilege so as to have extended capabilities in subsequent actions and\r\nprepare for injection by forming an array of structures. Each entry in the array represents a running process in the\r\nsystem and contains the process’ name, PID, and a number which represents the account type of its owner (as\r\noutlined in the figure below). After putting the aforementioned process list together, Ryuk will iterate over it and\r\ntry to inject a code to each process’s address space, as long as its name is not “explorer.exe”, “csrss.exe” or\r\n“lsaas.exe”, or is not run by NT AUTHORITY.\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 7 of 15\n\nFigure 7: An array entry representing a running process in the system.\r\nThe Injection Method\r\nRyuk uses a rather basic injection technique, whereby it first gets a handle on the target process using\r\nOpenProcess and allocates a buffer in its address space using VirtualAllocEx. The allocated buffer would have the\r\nsize of the malware’s image and would be required to be positioned at the same base address.\r\nThe malware will then write its current virtual image content into it and create a thread that will carry out some\r\nactions, as described in the next section. Note that by writing the virtual image into a requested buffer with a\r\npredefined allocation base, and with the lack of a proper code relocation procedure, Ryuk is taking the risk that the\r\nrequested address is not available for allocation, thus causing a potential failure in the execution of the injected\r\ncode.\r\nFigure 8: The injection method and bug that causes it to fail.\r\nThe Injected Code\r\nThe injected code holds the core functionality used by the ransomware for file encryption. It is started by\r\ndecrypting a list of API function name strings using a predefined key and an array of the string lengths which is\r\nthen used to dynamically load the corresponding functions.\r\nIn order to ease the decryption process during analysis, we created an IDA Python script that will automatically\r\ndecrypt these strings and rename the relevant variables. The script can be found in the Appendix below.\r\nFollowing this, the malware will attempt to write a dummy file to the Windows directory, which would only be\r\nallowed with Admin privileges. If the creation of the file failed, it will sleep for a while and attempt the same\r\nanother five times. If failure persists beyond these attempts, Ryuk will simply terminate.\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 8 of 15\n\nIf the file was successfully created, it will write two more files to a subfolder in the Windows directory. The first is\r\na file named “PUBLIC” which contains an RSA Public key, and the second is\r\n“UNIQUE_ID_DO_NOT_REMOVE” that contains a hardcoded key. Both are leveraged for the purpose of\r\nencryption as outlined in the following section.\r\nThe Encryption Scheme\r\nThe ransomware uses a relatively straightforward three-tier trust model. At the root of the trust model, as is typical\r\nin robust ransomware implementations, is the global RSA key pair held by the attackers. The private key from this\r\nkey pair is not visible to the victim at any point during infection.\r\nThe second tier is a per-victim RSA keypair. Typically a ransomware would generate this keypair on-the-fly, and\r\nthen immediately encrypt the resulting private key using the higher-tier global key. Instead, the ransomware comes\r\nwith this keypair pre-embedded and the private key pre-encrypted. This is a somewhat unorthodox approach,\r\nwhich may be vulnerable to a ‘pay-once, decrypt-many’ attack if the same sample is used to infect multiple\r\nvictims, or if the same keypair is embedded in multiple samples.  But given that a fresh key pair is generated for\r\neach new sample, it is a secure model.\r\nFigure 9: the embedded per-victim RSA public key (note the initial bytes 06 02).\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 9 of 15\n\nFigure 10: The embedded per-victim RSA private key that has been encrypted\r\nwith the campaign global key (note the initial bytes 07 02).\r\nThe third tier is a standard AES symmetric encryption key generated per victim file using the Win32API function\r\nCryptGenKey. The key is then exported using CryptExportKey, encrypted using the second-tier key, and the\r\nencrypted result appended to the encrypted file. In a truly extraordinary turn of events, the authors actually read\r\nthe documentation of CryptExportKey and provided the second-tier key as the hExpKey parameter, which is there\r\nexactly to provide this functionality. Most ransomware exports the AES key in plain and then encrypts the result\r\nusing CryptEncrypt, or some such.\r\nFigure 11: Assembly that generates the per-file AES key;\r\nthis is a part of the ransomware’s “encrypt file” routine.\r\nOnce all cryptographic primitives are in place, the ransomware performs a standard recursive sweep of every drive\r\nand network share on the victim system, and encrypts every file and directory except for any file or directory\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 10 of 15\n\ncontaining text from a hardcoded whitelist, which includes “Windows”, “Mozilla”, “Chrome”, “RecycleBin” and\r\n“Ahnlab”. It’s clear why the attackers would want the victim’s web browser intact given that it may be required\r\nfor reading the ransom note, purchasing cryptocurrency and so on. But it is less clear why the attackers are\r\nconcerned with encrypting the victim’s copy of a South Korean endpoint protection product, especially given that\r\nthis attack wasn’t even targeted at South Korean users.\r\nThis bit in particular is one piece of a larger puzzle of how the HERMES ransomware came to be re-used and\r\nrebranded as “Ryuk” ransomware. Apart from the obvious re-labeling in the readme file and so on, there are subtle\r\ndifferences in the trust model.\r\nAccording to a report by Malwarebytes, the original HERMES actually generated the tier-two per-victim RSA\r\nkeypairs, as opposed to embedding hard-coded copies in the malware samples. But the encryption function itself,\r\nincluding the encrypted file format and its associated unique “HERMES” file magic, are reproduced wholesale in\r\nthe rebranded version; as is the check for “AhnLab”-related files, which isn’t even relevant to Ryuk’s intended\r\nvictims.\r\nFigure 12: Hex dump of a file encrypted by Ryuk ransomware.\r\nThe file structure is visibly identical to the one used in HERMES,\r\ndown to the distinctive ‘HERMES’ marker, which the malware uses to identify files which it has already\r\nencrypted.\r\nIn addition to local drives, Ryuk will also try to encrypt network resources. First, it will start their enumeration by\r\ncalling WNetOpenEnum, and then allocate a zero-initialized buffer. This buffer will be filled throughout a call to\r\nthe WNetEnumResource function. If the enumerated resource is a container for other resources, the ransomware\r\nwill call its network resources enumeration function recursively.\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 11 of 15\n\nFor each network resource found by Ryuk, the resource’s name will be appended and separated with a semicolon\r\nto a list that will later be used to encrypt these network resources.\r\nFinally, Ryuk will destroy its encryption key and execute a .BAT file that will delete shadow copies and various\r\nbackup files from the disk.\r\nFigure 13: List of Batch commands to be executed by Ryuk after encrypting the system.\r\nFollowing the Money\r\nRyuk ransomware has not been widely distributed. Similarly to its forefather, HERMES, it has only been used in\r\ntargeted attacks, which makes it a lot harder to track the malware author’s activities and revenues. Almost each\r\nmalware sample was provided a unique wallet and shortly after the ransom payment was made, the funds were\r\ndivided and transmitted through multiple other accounts.\r\nHowever, examining the currency transactions directly from the wallet provided in the ransom note onwards\r\nexposed a pattern, which enabled us to pinpoint wallets that would most likely be used for monetization. We were\r\nalso able to spot a connection between these wallets, as funds paid to them were transferred to several key wallets\r\nat a certain point. This may indicate that a coordinated operation, in which several companies have been carefully\r\ntargeted, is currently taking place using the Ryuk ransomware.\r\nAfter a ransom payment was made to a preassigned wallet, some 25% of the funds (a round amount such as 10 or\r\n12.5 BTC) are transferred to a new wallet. These funds can still be found at that same new wallet that was created\r\nfor them. We can assume that these wallets will later be cashed out. The remaining amount, indeed the majority of\r\nthe original amount, is also transferred to a new wallet; however, the remaining funds are split and relocated again\r\n– some 25% of it is transferred to a new wallet in which it would remain, with the other funds split again, and so\r\non.\r\nInterestingly, several wallets were used more than others, as several transactions originating in different ransom\r\npayments were made to them. These key wallets were in fact the link between the original ransom payments, and\r\nenabled us to measure the extent of these coordinated targeted attacks delivering the Ryuk ransomware. The\r\npattern we uncovered is presented in the chart below.\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 12 of 15\n\nFigure 14: Bitcoin Transaction Flow, from the ransom payment to the cashing out stage.\r\nConclusions\r\nFrom the exploitation phase through to the encryption process and up to the ransom demand itself, the carefully\r\noperated Ryuk campaign is targeting enterprises that are capable of paying a lot of money in order to get back on\r\ntrack.\r\nBoth the nature of the attack and the malware’s own inner workings tie Ryuk to the HERMES ransomware and\r\narouse curiosity regarding the identity of the group behind it and its connection to the Lazarus Group. After\r\nsucceeding with infecting and getting paid some $640,000, we believe that this is not the end of this campaign and\r\nthat additional organizations are likely to fall victim to Ryuk.\r\nCheck Point’s SandBlast Agent Anti-Ransomware product protects against Ryuk ransomware. Here is a forensics\r\nreport of Ryuk, triggered by SandBlast Agent Anti-Ransomware.\r\nAppendix\r\nString decryption Python code:\r\n\"\"\" Ryuk strings decrypter\r\nThis is an IDA Python based script which can be used to decrypt the encrypted\r\nAPI strings in recent Ryuk ransomware samples. After the decryption, the\r\nscript will rename the encrypted string in order to ease analysis.\r\nRyuk sha-256: 8d3f68b16f0710f858d8c1d2c699260e6f43161a5510abb0e7ba567bd72c965b\r\n\"\"\"\r\n__author__ = \"Itay Cohen, aka @megabeets_\"\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 13 of 15\n\n__company__ = \"Check Point Software Technologies Ltd\"\r\nimport idc\r\nfrom idaapi import *\r\ndef decryptStrings (verbose = True):\r\n encrypted_strings_array = 0x1400280D0\r\n lengths_array = 0x1400208B0\r\n num_of_encrypted_strings = 68\r\n key = 'bZIiQ'\r\nif verbose:\r\n print (\"[!] Starting to decrypt the strings\\n\\n\")\r\n \r\n # Iterate over the encrypted strings array\r\n for i in range(num_of_encrypted_strings):\r\n # Get the length of the encrypted string\r\n string_length = idc.Dword(lengths_array + i*4)\r\n \r\n # Get the offset of the encrypted string\r\n string_offset = encrypted_strings_array + i*50\r\n \r\n # Read bytes from\r\n # For IDA version \u003c 7, use get_many_bytes()\r\n encrypted_buffer = get_bytes(string_offset, string_length)\r\n decrypted_string = ''\r\n \r\n # Decrypt the bytes and save it to\r\n for idx, val in enumerate(encrypted_buffer):\r\n decrypted_string += chr( ord(val) ^ ord(key [idx % len(key)]))\r\n \r\n # Set name for the string variable in IDA\r\n idc.MakeName (string_offset, \"dec_\" + decrypted_string)\r\n \r\n # Print to the ouput window\r\n if verbose:\r\n print(\"0x%x : %s\" % (string_offset, decrypted_string,))\r\n if verbose:\r\n print (\"\\n[!] Done.\")\r\n \r\n# Execute the decryption function\r\ndecryptStrings()\r\nIOCs\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 14 of 15\n\nRyuk Ransomware hashes (MD5):\r\nc0202cf6aeab8437c638533d14563d35\r\nd348f536e214a47655af387408b4fca5\r\n958c594909933d4c82e93c22850194aa\r\n86c314bc2dc37ba84f7364acd5108c2b\r\n29340643ca2e6677c19e1d3bf351d654\r\ncb0c1248d3899358a375888bb4e8f3fe\r\n1354ac0d5be0c8d03f4e3aba78d2223e\r\nMalware Dropper hashes (MD5):\r\n5ac0f050f93f86e69026faea1fbb4450\r\nSource: https://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nhttps://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://research.checkpoint.com/ryuk-ransomware-targeted-campaign-break/"
	],
	"report_names": [
		"ryuk-ransomware-targeted-campaign-break"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "34eea331-d052-4096-ae03-a22f1d090bd4",
			"created_at": "2025-08-07T02:03:25.073494Z",
			"updated_at": "2026-04-10T02:00:03.709243Z",
			"deleted_at": null,
			"main_name": "NICKEL ACADEMY",
			"aliases": [
				"ATK3 ",
				"Black Artemis ",
				"COVELLITE ",
				"CTG-2460 ",
				"Citrine Sleet ",
				"Diamond Sleet ",
				"Guardians of Peace",
				"HIDDEN COBRA ",
				"High Anonymous",
				"Labyrinth Chollima ",
				"Lazarus Group ",
				"NNPT Group",
				"New Romanic Cyber Army Team",
				"Temp.Hermit ",
				"UNC577 ",
				"Who Am I?",
				"Whois Team",
				"ZINC "
			],
			"source_name": "Secureworks:NICKEL ACADEMY",
			"tools": [
				"Destover",
				"KorHigh",
				"Volgmer"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "732597b1-40a8-474c-88cc-eb8a421c29f1",
			"created_at": "2025-08-07T02:03:25.087732Z",
			"updated_at": "2026-04-10T02:00:03.776007Z",
			"deleted_at": null,
			"main_name": "NICKEL GLADSTONE",
			"aliases": [
				"APT38 ",
				"ATK 117 ",
				"Alluring Pisces ",
				"Black Alicanto ",
				"Bluenoroff ",
				"CTG-6459 ",
				"Citrine Sleet ",
				"HIDDEN COBRA ",
				"Lazarus Group",
				"Sapphire Sleet ",
				"Selective Pisces ",
				"Stardust Chollima ",
				"T-APT-15 ",
				"TA444 ",
				"TAG-71 "
			],
			"source_name": "Secureworks:NICKEL GLADSTONE",
			"tools": [
				"AlphaNC",
				"Bankshot",
				"CCGC_Proxy",
				"Ratankba",
				"RustBucket",
				"SUGARLOADER",
				"SwiftLoader",
				"Wcry"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a2b92056-9378-4749-926b-7e10c4500dac",
			"created_at": "2023-01-06T13:46:38.430595Z",
			"updated_at": "2026-04-10T02:00:02.971571Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"Operation DarkSeoul",
				"Bureau 121",
				"Group 77",
				"APT38",
				"NICKEL GLADSTONE",
				"G0082",
				"COPERNICIUM",
				"Moonstone Sleet",
				"Operation GhostSecret",
				"APT 38",
				"Appleworm",
				"Unit 121",
				"ATK3",
				"G0032",
				"ATK117",
				"NewRomanic Cyber Army Team",
				"Nickel Academy",
				"Sapphire Sleet",
				"Lazarus group",
				"Hastati Group",
				"Subgroup: Bluenoroff",
				"Operation Troy",
				"Black Artemis",
				"Dark Seoul",
				"Andariel",
				"Labyrinth Chollima",
				"Operation AppleJeus",
				"COVELLITE",
				"Citrine Sleet",
				"DEV-0139",
				"DEV-1222",
				"Hidden Cobra",
				"Bluenoroff",
				"Stardust Chollima",
				"Whois Hacking Team",
				"Diamond Sleet",
				"TA404",
				"BeagleBoyz",
				"APT-C-26"
			],
			"source_name": "MISPGALAXY:Lazarus Group",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "32a223a8-3c79-4146-87c5-8557d38662ae",
			"created_at": "2022-10-25T15:50:23.703698Z",
			"updated_at": "2026-04-10T02:00:05.261989Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"Lazarus Group",
				"Labyrinth Chollima",
				"HIDDEN COBRA",
				"Guardians of Peace",
				"NICKEL ACADEMY",
				"Diamond Sleet"
			],
			"source_name": "MITRE:Lazarus Group",
			"tools": [
				"RawDisk",
				"Proxysvc",
				"BADCALL",
				"FALLCHILL",
				"WannaCry",
				"MagicRAT",
				"HOPLIGHT",
				"TYPEFRAME",
				"Dtrack",
				"HotCroissant",
				"HARDRAIN",
				"Dacls",
				"KEYMARBLE",
				"TAINTEDSCRIBE",
				"AuditCred",
				"netsh",
				"ECCENTRICBANDWAGON",
				"AppleJeus",
				"BLINDINGCAN",
				"ThreatNeedle",
				"Volgmer",
				"Cryptoistic",
				"RATANKBA",
				"Bankshot"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f32df445-9fb4-4234-99e0-3561f6498e4e",
			"created_at": "2022-10-25T16:07:23.756373Z",
			"updated_at": "2026-04-10T02:00:04.739611Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"APT-C-26",
				"ATK 3",
				"Appleworm",
				"Citrine Sleet",
				"DEV-0139",
				"Diamond Sleet",
				"G0032",
				"Gleaming Pisces",
				"Gods Apostles",
				"Gods Disciples",
				"Group 77",
				"Guardians of Peace",
				"Hastati Group",
				"Hidden Cobra",
				"ITG03",
				"Jade Sleet",
				"Labyrinth Chollima",
				"Lazarus Group",
				"NewRomanic Cyber Army Team",
				"Operation 99",
				"Operation AppleJeus",
				"Operation AppleJeus sequel",
				"Operation Blockbuster: Breach of Sony Pictures Entertainment",
				"Operation CryptoCore",
				"Operation Dream Job",
				"Operation Dream Magic",
				"Operation Flame",
				"Operation GhostSecret",
				"Operation In(ter)caption",
				"Operation LolZarus",
				"Operation Marstech Mayhem",
				"Operation No Pineapple!",
				"Operation North Star",
				"Operation Phantom Circuit",
				"Operation Sharpshooter",
				"Operation SyncHole",
				"Operation Ten Days of Rain / DarkSeoul",
				"Operation Troy",
				"SectorA01",
				"Slow Pisces",
				"TA404",
				"TraderTraitor",
				"UNC2970",
				"UNC4034",
				"UNC4736",
				"UNC4899",
				"UNC577",
				"Whois Hacking Team"
			],
			"source_name": "ETDA:Lazarus Group",
			"tools": [
				"3CX Backdoor",
				"3Rat Client",
				"3proxy",
				"AIRDRY",
				"ARTFULPIE",
				"ATMDtrack",
				"AlphaNC",
				"Alreay",
				"Andaratm",
				"AngryRebel",
				"AppleJeus",
				"Aryan",
				"AuditCred",
				"BADCALL",
				"BISTROMATH",
				"BLINDINGCAN",
				"BTC Changer",
				"BUFFETLINE",
				"BanSwift",
				"Bankshot",
				"Bitrep",
				"Bitsran",
				"BlindToad",
				"Bookcode",
				"BootWreck",
				"BottomLoader",
				"Brambul",
				"BravoNC",
				"Breut",
				"COLDCAT",
				"COPPERHEDGE",
				"CROWDEDFLOUNDER",
				"Castov",
				"CheeseTray",
				"CleanToad",
				"ClientTraficForwarder",
				"CollectionRAT",
				"Concealment Troy",
				"Contopee",
				"CookieTime",
				"Cyruslish",
				"DAVESHELL",
				"DBLL Dropper",
				"DLRAT",
				"DRATzarus",
				"DRATzarus RAT",
				"Dacls",
				"Dacls RAT",
				"DarkComet",
				"DarkKomet",
				"DeltaCharlie",
				"DeltaNC",
				"Dembr",
				"Destover",
				"DoublePulsar",
				"Dozer",
				"Dtrack",
				"Duuzer",
				"DyePack",
				"ECCENTRICBANDWAGON",
				"ELECTRICFISH",
				"Escad",
				"EternalBlue",
				"FALLCHILL",
				"FYNLOS",
				"FallChill RAT",
				"Farfli",
				"Fimlis",
				"FoggyBrass",
				"FudModule",
				"Fynloski",
				"Gh0st RAT",
				"Ghost RAT",
				"Gopuram",
				"HARDRAIN",
				"HIDDEN COBRA RAT/Worm",
				"HLOADER",
				"HOOKSHOT",
				"HOPLIGHT",
				"HOTCROISSANT",
				"HOTWAX",
				"HTTP Troy",
				"Hawup",
				"Hawup RAT",
				"Hermes",
				"HotCroissant",
				"HotelAlfa",
				"Hotwax",
				"HtDnDownLoader",
				"Http Dr0pper",
				"ICONICSTEALER",
				"Joanap",
				"Jokra",
				"KANDYKORN",
				"KEYMARBLE",
				"Kaos",
				"KillDisk",
				"KillMBR",
				"Koredos",
				"Krademok",
				"LIGHTSHIFT",
				"LIGHTSHOW",
				"LOLBAS",
				"LOLBins",
				"Lazarus",
				"LightlessCan",
				"Living off the Land",
				"MATA",
				"MBRkiller",
				"MagicRAT",
				"Manuscrypt",
				"Mimail",
				"Mimikatz",
				"Moudour",
				"Mydoom",
				"Mydoor",
				"Mytob",
				"NACHOCHEESE",
				"NachoCheese",
				"NestEgg",
				"NickelLoader",
				"NineRAT",
				"Novarg",
				"NukeSped",
				"OpBlockBuster",
				"PCRat",
				"PEBBLEDASH",
				"PLANKWALK",
				"POOLRAT",
				"PSLogger",
				"PhanDoor",
				"Plink",
				"PondRAT",
				"PowerBrace",
				"PowerRatankba",
				"PowerShell RAT",
				"PowerSpritz",
				"PowerTask",
				"Preft",
				"ProcDump",
				"Proxysvc",
				"PuTTY Link",
				"QUICKRIDE",
				"QUICKRIDE.POWER",
				"Quickcafe",
				"QuiteRAT",
				"R-C1",
				"ROptimizer",
				"Ratabanka",
				"RatabankaPOS",
				"Ratankba",
				"RatankbaPOS",
				"RawDisk",
				"RedShawl",
				"Rifdoor",
				"Rising Sun",
				"Romeo-CoreOne",
				"RomeoAlfa",
				"RomeoBravo",
				"RomeoCharlie",
				"RomeoCore",
				"RomeoDelta",
				"RomeoEcho",
				"RomeoFoxtrot",
				"RomeoGolf",
				"RomeoHotel",
				"RomeoMike",
				"RomeoNovember",
				"RomeoWhiskey",
				"Romeos",
				"RustBucket",
				"SHADYCAT",
				"SHARPKNOT",
				"SIGFLIP",
				"SIMPLESEA",
				"SLICKSHOES",
				"SORRYBRUTE",
				"SUDDENICON",
				"SUGARLOADER",
				"SheepRAT",
				"SierraAlfa",
				"SierraBravo",
				"SierraCharlie",
				"SierraJuliett-MikeOne",
				"SierraJuliett-MikeTwo",
				"SimpleTea",
				"SimplexTea",
				"SmallTiger",
				"Stunnel",
				"TAINTEDSCRIBE",
				"TAXHAUL",
				"TFlower",
				"TOUCHKEY",
				"TOUCHMOVE",
				"TOUCHSHIFT",
				"TOUCHSHOT",
				"TWOPENCE",
				"TYPEFRAME",
				"Tdrop",
				"Tdrop2",
				"ThreatNeedle",
				"Tiger RAT",
				"TigerRAT",
				"Trojan Manuscript",
				"Troy",
				"TroyRAT",
				"VEILEDSIGNAL",
				"VHD",
				"VHD Ransomware",
				"VIVACIOUSGIFT",
				"VSingle",
				"ValeforBeta",
				"Volgmer",
				"Vyveva",
				"W1_RAT",
				"Wana Decrypt0r",
				"WanaCry",
				"WanaCrypt",
				"WanaCrypt0r",
				"WannaCry",
				"WannaCrypt",
				"WannaCryptor",
				"WbBot",
				"Wcry",
				"Win32/KillDisk.NBB",
				"Win32/KillDisk.NBC",
				"Win32/KillDisk.NBD",
				"Win32/KillDisk.NBH",
				"Win32/KillDisk.NBI",
				"WinorDLL64",
				"Winsec",
				"WolfRAT",
				"Wormhole",
				"YamaBot",
				"Yort",
				"ZetaNile",
				"concealment_troy",
				"http_troy",
				"httpdr0pper",
				"httpdropper",
				"klovbot",
				"sRDI"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775701444,
	"ts_updated_at": 1775792299,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d4994d6af99268e34998650645f0b8adf5b963f3.pdf",
		"text": "https://archive.orkl.eu/d4994d6af99268e34998650645f0b8adf5b963f3.txt",
		"img": "https://archive.orkl.eu/d4994d6af99268e34998650645f0b8adf5b963f3.jpg"
	}
}