{
	"id": "c34cb32d-e6e9-432e-83bc-a0853ac5e403",
	"created_at": "2026-04-06T00:08:39.883702Z",
	"updated_at": "2026-04-10T03:37:08.813531Z",
	"deleted_at": null,
	"sha1_hash": "45d53cf79a35578be27e4d7d97b4d23b31392b4d",
	"title": "Malware-analysis-and-Reverse-engineering/kpot2/KPOT.md at main · Dump-GUY/Malware-analysis-and-Reverse-engineering",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 6601369,
	"plain_text": "Malware-analysis-and-Reverse-engineering/kpot2/KPOT.md at\r\nmain · Dump-GUY/Malware-analysis-and-Reverse-engineering\r\nBy Dump-GUY\r\nArchived: 2026-04-05 16:35:39 UTC\r\nReverse engineering KPOT v2.0 Stealer\r\nKPOT Stealer is a “stealer” malware that focuses on exfiltrating account information and other data from web\r\nbrowsers, instant messengers, email, VPN, RDP, FTP, cryptocurrency, and gaming software.\r\nSample:[Virustotal]\r\nAt first it is usually good to start with a little recon about this sample. For this purpose, I usually use browser\r\nextension called “Mitaka” [https://github.com/ninoseki/mitaka]. This is very useful browser extension for IOC\r\nOSINT search.\r\nTo be more sure about first assumption that it could be a “kpot” stealer, it is also good to perform a YARA\r\nscanning on this sample. I prefer YARA rules from Malpedia. [https://malpedia.caad.fkie.fraunhofer.de/]\r\nSo where to start? Usually one of my first questions is: “Is it packed or somehow encrypted?”\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 1 of 31\n\nI would not be covering the whole – not so interesting static analysis of file, but only focusing on the IAT of the\r\nsample and entropy which usually unhide that the sample is packed.\r\nWell in this case it looks like deterministic signatures cannot identify some well-known packer.\r\nLet´s try something what works almost every time. Another picture is more than words.\r\nYou can see that the sample has only 4 imports and the entropy of the .text code section is too high – packed.\r\nSo for now we know that we have to deal with sample which is some kind of stealer and it is probably encrypted\r\nor packed.\r\nLet’s start Reversing !!!\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 2 of 31\n\nAfter throwing the sample to IDA, we can clearly see that in the start (entrypoint) there are 4 functions which\r\nshould be in our interest.\r\nYou can see also unresolved calls like “call dword_4151C0” – these calls are pointing to some location in .data\r\nsection which is now empty and probably gets filled with addresses later.\r\nSo we have almost no imports and plenty of unresolved calls. Let’s start with the 4 interesting functions\r\nmentioned before.\r\nFirst function is sub_404477 – this function is not interesting at all. It is only clearing 20 bytes in memory for call\r\nLoadUserProfileW.\r\nSo let’s continue to another call sub_4042FC. This function is locating PEB exactly ProcessHeap and saving it to\r\nlocation dword_415224.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 3 of 31\n\nWe can confirm it in windbg where we can easily parse PEB structure.\r\nMove to the next function sub_4058FB. This function is the most interesting where string decryption and API\r\nresolving happens.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 4 of 31\n\nAt first, we will focus on the function sub_40C8F5 which you can see is referenced from 69 locations.\r\nWe can see this function (sub_40C8F5) in the picture below. It looks like some basic xor cipher. It also looks like\r\nthat decompiler has some hard time to produce us more pretty code so we help him.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 5 of 31\n\nSo first of all, we check the arguments to this function and retype it correctly. Function sub_40C8F5 takes 2\r\narguments, where the first one is some hardcoded unsigned _int8 which looks like some kind of index and the\r\nsecond one is a pointer to stack address.\r\nFrom the decompiler view we can see that the second argument is actually pointer to BYTE. If we set the types\r\nand names of variables correctly we can see better but not the best results.\r\nFor better results, we must check also the nullsub_1 which is not a function but address to array of structures.\r\nLet’s undefine the nullsub_1 firstly.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 6 of 31\n\nYou can see that the index variable is used for pointing to the specific structure which would be probably 8bytes in\r\nsize. We can confirm it when we check the address .text:00401288 where we can see another 183 structures – 8\r\nbytes in size.\r\nWhen we check the address .text:00401288, it looks like the first BYTE value “C3” is used as xor key, second\r\nBYTE value could be unidentified (undefined), the WORD “0013” looks like length of string which will be xored\r\nand the last DWORD (00403594) is the address where our encrypted string is located. Let’s check that address\r\n(403594) if our assumption is correct and if there is some kind of encrypted string with length 13h (19).\r\nOur first assumption was correct so let’s create a structure and apply it as array of structures.\r\nTo apply our created structure “Decrypt_string_Struct” simply navigate to location 00401288 and press ALT+Q\r\nand choose newly created structure.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 7 of 31\n\nConvert the structure to array with array size = 183.\r\nAnd now we are ready to check our better decompiled function String_Decrypt1. Below is comparing of\r\ndecompiled function String_Decrypt1 before and after modification.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 8 of 31\n\nSo this algorithm is very basic: First argument to this function is index of the structure in array and second\r\nargument is location on stack where the decrypted string is saved.\r\nKey (BYTE) from the structure is xored with each BYTE in the location (Encrypted_string_pointer) from our\r\nindexed structure, till it reaches the length of encrypted string.\r\nLet’s quickly confirm it for the first structure in array with python.\r\nWe were correct and obtained our first IOC.\r\nBefore jumping to IDAPython we forgot something. If you remember the function String_Decrypt1 was\r\nreferenced from 69 locations but our array of structures contains 183 members.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 9 of 31\n\nSo we could check Xreferences to our array of structures if we could find another String_DecryptX function.\r\nWe were right, there is another one. Quick checking that function (sub_40C929) revealed that it is basically the\r\nsame as function String_Decrypt1. So we rename it to String_Decrypt2.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 10 of 31\n\nNow when we found both functions referencing our array of structures, we can jump to IDAPython and write a\r\ndecryptor.\r\nThe final decryptor could be something, what will find all location from where our 2 string-decrypting functions\r\n(String_Decrypt1, String_Decrypt2) are called. After it finds these locations it will grab the first argument as our\r\n“INDEX” to structure, find and parse the structure[index]. This will serve us for decrypting the current string so\r\nwe could insert a comment to location from where the string-decrypt function was called.\r\nDuring the creating of decryptor, I found one quite tricky problem with locating the first argument value “INDEX”\r\nfor our (String_Decrypt1, String_Decrypt2) functions. You can see it on the picture below where I let IDA with\r\nlittle help from IDAPython to print assembly line for all previous instruction before our functions\r\n(String_Decrypt1, String_Decrypt2) get called. The script part is self-explanatory.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 11 of 31\n\nYou can find script “Find_previous_instruction.py” here [Find_previous_instruction.py].\r\nWe must deal with locating the first argument during the string-decryptor implementation. In the picture below is\r\nthe string-decryptor script in IDAPython for the “String_Decrypt1” function.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 12 of 31\n\nString-decryptor script for the “String_Decrypt2” function is little different only in area of searching and\r\nextracting the first argument VALUE (index) to function String_Decrypt2.\r\nYou can find both scripts for decrypting functions (String_Decrypt1, String_Decrypt2) here\r\n[Decrypt_KPOT_Strings1.py, Decrypt_KPOT_Strings2.py].\r\nAfter running these scripts, we get commented all location from where (String_Decrypt1, String_Decrypt2) are\r\ncalled with decrypted strings in both assembly view and decompile view.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 13 of 31\n\nIn Output window we could see some information like: String_Decrypt1 function address, count of references and\r\nfor each processed reference is shown - current index value, current structure in hex, current xor KEY, length of\r\nencrypted string, address where the encrypted string is located and finally decrypted string.\r\nAs we are now able to see decrypted strings we are getting some ideas about functionality of this sample. As you\r\ncan see we were able to get 211 locations with decrypted strings. Some of them are referencing the same string.\r\nWe can clearly say that this sample is some kind of credential, cryptocurrency stealer…\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 14 of 31\n\nSo for now strings are decrypted and we can continue to resolve API calls.\r\nWe will continue with our string-decrypting and API resolving function sub_4058FB to see what is going on next.\r\nWe can see that there will be probably some kind of API name hashing which after matching hash of API name,\r\nthe address of the API function will be saved to the hardcoded memory location. In the picture below we can see\r\nthe stack preparation for the API name hashing and resolving.\r\nAfter the stack is prepared two functions get called. Let’s check the first function sub_406936.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 15 of 31\n\nThe function sub_406936 is basically parsing PEB structure and loading base address of the kernel32.dll module.\r\nYou can easily confirm it with help of IDA _PEB struct or windbg as in the pictures below. It is finding the PEB\r\nstructure, _PEB_LDR_DATA where it finds first member in InLoadOrderModuleList which is our sample\r\nkpot2.exe. After that, it finds a location of the third loaded module (kernel32.dll) and extracts the base address.\r\nThis base address of kernel32.dll is passed to the next function sub_4045DC so it will be used to find addresses of\r\nexport functions.\r\nWe can move to the next function sub_4045DC which is responsible for finding address of LoadLibraryA API\r\nfunction from kernel32.dll module.\r\nThis function (sub_4045DC) is not responsible only for finding address of LoadLibraryA but it is able to find API\r\naddress via hash value of its name and base address of module as arguments.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 16 of 31\n\nSo we can clearly rename it as function “Find_api_via_HASH”. With a little help with tool like PEbear\r\n[https://github.com/hasherezade/pe-bear-releases] we could properly annotate the function sub_4045DC -\r\n“Find_api_via_HASH”. In this case where arguments to the function are kernel32.dll base address and API name\r\nhash 0x822FC0FA (LoadLibraryA), it is parsing kernel32.dll and searching for export function name which hash\r\nis 0x822FC0FA.\r\nWe can focus more on the function Api_hashing_func later.\r\nOf course we can save some time and let IDA help you with defaultly defined structs for PE. But I personally\r\nthink that it is a needed skill to understand and be able to parse PE manually.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 17 of 31\n\nSo let´s jump to the function Api_hashing_func (0x403E1C) which you could see in the picture below is\r\nimplementing some probably modified version of well-known hashing algorithm.\r\nWe could use a little help to find out what hash algorithm is implemented from another excellent tool Capa\r\n[https://github.com/fireeye/capa]. This gives us a hint that it could be hashing algorithm of type murmur3. We will\r\ncome back to this hashing algorithm later.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 18 of 31\n\nSo for now, we have more information and can come back and continue with function sub_4058FB - picture\r\nbelow which I populated with all known info. You can see that some another dlls are loaded and also another\r\nfunction sub_40694A is called.\r\nFunction sub_40694A is parsing PEB where it returns ntdll.dll base address.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 19 of 31\n\nSo we can continue and finally reach the interesting part.\r\nIn the picture below, we can see the last part of sub_4058FB which we can clearly rename now as\r\n“String_Api_Decrypt”. This last part as you can see is responsible for resolving all API functions and saving them\r\nto .data section in memory. All these resolved API functions addresses are later in code referenced. You can see\r\nthat there is a loop which is looping through all API name hashes saved on stack before and calling\r\nFind_api_via_HASH.\r\nSo now we have more options to obtain and populate all resolved API functions in our code. One of the option is\r\nto implement murmur3 hashing algorithm and with help of IDAPython, find all API function name hashes to\r\nprocess it with our algorithm. As we did some IDAPython scripting before and I want to show you different\r\nmethods you can only see that our assumption about murmur3 hashing algorithm is right in the pictures below:\r\nAccording to our annotated code – the hash of API function name LoadLibraryA is 0x822FC0FA\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 20 of 31\n\nWe are also able to find out that murmur3 is using Seed value 0x5BCFB733 by examining the code in function\r\nApi_hashing_func (0x403E1C).\r\nTo verify that it is really murmur3 hashing algorithm with seed 0x5BCFB733:\r\nOur assumption about hashing algorithm is right so move next.\r\nThe another option to obtain and populate all resolved API functions in our code is to debug the sample kpot2 and\r\nafter API functions addresses get resolved, apply plugin Scylla to reconstruct IAT – this sometimes does not work\r\nwell. Option we will use and which I am finding more interesting and in this case perfectly suitable is to use tool\r\n“apiscout” [https://github.com/danielplohmann/apiscout]. This tool is extremely useful in situation like this.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 21 of 31\n\nWhen we have all information about how the API resolving works, we could let the sample populate the resolved\r\nAPI function addresses in debugger, dump the process from memory and after that, we need something what is\r\nable to find in our dumped memory all populated API function addresses and annotate it for us. This is the time\r\nwhen apiscout comes to save the situation.\r\nOne of the feature of apiscout is creating of database of all API functions (exports of module). We can let the\r\napiscout build the database from all dlls on our system or we can select only some of them. It is basically parsing\r\nall modules exports and creating database with information like name of API function, VA, ASLR offset etc…\r\nLet’s start with dumping our kpot2.exe process from memory in debugger like x64dbg after it populates the\r\nresolved API function addresses. We put a breakpoint after the call sub_4058FB - “String_Api_Decrypt” and\r\ndump the process. To find location of this function in debugger easily, do not forget to disable ASLR in the\r\noptional header of kpot2.exe.\r\nLocating our sub_4058FB - “String_Api_Decrypt function.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 22 of 31\n\nDumping the kpot2.exe process from memory with plugin OllyDumpEx.\r\nConfirmation in IDA that all referenced API addresses are already populated in our kpot2 process dump\r\n“kpot2_dump.bin”:\r\nApiscout is able to work also on system with ASLR enabled but in case we want to choose apiscout option to\r\nignore ASLR, we must disable the ASLR before we perform the process dump of kpot2.exe – find registry key:\r\n[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management]\r\nCreate a new dword value: “MoveImages” = dword:00000000 (without quote)\r\nRestart system.\r\nIf we do not want to create database of all dlls from our system, first of all we should find and copy to some\r\nlocation all dlls which is our sample kpot2.exe loading and processing:\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 23 of 31\n\nWe can see this information in debugger from where we can copy the whole table to .txt file:\r\nExtract dlls path with some regex, editors etc…\r\nTo copy all dlls from provided paths with powershell:\r\nNow when we have all our needed dlls we start with apiscout – “DatabaseBuilder.py” to create our database.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 24 of 31\n\nNow when we have build our kpot2_DB.json, before we apply it to our previously created process dump file in\r\nIDA “kpot2_dump.bin”, we can verify that apiscout is able to find all API functions in our dump according to\r\nkpot2_DB.json. For this purpose, we use apiscout tool “scout.py” as you can see in the picture below.\r\nWe can see that apiscout was successful and there is more – something called “WinApi1024 vector”. Basically\r\nspeaking it is something like ImpHash on steroids. You can read more about Apivector here: [https://byte-atlas.blogspot.com/2018/04/apivectors.html]. As we get WinApi1024 vector of our kpot2_dump.bin calculated,\r\nwe can use it against big database maintained on Malpedia which is covering big amount of well-known malware\r\nfamilies [https://malpedia.caad.fkie.fraunhofer.de/apiqr/]. We can see that our WinApi1024 vector is matched\r\n100% with family “win.kpot_stealer” below.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 25 of 31\n\nTo apply all previously annotated names of functions from previous IDA database file to our newly created kpot2\r\nprocess dump “kpot2_dump.bin”, we could use IDA plugin called “rizzo”\r\n[https://github.com/tacnetsol/ida/tree/master/plugins/rizzo].\r\nAfter that, previously created IDAPython scripts for decrypting strings must be run again\r\n(Decrypt_KPOT_Strings1.py, Decrypt_KPOT_Strings2.py) [View here]\r\nNow we are almost in the same state with “kpot2_dump.bin” as we were in the original sample.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 26 of 31\n\nLet’s continue to apply our created database kpot2_DB.json to process dump kpot2_dump.bin in context of IDA.\r\nWe will use apiscout IDAPython script “ida_scout.py” for that.\r\nIn the next window choose all of the found APIs and click “Annotate”.\r\nAfter apiscout is done we can check the results – all referenced API addresses are annotated with their names and\r\ntype.\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 27 of 31\n\nNow we are in state were we have all strings decrypted, all API function calls resolved and annotated so we are\r\nready to benefit from it in analysis.\r\nThe analysis of the sample is now a simply task so for brevity, I will show only some of functions. Capabilities of\r\nthe functions are now usually self-explanatory.\r\nsub_40CB02 - is clearly \"Namecoin\" cryptocurrency stealer:\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 28 of 31\n\nsub_4101AB – ping + delete main module (kpot2.exe) always called before exit().\r\nWe can also easily rename wrapped functions when we have all API functions resolved:\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 29 of 31\n\nsub_40D5B3 - WinSCP 2 sessions information stealer.\r\nConclusion:\r\nKpot2 stealer is able to exfiltrate account information and other data from web browsers, instant messengers,\r\nemail, VPN, RDP, FTP, cryptocurrency, and gaming software.\r\nMost of them:\r\nFirefox, Internet Explorer, cryptocurrency: (Ethereum, Electrum, Namecoin, Monero) Wallets - Jaxx Liberty,\r\nExodus, TotalCommander FTP, FileZilla, WinSCP 2, Ipswitch ws_ftp, Battle.net, Steam, Skype, Telegram,\r\nDiscordapp, Pidgin, Psi, Outlook, RDP, NordVPN, EarthVPN.\r\nIt is almost impossible to cover all of stealing/exfiltrating functions here and it wasn't even my intention. I wanted\r\nto cover some tricky techniques during reversing and hope that anybody could find something from this analysis\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 30 of 31\n\nuseful or even interesting.\r\nIf you find it useful and want to share it on your blog or somewhere else, you can, just let me know if you would\r\nlike to get it in better format for sharing.\r\nThank you to everybody who was able to read it to the end.\r\nAuthor:\r\n[Twitter]\r\n[Github]\r\nDownload:\r\n[Download PDF]\r\nSource: https://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nhttps://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md\r\nPage 31 of 31",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/kpot2/KPOT.md"
	],
	"report_names": [
		"KPOT.md"
	],
	"threat_actors": [
		{
			"id": "8941e146-3e7f-4b4e-9b66-c2da052ee6df",
			"created_at": "2023-01-06T13:46:38.402513Z",
			"updated_at": "2026-04-10T02:00:02.959797Z",
			"deleted_at": null,
			"main_name": "Sandworm",
			"aliases": [
				"IRIDIUM",
				"Blue Echidna",
				"VOODOO BEAR",
				"FROZENBARENTS",
				"UAC-0113",
				"Seashell Blizzard",
				"UAC-0082",
				"APT44",
				"Quedagh",
				"TEMP.Noble",
				"IRON VIKING",
				"G0034",
				"ELECTRUM",
				"TeleBots"
			],
			"source_name": "MISPGALAXY:Sandworm",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3a0be4ff-9074-4efd-98e4-47c6a62b14ad",
			"created_at": "2022-10-25T16:07:23.590051Z",
			"updated_at": "2026-04-10T02:00:04.679488Z",
			"deleted_at": null,
			"main_name": "Energetic Bear",
			"aliases": [
				"ATK 6",
				"Blue Kraken",
				"Crouching Yeti",
				"Dragonfly",
				"Electrum",
				"Energetic Bear",
				"G0035",
				"Ghost Blizzard",
				"Group 24",
				"ITG15",
				"Iron Liberty",
				"Koala Team",
				"TG-4192"
			],
			"source_name": "ETDA:Energetic Bear",
			"tools": [
				"Backdoor.Oldrea",
				"CRASHOVERRIDE",
				"Commix",
				"CrackMapExec",
				"CrashOverride",
				"Dirsearch",
				"Dorshel",
				"Fertger",
				"Fuerboos",
				"Goodor",
				"Havex",
				"Havex RAT",
				"Hello EK",
				"Heriplor",
				"Impacket",
				"Industroyer",
				"Karagany",
				"Karagny",
				"LightsOut 2.0",
				"LightsOut EK",
				"Listrix",
				"Oldrea",
				"PEACEPIPE",
				"PHPMailer",
				"PsExec",
				"SMBTrap",
				"Subbrute",
				"Sublist3r",
				"Sysmain",
				"Trojan.Karagany",
				"WSO",
				"Webshell by Orb",
				"Win32/Industroyer",
				"Wpscan",
				"nmap",
				"sqlmap",
				"xFrost"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "a66438a8-ebf6-4397-9ad5-ed07f93330aa",
			"created_at": "2022-10-25T16:47:55.919702Z",
			"updated_at": "2026-04-10T02:00:03.618194Z",
			"deleted_at": null,
			"main_name": "IRON VIKING",
			"aliases": [
				"APT44 ",
				"ATK14 ",
				"BlackEnergy Group",
				"Blue Echidna ",
				"CTG-7263 ",
				"ELECTRUM ",
				"FROZENBARENTS ",
				"Hades/OlympicDestroyer ",
				"IRIDIUM ",
				"Qudedagh ",
				"Sandworm Team ",
				"Seashell Blizzard ",
				"TEMP.Noble ",
				"Telebots ",
				"Voodoo Bear "
			],
			"source_name": "Secureworks:IRON VIKING",
			"tools": [
				"BadRabbit",
				"BlackEnergy",
				"GCat",
				"NotPetya",
				"PSCrypt",
				"TeleBot",
				"TeleDoor",
				"xData"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "b3e954e8-8bbb-46f3-84de-d6f12dc7e1a6",
			"created_at": "2022-10-25T15:50:23.339976Z",
			"updated_at": "2026-04-10T02:00:05.27483Z",
			"deleted_at": null,
			"main_name": "Sandworm Team",
			"aliases": [
				"Sandworm Team",
				"ELECTRUM",
				"Telebots",
				"IRON VIKING",
				"BlackEnergy (Group)",
				"Quedagh",
				"Voodoo Bear",
				"IRIDIUM",
				"Seashell Blizzard",
				"FROZENBARENTS",
				"APT44"
			],
			"source_name": "MITRE:Sandworm Team",
			"tools": [
				"Bad Rabbit",
				"Mimikatz",
				"Exaramel for Linux",
				"Exaramel for Windows",
				"GreyEnergy",
				"PsExec",
				"Prestige",
				"P.A.S. Webshell",
				"AcidPour",
				"VPNFilter",
				"Neo-reGeorg",
				"Cyclops Blink",
				"SDelete",
				"Kapeka",
				"AcidRain",
				"Industroyer",
				"Industroyer2",
				"BlackEnergy",
				"Cobalt Strike",
				"NotPetya",
				"KillDisk",
				"PoshC2",
				"Impacket",
				"Invoke-PSImage",
				"Olympic Destroyer"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434119,
	"ts_updated_at": 1775792228,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/45d53cf79a35578be27e4d7d97b4d23b31392b4d.pdf",
		"text": "https://archive.orkl.eu/45d53cf79a35578be27e4d7d97b4d23b31392b4d.txt",
		"img": "https://archive.orkl.eu/45d53cf79a35578be27e4d7d97b4d23b31392b4d.jpg"
	}
}