{
	"id": "e391695a-0ab4-498b-b817-3d9eeac11123",
	"created_at": "2026-04-06T01:30:31.811898Z",
	"updated_at": "2026-04-10T03:31:17.006317Z",
	"deleted_at": null,
	"sha1_hash": "7c69d2cd21a7754304a56708ee01ce748e97bf78",
	"title": "Latrodectus: A year in the making",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 771984,
	"plain_text": "Latrodectus: A year in the making\r\nBy Fatih Cam\r\nPublished: 2024-10-21 · Archived: 2026-04-06 00:07:04 UTC\r\nVIEW VMRAY’S ANALYSIS REPORT\r\nOverview\r\nFirst identified in October 2023, Latrodectus malware has since evolved significantly, becoming a key player in the\r\ncybercriminal ecosystem. The malware works mainly as a loader/downloader. Latrodectus malware has strong ties\r\nwith the former, infamous loader IcedID, which was taken down in May 2024, thanks to the efforts of an\r\ninternational operation led by Europol and EC3. Since Operation Endgame, IcedID went under and Latrodectus is\r\nseen slowly taking its place in the cybercriminal ecosystem. Interestingly, Latrodectus also includes a specific C2\r\ncommand, which can download a sample of IcedID loader.\r\nRecently, Latrodectus malware developers released multiple new versions in quick succession, likely to stay ahead\r\nin the constant ‘cat-and-mouse’ game between defenders and attackers. As a result of this rapid iteration, these new\r\nversions primarily consist of small changes, including the removal of existing features. The previous pace of\r\ndevelopment would suggest that Latrodectus malware will keep on iterating with new versions. Due to the\r\nprevalence of the malware family, we felt that adding malware configuration extraction support for all the recent\r\nversions was the best move forward for producing high-quality IoCs for our customers.\r\nFurthermore, in this short blogpost, we would like to go over some of the most important features of the malware.\r\nFigure 1: VMRay Platform’s dynamic analysis reveals the malicious behavior of Latrodectus\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 1 of 15\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nHow Latrodectus Malware is Distributed and Continually Evolving\r\nLatrodectus malware is distributed in a chain of JavaScript → MSI droppers, finally ending in the core DLL\r\npayload. The DLL payload often has four unique-looking exports, using the same address, and eventually running\r\nthe same main logic when all four exports are tested.\r\nFigure 2: Latrodectus exhibiting 4 exports with the same export address\r\nOver time, the loader has undergone several iterations. At the time of writing, the most up-to-date version is v1.8.\r\nInitially, early versions began to surface in late September 2023. In contrast, samples of the most recent version\r\nwere compiled just by the end of September 2024.\r\n:\r\nKey technical changes in Latrodectus malware versions include:\r\nInitially the family used a PRNG seed with XOR algorithm for string decryption (v1.1a)\r\nThen Latrodectus developers decided to degrade it, and use a simpler rolling XOR method (v1.1b)\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 2 of 15\n\nStarting with version 1.4, the loader changed to AES-256 (CTR) string decryption with a fixed key and a\r\nvariable initialization value (IV) for each string\r\nAdditional command IDs introduced for the command handler in v1.4, like the possibility of downloading\r\nan arbitrary file to %APPDATA%\r\nSome features that were previously incorporated are now removed from recent versions of samples, like the\r\nADS self-deletion technique\r\nEvasion techniques\r\nIn summary, Latrodectus malware employs four distinct anti-debugging and sandbox evasion techniques, which\r\nare as follows:\r\nProcess count check\r\nFor this reason, the sanity process count check is most likely aimed at evading sandboxes. Virtualized\r\nenvironments often lack the same number of installed and running applications as a real desktop environment.\r\na the API call RtlGetVersion or via GetVersionExW, if the Rtl version does not return data. If the routine detects\r\nWindows 10 or Windows 11 as the host OS, Latrodectus malware needs at least 75 active processes to launch,\r\notherwise it simply terminates. The other condition does the same check, just for Windows versions v6.3 or less\r\n(which would constitute Windows 8.1, Windows 8, Windows 7 and anything  this case, the loader needs at least 50\r\nactive processes to launch. This is to account for baseline levels for different versions of Windows OS.\r\nThe VMRay Platform allows customers to directly specify the amount of background processes during analysis\r\ntime, successfully countering such sandbox evasion techniques.\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 3 of 15\n\nFigure 3: Latrodectus enumerating Windows OS version\r\nMAC address validity\r\nFurthermore, the second evasion check enumerates the _IP_ADAPTER_INFO structure via the GetAdaptersInfo\r\nAPI function, then all hardware addresses of present network adapters are examined against the argument of 6  the\r\nprogram will simply terminate. While MAC addresses have been standardized to 6 bytes for a long time now, some\r\nolder networking technologies used different address lengths and certain specialized or proprietary systems might\r\nuse non-standard MAC address formats. This same evasion check was present in the BumbleBee loader as well.\r\nFigure 4: A rare network card check to verify validity of MAC addresses\r\nBeingDebugged\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 4 of 15\n\nA third evasion check is simply walking the Process Environment Block (PEB) data structure to query the\r\nBeingDebugged flag to detect any debugging attempts: this is a smarter way without calling the actual Windows\r\nAPI IsDebuggerPresent(), which may trigger some AV/EDR systems.\r\nFigure 5: BeingDebugged flag being checked by walking the PEB\r\nWOW64 process check\r\nThe next check is a validation of the current process, whether it is running under WOW64 on Windows, which\r\nsimply ascertains whether the malware process is running . In this case, the malware will simply exit. Since all\r\nLatrodectus DLLs so far have been 64-bit DLLs, it is not fully clear what the intention of the threat actors was\r\nwith this condition, since it will not return 32-bit in normal circumstances. \r\nFigure 6: Checking the running process against IsWow64Process\r\nEncrypted strings\r\nHow Latrodectus Malware Encrypts Strings\r\nIn order to make reverse engineering process harder, Latrodectus malware employs string encryption. The internal\r\nstrings hold a significant amount of information on how the malware operates, what behavior it resembles. These\r\ninternal strings often serve as the base for malware configuration extraction as well. In early versions of samples,\r\nthe malware family utilized a unique pseudo random generator (PRNG) for Later, Latrodectus malware\r\ndowngraded this functionality and simply opted to use an increment-based seed variable, which in essence turned\r\nthe encryption process into a rolling XOR method. As of the most recent versions, the loader is now using AES-256 encryption with a hardcoded key inside the sample and with a variable IV for each of encrypted strings.\r\nWhile the encryption algorithm has undergone several changes, as described earlier, the storage of encrypted\r\nstrings has remained largely consistent. The prototype for these structures are simple: the encrypted strings are\r\nstored in the .data section of the DLL. In early versions of the loader, the first 4 bytes noted the XOR key and the\r\ndelimiter bytes as well, the length of each strings are stored in the 5. and 6. bytes, and the remaining bytes are the\r\nactual encrypted data.\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 5 of 15\n\nStorage of Encrypted Data Across Versions\r\nThe recent versions, due to introducing the AES algorithm, a hardcoded key is burnt-in into the .text section of the\r\nsamples. The data length still resides in the .data section in the first two bytes for each chunk, which is followed by\r\nthe IV, taking up 16 bytes. The remaining data of each chunk is again the actual encrypted data.\r\nString encryption\r\nVersions Algorithm Key\r\nData\r\nlength\r\nIV Data Seed\r\nv1.1a XOR chunk[:4] chunk[4:6]\r\nNot\r\napplicable\r\nchunk[6:6+data_length] PRNG\r\nv1.1b\r\nRolling\r\nXOR\r\nchunk[:4] chunk[4:6]\r\nNot\r\napplicable\r\nchunk[6:6+data_length] Incrementer\r\nv1.2\r\nRolling\r\nXOR\r\nchunk[:4] chunk[4:6]\r\nNot\r\napplicable\r\nchunk[6:6+data_length] Incrementer\r\nv1.3\r\nRolling\r\nXOR\r\nchunk[:4] chunk[4:6]\r\nNot\r\napplicable\r\nchunk[6:6+data_length] Incrementer\r\nv1.4\r\nAES-256\r\n(CTR\r\nmode)\r\nhardcoded chunk[:2] chunk[2:18] chunk[18:18+data_length]\r\nNot\r\napplicable\r\nv1.5\r\nAES-256\r\n(CTR\r\nmode)\r\nhardcoded chunk[:2] chunk[2:18] chunk[18:18+data_length]\r\nNot\r\napplicable\r\nv1.7\r\nAES-256\r\n(CTR\r\nmode)\r\nhardcoded chunk[:2] chunk[2:18] chunk[18:18+data_length]\r\nNot\r\napplicable\r\nv1.8\r\nAES-256\r\n(CTR\r\nmode)\r\nhardcoded chunk[:2] chunk[2:18] chunk[18:18+data_length]\r\nNot\r\napplicable\r\nFigure 7: Encryption changes across versions\r\nRuntime API resolving and API hashing\r\nThe loader again utilizes the Process Environment Block (PEB) structure to find the base addresses of kernel32.dll\r\nand ntdll.dll. Then Latrodectus continues to resolve other libraries, like user32.dll, wininet.dll, iphlpapi.dllcall the\r\nLoadLibraryW function to finally load the library.\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 6 of 15\n\nOnce Latrodectus loaded all DLLs necessary, it continues to resolve the APIs by comparing the CRC32 checksums\r\nof the exported functions with the target values. The open-source project HashDB can help and save work here, as\r\nits Lookup Service can reverse the hash values and recreate the API names within an analysis.\r\nReference: https://github.com/OALabs/hashdb\r\nFigure 8: CRC32-based API hashing in Latrodectus\r\nSetting up persistence\r\nFile Placement in %APPDATA% Folder\r\nTo ensure persistence, the malware first checks whether it is running from under the %APPDATA% folder. If it is\r\nnot, it then copies itself to one of the following locations:\r\n%APPDATA%\\Custom_update\\Update_XXXXXXXX.dll (older versions)\r\n%APPDATA%\\falsify_steward\\confrontation_XXXXXXXX.dll (newer versions)\r\nThe part of the filename noted with XXXXXXXX gets filled up with the hardware ID, generated from the\r\nsystem’s volume serial number and a hardcoded constant described in the Hardware ID section of the blogpost.\r\nLeveraging COM Interfaces for Scheduled Tasks\r\nThe creativity of developers is again revealed at the next stage of persistence: Rather than using common APIs or\r\nscheduler commands to create a scheduled task, Latrodectus uses the Component Object Model (COM) interface\r\nto stay active. . In the past, we have also taken a deep-dive into how the use of COM objects can blind malware\r\nanalysis.\r\nFirst, the sample calls the CoCreateInstance API to create and initialize an object, then connects to the\r\nITaskService object. A new task is created inside the root of the scheduler and the job is set to execute whenever\r\nthe user logs on. The name of the scheduled task is changing between “Updater” or “anxiety” between different\r\nversions of Latrodectus samples.\r\nThe task will point to the file previously dropped inside the %APPDATA% folder.\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 7 of 15\n\nFigure 9: VMRay Platform’s Function Log reveals the setup of the scheduled task via the\r\nComponent Object Model (COM) interface\r\nMutex\r\nLatrodectus also tracks previously successful infections by creating a mutex on the target system. The hardcoded\r\nstring “runnung” has been consistent across all Latrodectus versions and it is checked before execution to prevent\r\nre-infecting already corrupted systems.\r\nFigure 10: VMRay Platform’s Function log showing the hardcoded mutex “runnung”\r\nGroup ID generation\r\nEnumerating the campaign name\r\nSo far, we have seen that each new version of the loader also introduces a new group ID. We suspect this may\r\nchange in the future and there will be unique group IDs per versions, if Latrodectus decides to switch to a\r\n“Malware-as-a-Service” model.\r\nThe group IDs are present in the initial C2 check-in traffic as \u0026group= parameter and are represented as decimal\r\nnumbers. They are also present in the malware sample as a string in an encrypted form. Since, we have already\r\ndiscovered that a Fowler–Noll–Vo (FNV1a) hash is created based off of the IDs, . Our approach was to create a\r\nword-list of all possible combinations of the English alphabet (26 letters) and try and simply brute-force it. With a\r\nhigh-computing machine, it is also reasonable to try mixed lowercase and uppercase variations, but for this short\r\nexperiment, we stuck with just capitalizing the first letters.\r\nKeep in mind that – since this is FNV-1a 32-bit space – there could be multiple strings appearing under the same\r\nhash due to hash collisions. So in rare cases, there might be a slight chance that the script cannot find the original\r\ncampaign name.\r\ndef generate_words(length):\r\nalphabet ='abcdefghijklmnopqrstuvwxyz'\r\nwords = []\r\nfor   combination in itertools.product(alphabet, repeat=length -1 ):\r\nword ='' .join(combination).capitalize()\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 8 of 15\n\nwords.append(word)\r\nreturn   words\r\ndef write_words(words, file_path):\r\nwith open(file_path,'a' ) as f:\r\nfor   word in words:\r\nf.write(word +'\\n' )\r\nOnce we gave enough time to the script to generate a massive (~ 130MB) wordlist (we kept it up to 7 letters), we\r\ncan simply call a FNV1a hash generator to iterate through the given words line by line:\r\nfnv_prime_32 =2 ** 24   +2 ** 8   +0x93\r\noffset_basis_32 =0x811c9dc5\r\ndef fnv1a_hash_32(bs):\r\nr = offset_basis_32\r\nfor   b in bs:\r\nr = r ^ b\r\nr = (r * fnv_prime_32) \u00260xffffffff\r\nreturn   r\r\nif   __name__ =='__main__' :\r\nwith open( 'wordlist.txt' ,'rb' ) as file:\r\nwordlist = file.readlines()\r\nfor   words in wordlist:\r\nprint( \"Campaign: \"   + Fore.YELLOW, wordbytes.decode( 'ascii' ), \"| FNV1a: \" ,\r\nhex(fnv1a_hash_32(wordbytes)), \"| Dec: \" , int (hex(fnv1a_hash_32(wordbytes)),16 ))\r\nFigure 11: Successfully brute-forcing the campaign name based on the decimal value of the\r\ncampaign ID\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 9 of 15\n\nHardware ID generation\r\nThe loader also generates a unique hardware ID for each target host. This ID is based off of the victim’s Serial\r\nVolume ID and simply multiplied with a hardcoded constant. This constant is consistent so far in all observed\r\nLatrodectus versions: 0x19660D. The generated GUID is present in the initial C2 check-in request as \u0026guid=\r\nparameter.\r\nFigure 12: Generating the hardware ID, using the Volume Serial Number and the hardcoded constant\r\n(0x19660Dh)\r\nSelf-deletion\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 10 of 15\n\nThe loader uses a rather fascinating self-deletion technique: besides Latrodectus, we have previously observed this\r\ntechnique in both DarkSide, Dark Power, HelloXD and other malware families. Ultimately, this method can delete\r\na locked, or a currently running executable from disk. It uses the SetFileInformationByHandle Windows API to\r\nrename the executable’s primary data stream and then facilitates the DeleteFile flag in the FileDispositionInfo class\r\nto trigger the disposition. There is a publicly available proof-of-concept code for this method on\r\nGitHub: https://github.com/LloydLabs/delete-self-poc\r\nWe have – uniquely in the industry – tried creating a future-proof detection coverage specifically for this\r\ntechnique, which is now observable as a VMRay Threat Identifier (VTI).\r\nFigure 13: The VMRay Platform triggering on ADS self-deletion technique via VTIs\r\nNetwork C2\r\nUpon successful infection, Latrodectus sends an initial check-in POST request with a hardcoded User-Agent\r\nstring: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tob 1.1). This User-Agent header is consistent across\r\nall Latrodectus versions so far.\r\nFigure 14: VMRay Platform’s network capture displays POST requests to the C2 server\r\nThe POST request data includes parameter values collected from the system and also consists of a few hardcoded\r\nvalues, stored in the sample that identifies the campaign and the sample version. These parameters are originally\r\nsent towards the C2 server RC4 encrypted and then base64 encoded, but the VMRay Platform easily captures the\r\ndecrypted values in the function logs.\r\nFigure 15: VMRay Platform’s Function Log revealing the parameters being filled with values\r\nEach of these parameters serve a specific purpose:\r\nC2 command handler\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 11 of 15\n\nOnce an infection took place, the malicious process can receive further commands from the C2 server, 4 different\r\ncommands are available:\r\nThe COMMAND handler is the most interesting one as it can receive the following further sub-commands from\r\nthe C2:\r\nFigure 16: Command handler IDs for more functionalities\r\nYARA coverage\r\nWe have introduced several forward-looking YARA signatures to detect all versions of the family. We also provide\r\nversion-based signatures to aid customers with up-to-date information on the exact version of Latrodectus in\r\nquestion.\r\nFigure 17: VMRay Platform’s report showing YARA detection signatures on Latrodectus samples\r\nMalware configuration extraction\r\nThe VMRay Platform currently extracts all important malware configuration information from the samples. These\r\nwould include the C2 URLs, the exact version, mission ID, and any potential encryption keys that are used for the\r\nstring encryption or C2 communication: namely the RC4 key and the AES key (from v1.4 up to v1.8).\r\nFigure 18: VMRay Platform’s successful malware configuration extraction for Latrodectus v1.8\r\nConclusion\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 12 of 15\n\nWith its consistent updates and strategic adaptations, Latrodectus malware continues to challenge security\r\nmeasures worldwide.\r\nThe threat actors behind the malware family seem to iterate versions in a speedy fashion, perhaps to wear\r\ndefenders out or potentially to prepare for a substantial major change. Looking ahead, we suspect the prevalent\r\nloader will enter version 2.0 soon. Given the previous pace of development, it seems likely that even more updates\r\nare on the horizon. We noticed that some subversions even removed features from the loader, likely to reorganize\r\nits internal design. As this threat is still prevalent today, we will make sure to follow-up on future changes to aid\r\ncustomers with proper detection coverage and precise malware configuration extraction.\r\nLatrodectus malware exemplifies the ever-evolving threats in the digital landscape. Stay updated on its latest\r\ndevelopments by exploring our full malware analysis and detection capabilities: try VMRay Platform to detect all\r\nLatrodectus versions up to v1.8 and can acquire malware configuration from all working samples!\r\nReferences\r\nhttps://malpedia.caad.fkie.fraunhofer.de/details/win.lactrodectus\r\nhttps://bazaar.abuse.ch/browse/signature/latrodectus/\r\nhttps://bazaar.abuse.ch/browse/tag/latrodectus/\r\nhttps://github.com/OALabs/hashdb\r\nhttps://www.proofpoint.com/us/blog/threat-insight/latrodectus-spider-bytes-ice\r\nhttps://www.elastic.co/security-labs/spring-cleaning-with-latrodectus\r\nhttps://www.europol.europa.eu/media-press/newsroom/news/largest-ever-operation-against-botnets-hits-dropper-malware-ecosystem\r\nIoCs\r\nC2 URLs hxxps://antyparkov[.]site/live/\r\nhxxps://aytobusesre[.]com/live/\r\nhxxps://carflotyup[.]com/live/\r\nhxxps://drifajizo[.]fun/live/\r\nhxxps://coolarition[.]com/live/\r\nhxxps://finjuiceer[.]com/live/\r\nhxxps://grebiunti[.]top/live/\r\nhxxps://grunzalom[.]fun/live/\r\nhxxps://illoskanawer[.]com/live/\r\nhxxps://jertacco[.]com/live/\r\nhxxps://saicetyapy[.]space/live/\r\nhxxps://scifimond[.]com/live/\r\nhxxps://skinnyjeanso[.]com/live/\r\nhxxps://stratimasesstr[.]com/live/\r\nhxxps://stripplasst[.]com/live/\r\nhxxps://titnovacrion[.]top/live/\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 13 of 15\n\nhxxps://trymeakafr[.]com/live/\r\nhxxps://winarkamaps[.]com/live/\r\nhxxps://workspacin[.]cloud/live/\r\nhxxps://worlpquano[.]com/live/\r\nhxxps://zumkoshapsret[.]com/live/\r\nhxxps://minrezviko[.]com/test/\r\nhxxps://pomaspoteraka[.]com/test/\r\nhxxps://finilamedima[.]com/test/\r\nhxxps://restoreviner[.]com/test/\r\nhxxps://peronikilinfer[.]com/test/\r\nhxxps://rilomenifis[.]com/test/\r\nhxxps://isomicrotich[.]com/test/\r\nMutex runnung\r\nScheduled task\r\nname\r\nUpdater\r\nanxiety\r\nPersistence\r\nlocation\r\n%APPDATA%\\falsify_steward\\confrontation_XXXXXXXX.dll\r\n%APPDATA%\\Custom_update\\Update_XXXXXXXX.dll\r\nRC4 keys\r\n12345\r\n2sDbsEUXvhgLOO4Irt8AF6el3jJ0M1MowXyao00Nn6ZUjtjXwb\r\nu9X7Ogp3IECwtHNBFGa0uMc0fDXhjVnV9SiAiVzqdkoleTZy16\r\neNIHaXC815vAqddR21qsuD35eJFL7CnSOLI9vUBdcb5RPcS0h6\r\nEhAyPSHvva9CvL6OIddDJvDXHJjoMsqXyjraKyYmXFqDGdAYyO\r\n9edoY7pK6eQfntcLBNU1WSkauwf1sHj4I8vTuAddXvPwYbJPeP\r\nv9JrWM4aDsviWsTfSCgX5Ed98pH6kMpQr1VWWj5LTMiC5C5Lna\r\nk2C0I3yY0ZDMCy4zFZDFnCD3mzc4fFdEMw5uF1n6u59eGG2NDN\r\nxkxp7pKhnkQxUokR2dl00qsRa6Hx0xvQ31jTD7EwUqj4RXWtHwELbZFbOoqCnXl8\r\nGroup/Campaign\r\nIDs\r\nAlpha (v1.8)\r\nAlpha (v1.7)\r\nCeres\r\nCompati\r\nDelta (v1.5)\r\nElectrol\r\nFacial\r\nJupiter\r\nLiniska\r\nLittlehw\r\nMars\r\nMercury\r\nNeptun\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 14 of 15\n\nNovik\r\nOlimp\r\nSupted\r\nTrusted\r\nVenus\r\nWiski (v1.4)\r\nVersions\r\nv1.1a\r\nv1.1b\r\nv1.2\r\nv1.3\r\nv1.4\r\nv1.5\r\nv1.7\r\nv1.8\r\nSource: https://www.vmray.com/latrodectus-a-year-in-the-making/\r\nhttps://www.vmray.com/latrodectus-a-year-in-the-making/\r\nPage 15 of 15\n\nThe VMRay would include Platform currently the C2 URLs, the extracts all important exact version, malware configuration mission ID, and any information potential encryption from the samples. keys that are These used for the\nstring encryption or C2 communication: namely the RC4 key and the AES key (from v1.4 up to v1.8).\nFigure 18: VMRay Platform’s successful malware configuration extraction for Latrodectus v1.8\nConclusion     \n   Page 12 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.vmray.com/latrodectus-a-year-in-the-making/"
	],
	"report_names": [
		"latrodectus-a-year-in-the-making"
	],
	"threat_actors": [
		{
			"id": "156b3bc5-14b7-48e1-b19d-23aa17492621",
			"created_at": "2025-08-07T02:03:24.793494Z",
			"updated_at": "2026-04-10T02:00:03.634641Z",
			"deleted_at": null,
			"main_name": "COBALT ULSTER",
			"aliases": [
				"Boggy Serpens ",
				"ENT-11 ",
				"Earth Vetala ",
				"ITG17 ",
				"MERCURY ",
				"Mango Sandstorm ",
				"MuddyWater ",
				"STAC 1171 ",
				"Seedworm ",
				"Static Kitten ",
				"TA450 ",
				"TEMP.Zagros ",
				"UNC3313 ",
				"Yellow Nix "
			],
			"source_name": "Secureworks:COBALT ULSTER",
			"tools": [
				"CrackMapExec",
				"Empire",
				"FORELORD",
				"Koadic",
				"LaZagne",
				"Metasploit",
				"Mimikatz",
				"Plink",
				"PowerStats"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775439031,
	"ts_updated_at": 1775791877,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7c69d2cd21a7754304a56708ee01ce748e97bf78.pdf",
		"text": "https://archive.orkl.eu/7c69d2cd21a7754304a56708ee01ce748e97bf78.txt",
		"img": "https://archive.orkl.eu/7c69d2cd21a7754304a56708ee01ce748e97bf78.jpg"
	}
}