{
	"id": "06e35648-5b9c-4f0d-806c-72bc38a607df",
	"created_at": "2026-04-06T00:12:51.963567Z",
	"updated_at": "2026-04-10T13:12:20.500875Z",
	"deleted_at": null,
	"sha1_hash": "cbe5aaaf0980f560b9c63d357967e65d0b717072",
	"title": "Funtastic Packers And Where To Find Them",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 13351175,
	"plain_text": "Funtastic Packers And Where To Find Them\r\nBy Eli Salem\r\nPublished: 2021-01-18 · Archived: 2026-04-05 20:37:45 UTC\r\n11 min read\r\nJan 18, 2021\r\nWhat's Inside?\r\nIn malware, we often see threat actors that tend to obfuscate or encrypt their code in order to slow down the\r\nanalysis of security researchers. To do so, many authors tend to use open-source packers but also craft their own\r\ncustom packers.\r\nWhile custom packers are definitely not a new thing, it is always interesting to observe how they work, and what\r\nis the shared similarities between them in different malware.\r\nIn this writeup, I will present some known first-stage malware that uses custom packers or other packing\r\nmechanisms.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 1 of 27\n\nI will also share some theoretical insights regarding the way to approach these packers, and hopefully, shed some\r\nlight using a step-by-step dynamic observation.\r\nThe purpose here is to give some guidelines on what to look for when we try to understand how the unpacking\r\nmechanism works.\r\nNote: this writeup is about observing the unpacking mechanism, therefore, faster methods to get the final payload\r\nsuch as:\r\nTracking specific API calls and ignoring others, or, focusing on the code injection parts; won't be mentioned -the\r\ngoal of this article is to explain the unpacking mechanism and not the fastest way to get the final payload.\r\nGet2Downloader\r\nThis downloader was first emerged in 2019 and associated with TA505 threat actors. It is known to deliver\r\ndifferent malware, most notably Sdbbot.\r\nAs in every case, when malware wants to write unpacked content, it first needs to allocate the memory space for\r\nit. Get2 uses the API call VirtualAlloc three times, we’ll focus only on the last two.\r\nIn each allocated memory we’ll set a write hardware breakpoint, this assures us that whenever something will be\r\nwritten we’ll know about lt.\r\nPress enter or click to view image in full size\r\nGet2: First Allocated Memory\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 2 of 27\n\nGet2: Second Allocated Memory\r\nAfter settings the breakpoints, we'll hit run until we reach the first breakpoint. Then, we’ll observe a loop whose\r\nobjective is to write content to the first allocated memory.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 3 of 27\n\nGet2: First Allocated Memory being written\r\nTo save time, we’ll set a breakpoint one step after the loop to see the entire written content. Then, we observe that\r\nthe memory section is filled with obfuscated data.\r\nGet2: First Allocated Memory obfuscated content\r\nAfter a couple of instructions, we found ourselves in another loop. At first glance, it seems this loop has\r\ncharacteristics we expect from traditional decryption\\encryption routines, such as shr (shift right), xor, and rol\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 4 of 27\n\n(rotate left) opcodes. The loop changes the first bytes of the obfuscated content to “M8Z”, which starts to\r\nresemble the classic “MZ” string.\r\nGet2: M8Z string written\r\nTo see the final stage of this decryption loop, we’ll set a breakpoint one step after the jump instruction and hit run.\r\nThen, additional string fractures such as: “This program cannot run in DOS mode” and the word “PE”, will be\r\nrevealed. Overall, we understand that this loop was responsible for taking the obfuscated content and do some\r\ndecryption. However, it is obvious that this is not the final stage.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 5 of 27\n\nGet2: decryption loop ends\r\nAfter the loop ends, we encounter a call to one of the Get2 functions. This function is important for the final\r\ndecryption stage. We’ll set a breakpoint on it and step into it.\r\nGet2: Second stage decryption function\r\nAs we enter, we see that our second allocated memory has been manipulated., and the letter M has been written\r\ninto it. This is because the function is copying and manipulating the content from the first to the second allocated\r\nmemory.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 6 of 27\n\nGet2: Second Allocated Memory Being Written\r\nThe entire process of writing content to the second allocated memory is also part of a large loop. Although we get\r\nwhat seems to be a clean portable executable, we didn't finish yet. When we inspect the PE headers we see that it\r\nis packed with a UPX packer.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 7 of 27\n\nGet2: Second Allocated Memory Packed With UPX\r\nThe UPX packer is one of the most common open-source packers. For attackers, it's easy to use packer and it also\r\nprovides reliability because of the fact that it is not a complex packer. There are several ways to overcome this\r\npacker, most of them are documented on the internet. In this case, I choose to use the UPX utility of CFF Explorer.\r\nNote: In some recent versions of Get2 malware, the UPX part is missing.\r\nThe final stages of the unpacking mechanism are portrayed in the following diagram:\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 8 of 27\n\nWhile inspecting the final unpacked file, we’ll see it has low entropy and a large number of strings, functions\r\nnames, and data.\r\nPress enter or click to view image in full size\r\nGet2: Final unpacked payload\r\nQbot\r\nQbot (aka QakBot, Pinkslipbot, QuakBot) is one of the known and prevalent banking trojans in the last years and\r\nbeen active for years since 2007.\r\nThe way to unpack the first dropper of Qbot is relatively simple and already been documented. Setting a\r\nbreakpoint on VirtualProtect and inspecting several mov instructions after it, will do the trick. Otherwise, we can\r\nuse automated tools such as PE-Sieve. However, where is the fun in that?\r\nGet Eli Salem’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 9 of 27\n\nTo start, we’ll set a breakpoint on VirtualAllocEx and VirtualAlloc, then, click Run. We’ll hit on VirtualAllocEx,\r\nand to assure nothing slips away, put a write hardware breakpoint on the newly allocated memory. Then, hit run.\r\nQbot: VirtualAllocEx allocated memory\r\nWe reach our breakpoint in a function that writes obfuscated data, byte by byte, into this allocated memory.\r\nSimilar to the Get2 malware or basically any other malware that has an unpacking mechanism, the data is written\r\ninside a loop.\r\nPress enter or click to view image in full size\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 10 of 27\n\nQbot: Data Written In The Allocated Memory\r\nIn order to speed up the process, we’ll set a breakpoint just after the loop. Then, an entire obfuscated content will\r\nbe written.\r\nQbot: Obfuscated Data Written In The Allocated Memory\r\nNote: Packed binaries tend to contain an embedded obfuscated content that will be read and written into newly\r\nallocated memory sections. Initial static analysis of Qbot shows the obfuscated content to be written.\r\nPress enter or click to view image in full size\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 11 of 27\n\nQbot: Static analysis — obfuscated content\r\nInterestingly, this memory section is being manipulated again and again by several loops. Then, it being\r\noverwritten until the upper part is filled with the unknown string “aaa45678901234” followed by several names of\r\nAPI calls.\r\nPress enter or click to view image in full size\r\nQbot: Data being Overwritten In The Allocated Memory\r\nThe rest of the memory section appears to be more obfuscated. However, when taking a closer look, it does has\r\nfragments of strings that can indicate a potential encrypted PE file.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 12 of 27\n\nQbot: Signs Of Obfuscated PE\r\nSeveral instructions later, in the CPU window, we observe the string “aaa45678901234” is being modified by\r\nseveral mov instructions.\r\nThese instructions assign the HEX value “47 65 74 50 72 6f 63 41 64 64 72 65 73 73” to the ECX register (in\r\nASCII, these bytes are translated to “GetProcAddress”). This technique is called Stack-Strings and will appear\r\nseveral times during the Qbot unpacking process. Then, the GetProcAddress string being used by another\r\nfunction.\r\nPress enter or click to view image in full size\r\nQbot: GetProcAddress Stack-Strings\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 13 of 27\n\nNext, the packer call to another function that deals with VirtualAlloc by using the Stack-strings concept. As\r\nobserved in the image below, it will store the VirtualAlloc string from EBP-18 to EBP-C.\r\nPress enter or click to view image in full size\r\nQbot: VirtualAlloc Stack-Strings\r\nThen, the function will do the following:\r\n1. Calling GetProcAddress (the string resides in EBP-4) and request VirtualAlloc.\r\n2. GetProcAddress returns the address of VirtualAlloc (which is stored in EAX), and move it to EBP-8.\r\n3. VirtualAlloc being called with Read-Write-Execute permissions.\r\nSurprisingly, this call did not trigger the VirtualAlloc breakpoint we set at the beginning of our investigation.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 14 of 27\n\nQbot: Call For VirtualAlloc Steps\r\nSimilar to previous times, we’ll set a breakpoint on the newly allocated memory, just in case we’ll not miss any\r\ncontent that will be written there.\r\nQbot: Newly Allocated Memory\r\nFortunately, after several instructions, we encounter a loop that starts to write content to the newly allocated\r\nmemory. It starts copying the data stored in the EDX register, which points to an address found several offsets\r\nfurther in the first allocated memory. As we remember, we suspected it might contain encrypted PE.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 15 of 27\n\nQbot: Data Copied From First To Second Allocated Memory\r\nAs always, to speed things up, we’ll set a breakpoint one step after the loop and hit Run. We can see that the entire\r\npart from the first allocated memory has been copied into the second allocated memory.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 16 of 27\n\nQbot: Data Copied From First To Second Allocated Memory\r\nThen, we encounter another loop. This loop deobfuscates the entire second allocated memory. It is noticed by\r\nobserving the magic string -”MZ” that appears after the first iterations.\r\nPress enter or click to view image in full size\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 17 of 27\n\nQbot: Second Allocated Memory Deobfuscated\r\nThis loop contains several characteristics that already observed in the Get2 malware unpacking mechanism. The\r\nuse of xor and add opcodes.\r\nAs always, when we encounter these types of loops we’ll set a breakpoint step after the loop to get the final result,\r\nwhich is a clean portable executable.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 18 of 27\n\nQbot: Unpacked PE\r\nThe final stages of the unpacking mechanism are portrayed in the following diagram:\r\nNow, we’ll dump this memory section and inspect it with tools such as IDA or PEstudio. The second stage of Qbot\r\nis known to contain its further payload in its resource section, and also contain RC4 encryption and BLZPack\r\ndecompression.\r\nPress enter or click to view image in full size\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 19 of 27\n\nQbot: Qbot’s Second Stage Payload At The Resource Section\r\nIcedID\r\nIcedID aka Bokbot is also one of the most prevalent banking trojans in the last years. It is known to be associated\r\nwith Lunar Spider threat actors.\r\nUnpacking the first dropper of IcedID is pretty simple, similar to Qbot, we only need to set breakpoints on\r\nVirtualAlloc and VirtualProtect. In the unpacking mechanism, the second time VirtualProtect will be called it will\r\nindicate the unpacked IcedID. As said, we’ll focus on how the IcedID unpacking mechanism works rather than\r\ngetting the fastest way to unpack it.\r\nAs we start, by setting a breakpoint on VirtualAlloc and VirtualProtect, we’ll notice a difference between the\r\nIcedID and Qbot, Get2 unpacking mechanisms. Traditionally, we expect to see a memory allocation before\r\neverything else. In IcedID it’s not the case- VirtualProtect is being called before VirtualAlloc.\r\nBy inspecting the “lpAddress” argument in VirtualProtect we’ll notice that it appears to deal with shellcode\r\nexecution. This is visible with the byte sequence E8 00 00 00 00 which is a relative call for the next instruction.\r\nIn this writeup, I won't cover the entire shellcode investigation, only the unpacking mechanism. For those of you\r\nwho want to explore it, you can click on the shellcode memory address, press “follow in disassembler”, set a\r\nbreakpoint on the relative call, and hit Run.\r\nPress enter or click to view image in full size\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 20 of 27\n\nIcedID: Shellcode\r\nThen, we’ll hit Run again and encounter VirtualAlloc three different times. In the third time, we’ll set a write\r\nhardware breakpoint on the newly allocated memory.\r\nIcedID: Call To VirtualAlloc\r\nNext, we encounter a function, which has a loop that copies data to the newly allocated memory. Interestingly, in\r\nthe previous malware, when we saw data moved it always copied byte by byte. Nonetheless, in this case, we see\r\nthat the copy is managed by an instruction called rep movsb. This instruction by default moving data from the ESI\r\nto the EDI register, which points to the newly allocated memory.\r\nPress enter or click to view image in full size\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 21 of 27\n\nIcedID: Data Copied To The Allocated Memory\r\nThis opcode of data transfer will be used multiple times in the IcedID unpacking mechanism.\r\nPress enter or click to view image in full size\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 22 of 27\n\nIcedID: Data Comparison ESI vs EDI (Identical)\r\nWe’ll hit Run again until we found ourselves in another data manipulating loop. This loop is significantly smaller\r\nand appears to modify the data using xor and ror (rotate right) opcodes. While modifying, we notice some signs of\r\na portable executable, with the strings “M8Z” (as we saw in the Get2 malware).\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 23 of 27\n\nIcedID: Data being decrypted\r\nAs always, to speed up the process we’ll set a breakpoint one step after this loop and we’ll hit Run. Once we did\r\nthat, we can see that some bytes have been changed. Still, it’s not a clean portable executable.\r\nIcedID: Data being decrypted\r\nThen, we observe something unusual. We can see again the movsb opcode in a larger loop, but now it copies data\r\nfrom the upper part of the allocated memory (the one from the image above) which is stored in the ESI register, to\r\nan address in the same memory space located several offsets after (which is also stored in the EDI register).\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 24 of 27\n\nAfter a few iterations and data manipulation functions, we observe the bytes 4D 5A and the string “MZ” at the\r\nbeginning of the memory to which the movsb opcode writes.\r\nIcedID: Data Copied And Decrypted In The Upper Part Of The Memory\r\nEventually, we understand the purpose of this loop -writing a clean portable executable in this memory part.\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 25 of 27\n\nIcedID: Clean PE File\r\nThe final stages of the unpacking mechanism are portrayed in the following diagram:\r\nIcedID: Unpacking Diagram\r\nAfter the loop ends, we’ll dump the file and inspect it with other tools. This file, which is actually a module, is the\r\nsecond stage of IcedID, which is a downloader for the final payload.\r\nPress enter or click to view image in full size\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 26 of 27\n\nIcedID: Unpacked PE In Pestudio\r\nConclusion\r\nIn this writeup, we observed three first-stage malware unpacking mechanisms. And although each one has its own\r\nway to unpack itself, we saw several characteristics they all shared.\r\nSimilarly, whether its unpacking or decrypting, the following features will most likely occur:\r\nTraditionally, packers tend to start with reading an obfuscated data embedded in the PE, and writing it to a\r\nnewly allocated memory.\r\nWriting to, or reading from newly allocated memory will most likely happen inside a loop. So loops can be\r\na good starting point when we search for decryption routines.\r\nMost of the time, data will be copied or modified byte by byte. Therefore, it is important to pay attention to\r\nmoves of one byte (mov byte ptr)\r\nSome opcodes such as xor,rol,ror,shl,shr are likely to be found in the decryption loop.\r\nSource: https://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nhttps://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7\r\nPage 27 of 27",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://elis531989.medium.com/funtastic-packers-and-where-to-find-them-41429a7ef9a7"
	],
	"report_names": [
		"funtastic-packers-and-where-to-find-them-41429a7ef9a7"
	],
	"threat_actors": [
		{
			"id": "c2385aea-d30b-4dbc-844d-fef465cf3ea9",
			"created_at": "2023-01-06T13:46:38.916521Z",
			"updated_at": "2026-04-10T02:00:03.144667Z",
			"deleted_at": null,
			"main_name": "LUNAR SPIDER",
			"aliases": [
				"GOLD SWATHMORE"
			],
			"source_name": "MISPGALAXY:LUNAR SPIDER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "7cfe3bc9-7a6c-4ee1-a635-5ea7b947147f",
			"created_at": "2024-06-19T02:03:08.122318Z",
			"updated_at": "2026-04-10T02:00:03.652418Z",
			"deleted_at": null,
			"main_name": "GOLD SWATHMORE",
			"aliases": [
				"Lunar Spider "
			],
			"source_name": "Secureworks:GOLD SWATHMORE",
			"tools": [
				"Cobalt Strike",
				"GlobeImposter",
				"Gozi",
				"Gozi Trojan",
				"IcedID",
				"Latrodectus",
				"TrickBot"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "5e6b31a6-80e3-4e7d-8b0a-d94897ce9b59",
			"created_at": "2024-06-19T02:03:08.128175Z",
			"updated_at": "2026-04-10T02:00:03.636663Z",
			"deleted_at": null,
			"main_name": "GOLD TAHOE",
			"aliases": [
				"Cl0P Group Identity",
				"FIN11 ",
				"GRACEFUL SPIDER ",
				"SectorJ04 ",
				"Spandex Tempest ",
				"TA505 "
			],
			"source_name": "Secureworks:GOLD TAHOE",
			"tools": [
				"Clop",
				"Cobalt Strike",
				"FlawedAmmy",
				"Get2",
				"GraceWire",
				"Malichus",
				"SDBbot",
				"ServHelper",
				"TrueBot"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "475ea823-9e47-4098-b235-0900bc1a5362",
			"created_at": "2022-10-25T16:07:24.506596Z",
			"updated_at": "2026-04-10T02:00:05.015497Z",
			"deleted_at": null,
			"main_name": "Lunar Spider",
			"aliases": [
				"Gold SwathMore"
			],
			"source_name": "ETDA:Lunar Spider",
			"tools": [
				"BokBot",
				"IceID",
				"IcedID",
				"NeverQuest",
				"Vawtrak",
				"grabnew"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "75d4d6a9-b5d1-4087-a7a0-e4a9587c45f4",
			"created_at": "2022-10-25T15:50:23.5188Z",
			"updated_at": "2026-04-10T02:00:05.26565Z",
			"deleted_at": null,
			"main_name": "TA505",
			"aliases": [
				"TA505",
				"Hive0065",
				"Spandex Tempest",
				"CHIMBORAZO"
			],
			"source_name": "MITRE:TA505",
			"tools": [
				"AdFind",
				"Azorult",
				"FlawedAmmyy",
				"Mimikatz",
				"Dridex",
				"TrickBot",
				"Get2",
				"FlawedGrace",
				"Cobalt Strike",
				"ServHelper",
				"Amadey",
				"SDBbot",
				"PowerSploit"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "99cb4e5b-8071-4f9e-aa1d-45bfbb6197e3",
			"created_at": "2023-01-06T13:46:38.860754Z",
			"updated_at": "2026-04-10T02:00:03.125179Z",
			"deleted_at": null,
			"main_name": "TA505",
			"aliases": [
				"SectorJ04",
				"SectorJ04 Group",
				"ATK103",
				"GRACEFUL SPIDER",
				"GOLD TAHOE",
				"Dudear",
				"G0092",
				"Hive0065",
				"CHIMBORAZO",
				"Spandex Tempest"
			],
			"source_name": "MISPGALAXY:TA505",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "e447d393-c259-46e2-9932-19be2ba67149",
			"created_at": "2022-10-25T16:07:24.28282Z",
			"updated_at": "2026-04-10T02:00:04.921616Z",
			"deleted_at": null,
			"main_name": "TA505",
			"aliases": [
				"ATK 103",
				"Chimborazo",
				"G0092",
				"Gold Evergreen",
				"Gold Tahoe",
				"Graceful Spider",
				"Hive0065",
				"Operation Tovar",
				"Operation Trident Breach",
				"SectorJ04",
				"Spandex Tempest",
				"TA505",
				"TEMP.Warlock"
			],
			"source_name": "ETDA:TA505",
			"tools": [
				"Amadey",
				"AmmyyRAT",
				"AndroMut",
				"Azer",
				"Bart",
				"Bugat v5",
				"CryptFile2",
				"CryptoLocker",
				"CryptoMix",
				"CryptoShield",
				"Dridex",
				"Dudear",
				"EmailStealer",
				"FRIENDSPEAK",
				"Fake Globe",
				"Fareit",
				"FlawedAmmyy",
				"FlawedGrace",
				"FlowerPippi",
				"GOZ",
				"GameOver Zeus",
				"GazGolder",
				"Gelup",
				"Get2",
				"GetandGo",
				"GlobeImposter",
				"Gorhax",
				"GraceWire",
				"Gussdoor",
				"Jaff",
				"Kasidet",
				"Kegotip",
				"Kneber",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"Locky",
				"MINEBRIDGE",
				"MINEBRIDGE RAT",
				"MirrorBlast",
				"Neutrino Bot",
				"Neutrino Exploit Kit",
				"P2P Zeus",
				"Peer-to-Peer Zeus",
				"Philadelphia",
				"Philadephia Ransom",
				"Pony Loader",
				"Rakhni",
				"ReflectiveGnome",
				"Remote Manipulator System",
				"RockLoader",
				"RuRAT",
				"SDBbot",
				"ServHelper",
				"Shifu",
				"Siplog",
				"TeslaGun",
				"TiniMet",
				"TinyMet",
				"Trojan.Zbot",
				"Wsnpoem",
				"Zbot",
				"Zeta",
				"ZeuS",
				"Zeus"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434371,
	"ts_updated_at": 1775826740,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cbe5aaaf0980f560b9c63d357967e65d0b717072.pdf",
		"text": "https://archive.orkl.eu/cbe5aaaf0980f560b9c63d357967e65d0b717072.txt",
		"img": "https://archive.orkl.eu/cbe5aaaf0980f560b9c63d357967e65d0b717072.jpg"
	}
}