{
	"id": "bc12ebf9-4e00-40a0-90a6-aaa372804a55",
	"created_at": "2026-04-06T00:06:44.033494Z",
	"updated_at": "2026-04-10T03:36:13.689877Z",
	"deleted_at": null,
	"sha1_hash": "7b809e9703d64b08d9f13fea0f9e4ab16167f8e0",
	"title": "Anatomy of Cobalt Strike’s DLL Stager",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 699153,
	"plain_text": "Anatomy of Cobalt Strike’s DLL Stager\r\nBy Maxime Thiebaut\r\nPublished: 2021-04-26 · Archived: 2026-04-05 18:37:20 UTC\r\nNVISO recently monitored a targeted campaign against one of its customers in the financial sector. The attempt\r\nwas spotted at its earliest stage following an employee’s report concerning a suspicious email. While no harm was\r\ndone, we commonly identify any related indicators to ensure additional monitoring of the actor.\r\nThe reported email was an application for one of the company’s public job offers and attempted to deliver a\r\nmalicious document. What caught our attention, besides leveraging an actual job offer, was the presence of\r\nexecution-guardrails in the malicious document. Analysis of the document uncovered the intention to persist a\r\nCobalt Strike stager through Component Object Model Hijacking.\r\nDuring my free time I enjoy analyzing samples NVISO spots in-the-wild, and hence further dissected the Cobalt\r\nStrike DLL payload. This blog post will cover the payload’s anatomy, design choices and highlight ways to reduce\r\nboth log footprint and time-to-shellcode.\r\nExecution Flow Analysis\r\nTo understand how the malicious code works we have to analyze its behavior from start to end. In this section, we\r\nwill cover the following flows:\r\n1. The initial execution through DllMain .\r\n2. The sending of encrypted shellcode into a named pipe by WriteBufferToPipe .\r\n3. The pipe reading, shellcode decryption and execution through PipeDecryptExec .\r\nAs previously mentioned, the malicious document’s DLL payload was intended to be used as a COM in-process\r\nserver. With this knowledge, we can already expect some known entry points to be exposed by the DLL.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 1 of 21\n\nList of available entry points as displayed in IDA.\r\nWhile technically the malicious execution can occur in any of the 8 functions, malicious code commonly resides\r\nin the DllMain function given, besides TLS callbacks, it is the function most likely to execute.\r\nDllMain : An optional entry point into a dynamic-link library (DLL). When the system starts or\r\nterminates a process or thread, it calls the entry-point function for each loaded DLL using the first\r\nthread of the process. The system also calls the entry-point function for a DLL when it is loaded or\r\nunloaded using the LoadLibrary and FreeLibrary functions.\r\ndocs.microsoft.com/en-us/windows/win32/dlls/dllmain\r\nThroughout the following analysis functions and variables have been renamed to reflect their usage and improve\r\nclarity.\r\nThe DllMain Entry Point\r\nAs can be seen in the following capture, the DllMain function simply executes another function by creating a\r\nnew thread. This threaded function we named DllMainThread is executed without any additional arguments\r\nbeing provided to it.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 2 of 21\n\nGraphed disassembly of DllMain .\r\nAnalyzing the DllMainThread function uncovers it is an additional wrapper towards what we will discover is the\r\nmalicious payload’s decryption and execution function (called DecryptBufferAndExec in the capture).\r\nDisassembly of DllMainThread .\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 3 of 21\n\nBy going one level deeper, we can see the start of the malicious logic. Analysts experienced with Cobalt Strike\r\nwill recognize the well-known MSSE-%d-server pattern.\r\nDisassembly of DecryptBufferAndExec .\r\nA couple of things occur in the above code:\r\n1. The sample starts by retrieving the tick count through GetTickCount and then divides it by 0x26AA .\r\nWhile obtaining a tick count is often a time measurement, the next operation solely uses the divided tick as\r\na random number.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 4 of 21\n\n2. The sample then proceeds to call a wrapper around an implementation of the sprintf function. Its role is\r\nto format a string into the PipeName buffer. As can be observed, the formatted string will be\r\n\\\\.\\pipe\\MSSE-%d-server where %d will be the result computed in the previous division (e.g.:\r\n\\\\.\\pipe\\MSSE-1234-server ). This pipe’s format is a well-documented Cobalt Strike indicator of\r\ncompromise.\r\n3. With the pipe’s name defined in a global variable, the malicious code creates a new thread to run\r\nWriteBufferToPipeThread . This function will be the next one we will analyze.\r\n4. Finally, while the new thread is running, the code jumps to the PipeDecryptExec routine.\r\nSo far, we had a linear execution from our DllMain entry point until the DecryptBufferAndExec function. We\r\ncould graph the flow as follows:\r\nExecution flow from DllMain until DecryptBufferAndExec .\r\nAs we can see, two threads are now going to run concurrently. Let’s focus ourselves on the one writing into the\r\npipe ( WriteBufferToPipeThread ) followed by its reading counterpart ( PipeDecryptExec ) afterwards.\r\nThe WriteBufferToPipe Thread\r\nThe thread writing into the generated pipe is launched from DecryptBufferAndExec without any additional\r\narguments. By entering into the WriteBufferToPipeThread function, we can observe it is a simple wrapper to\r\nWriteBufferToPipe except it furthermore passes the following arguments recovered from a global Payload\r\nvariable (pointed to by the pPayload pointer):\r\n1. The size of the shellcode, stored at offset 0x4 .\r\n2. A pointer to a buffer containing the encrypted shellcode, stored at offset 0x14 .\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 5 of 21\n\nDisassembly of WriteBufferToPipeThread .\r\nWithin the WriteBufferToPipe function we can notice the code starts by creating a new pipe. The pipe’s name is\r\nrecovered from the PipeName global variable which, if you remember, was previously populated by the\r\nsprintf function. The code creates a single instance, outbound pipe ( PIPE_ACCESS_OUTBOUND ) by calling\r\nCreateNamedPipeA and then connects to it using the ConnectNamedPipe call.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 6 of 21\n\nGraphed disassembly of WriteBufferToPipe ‘s named pipe creation.\r\nIf the connection was successful, the WriteBufferToPipe function proceeds to loop the WriteFile call as long\r\nas there are bytes of the shellcode to be written into the pipe.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 7 of 21\n\nGraphed disassembly of WriteBufferToPipe writing to the pipe.\r\nOne important detail worth noting is that once the shellcode is written into the pipe, the previously opened handle\r\nto the pipe is closed through CloseHandle . This indicates that the pipe’s sole purpose was to transfer the\r\nencrypted shellcode.\r\nOnce the WriteBufferToPipe function is completed, the thread terminates. Overall the execution flow was quite\r\nsimple and can be graphed as follows:\r\nExecution flow from WriteBufferToPipe .\r\nThe PipeDecryptExec Flow\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 8 of 21\n\nAs a quick refresher, the PipeDecryptExec flow was executed immediately after the creation of the\r\nWriteBufferToPipe thread. The first task performed by PipeDecryptExec is to allocate a memory region to\r\nreceive shellcode to be transmitted through the named pipe. To do so, a call to malloc is performed with as\r\nargument the shellcode size stored at offset 0x4 of the global Payload variable.\r\nOnce the buffer allocation is completed, the code sleeps for 1024 milliseconds ( 0x400 ) and calls\r\nFillBufferFromPipe with both buffer location and buffer size as argument. Should the FillBufferFromPipe\r\ncall fail by returning FALSE ( 0 ), the code loops again to the Sleep call and attempts the operation again until\r\nit succeeds. These Sleep calls and loops are required as the multi-threaded sample has to wait for the shellcode\r\nbeing written into the pipe.\r\nOnce the shellcode is written to the allocated buffer, PipeDecryptExec will finally launch the decryption and\r\nexecution through XorDecodeAndCreateThread .\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 9 of 21\n\nGraphed disassembly of PipeDecryptExec .\r\nTo transfer the encrypted shellcode from the pipe into the allocated buffer, FillBufferFromPipe opens the pipe\r\nin read-only mode ( GENERIC_READ ) using CreateFileA . As was done for the pipe’s creation, the name is\r\nretrieved from the global PipeName variable. If accessing the pipe fails, the function proceeds to return FALSE\r\n( 0 ), resulting in the above described Sleep and retry loop.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 10 of 21\n\nDisassembly of FillBufferFromPipe ‘s pipe access.\r\nOnce the pipe opened in read-only mode, the FillBufferFromPipe function proceeds to copy over the shellcode\r\nuntil the allocated buffer is filled using ReadFile . Once the buffer filled, the handle to the named pipe is closed\r\nthrough CloseHandle and FillBufferFromPipe returns TRUE ( 1 ).\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 11 of 21\n\nGraphed disassembly of FillBufferFromPipe copying data.\r\nOnce FillBufferFromPipe has successfully completed, the named pipe has completed its task and the encrypted\r\nshellcode has been moved from one memory region to another.\r\nBack in the caller PipeDecryptExec function, once the FillBufferFromPipe call returns TRUE the\r\nXorDecodeAndCreateThread function gets called with the following parameters:\r\n1. The buffer containing the copied shellcode.\r\n2. The length of the shellcode, stored at the global Payload variable’s offset 0x4 .\r\n3. The symmetric XOR decryption key, stored at the global Payload variable’s offset 0x8 .\r\nOnce invoked, the XorDecodeAndCreateThread function starts by allocating yet another memory region using\r\nVirtualAlloc . The allocated region has read/write permissions ( PAGE_READWRITE ) but is not executable. By not\r\nmaking a region writable and executable at the same time, the sample possibly attempts to evade security\r\nsolutions which only look for PAGE_EXECUTE_READWRITE regions.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 12 of 21\n\nOnce the region is allocated, the function loops over the shellcode buffer and decrypts each byte using a simple\r\nxor operation into the newly allocated region.\r\nGraphed disassembly of XorDecodeAndCreateThread .\r\nWhen the decryption is complete, the GetModuleHandleAndGetProcAddressToArg function is called. Its role is to\r\nplace pointers to two valuable functions into memory: GetModuleHandleA and GetProcAddress . These functions\r\nshould enable the shellcode to further resolve additional procedures without relying on them being imported.\r\nBefore storing these pointers, the GetModuleHandleAndGetProcAddressToArg function first ensures a specific\r\nvalue is not FALSE ( 0 ). Surprisingly enough, this value stored in a global variable (here called zero ) is\r\nalways FALSE , resulting in the pointers never being stored.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 13 of 21\n\nGraphed disassembly of GetModuleHandleAndGetProcAddressToArg .\r\nBack in the caller function, XorDecodeAndCreateThread changes the shellcode’s memory region to be executable\r\n( PAGE_EXECUTE_READ ) using VirtualProtect and finally creates a new thread. This final thread starts at the\r\nJumpToParameter function which acts as a simple wrapper to the shellcode, provided as argument.\r\nDisassembly of JumpToParameter .\r\nFrom here, the previously encrypted Cobalt Strike shellcode stager executes to resolve WinINet procedures,\r\ndownload the final beacon and execute it. We will not cover the shellcode’s analysis in this post as it would\r\ndeserve a post of its own.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 14 of 21\n\nWhile this last flow contained more branches and logic, the overall graph remains quite simple:\r\nExecution flow from PipeDecryptExec until the shellcode.\r\nMemory Flow Analysis\r\nWhat was the most surprising throughout the above analysis was the presence of a well-known named pipe. Pipes\r\ncan be used as a defense evasion mechanism by decrypting the shellcode at pipe exit or for inter-process\r\ncommunications; but in our case it merely acted as a memcpy to move encrypted shellcode from the DLL into\r\nanother buffer.\r\nMemory flow from encrypted shellcode until decryption.\r\nSo why would this overhead be implemented? As pointed out by another colleague, the answer lays in the Artifact\r\nKit, a Cobalt Strike dependency:\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 15 of 21\n\nCobalt Strike uses the Artifact Kit to generate its executables and DLLs. The Artifact Kit is a source\r\ncode framework to build executables and DLLs that evade some anti-virus products. […] One of the\r\ntechniques [see: src-common/bypass-pipe.c in the Artifact Kit] generates executables and DLLs that\r\nserve shellcode to themselves over a named pipe. If an anti-virus sandbox does not emulate named\r\npipes, it will not find the known bad shellcode.\r\ncobaltstrike.com/help-artifact-kit\r\nAs we can see in the above diagram, the staging of the encrypted shellcode in the malloc buffer generates a lot\r\nof overhead supposedly for evasion. These operations could be avoided should XorDecodeAndCreateThread\r\ninstead directly read from the initial encrypted shellcode as outlined in the next diagram. Avoiding the usage of\r\nnamed pipes will furthermore remove the need for looped Sleep calls as the data would be readily available.\r\nImproved memory flow from encrypted shellcode until decryption.\r\nIt seems we found a way to reduce the time-to-shellcode; but do popular anti-virus solutions actually get tricked\r\nby the named pipe?\r\nPatching the Execution Flow\r\nTo test that theory, let’s improve the malicious execution flow. For starters we could skip the useless pipe-related\r\ncalls and have the DllMainThread function call PipeDecryptExec directly, bypassing pipe creation and writing.\r\nHow the assembly-level patching is performed is beyond this blog post’s scope as we are just interested in the\r\nflow’s abstraction.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 16 of 21\n\nDisassembly of the patched DllMainThread .\r\nThe PipeDecryptExec function will also require patching to skip malloc allocation, pipe reading and ensure it\r\nprovides XorDecodeAndCreateThread with the DLL’s encrypted shellcode instead of the now-nonexistent\r\nduplicated region.\r\nDisassembly of the patched PipeDecryptExec .\r\nWith our execution flow patched, we can furthermore zero-out any unused instructions should these be used by\r\nsecurity solutions as a detection base.\r\nWhen the patches are applied, we end up with a linear and shorter path until shellcode execution. The following\r\ngraph focuses on this patched path and does not include the leaves beneath WriteBufferToPipeThread.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 17 of 21\n\nOutline of the patched (red) execution flow and functions.\r\nAs we also figured out how the shellcode is encrypted (we have the xor key), we modified both samples to\r\nredact the actual C2 as it can be used to identify our targeted customer.\r\nTo ensure the shellcode did not rely on any bypassed calls, we spun up a quick Python HTTPS server and made\r\nsure the redacted domain resolved to 127.0.0.1 . We then can invoke both the original and patched DLL through\r\nrundll32.exe and observe how the shellcode still attempts to retrieve the Cobalt Strike beacon, proving our\r\npatches did not affect the shellcode. The exported StartW function we invoke is a simple wrapper around the\r\nSleep call.\r\nCapture of both the original and patched DLL attempting to fetch the Cobalt Strike beacon.\r\nAnti-Virus Review\r\nSo do named pipes actually work as a defense evasion mechanism? While there are efficient ways to measure our\r\npatches’ impact (e.g.: comparing across multiple sandbox solutions), VirusTotal does offer a quick primary\r\nassessment. As such, we submitted the following versions with redacted C2 to VirusTotal:\r\nwpdshext.dll.custom.vir which is the redacted Cobalt Strike DLL.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 18 of 21\n\nwpdshext.dll.custom.patched.vir which is our patched and redacted Cobalt Strike DLL without named\r\npipes.\r\nAs the original Cobalt Strike contains identifiable patterns (the named pipe), we would expect the patched version\r\nto have a lower detection ratio, although the Artifact Kit would disagree.\r\nAs we expected, the named-pipe overhead leveraged by Cobalt Strike actually turned out to act as a detection\r\nbase. As can be seen in the above captures, while the original version (left) obtained only 17 detections, the\r\npatched version (right) obtained one less for a total of 16 detections. Among the thrown-off solutions we noticed\r\nESET and Sophos did not manage to detect the pipe-less version, whereas ZoneAlarm couldn’t identify the\r\noriginal version.\r\nOne notable observation is that an intermediary patch where the flow is adapted but unused code is not zeroed-out\r\nturned out to be the most detected version with a total of 20 hits. This higher detection rate occurs as this patch\r\nallows pipe-unaware anti-virus vendors to also locate the shellcode while pipe-related operation signatures are still\r\napplicable.\r\nCapture of the intermediary patched Cobalt Strike’s detection ratio on VirusTotal.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 19 of 21\n\nWhile these tests focused on the default Cobalt Strike behavior against the absence of named pipes, one might\r\nargue that a customized named pipe pattern would have had the best results. Although we did not think of this\r\nvariant during the initial tests, we submitted a version with altered pipe names ( NVISO-RULES-%d instead of\r\nMSSE-%d-server ) the day after and obtained 18 detections. As a comparison, our two other samples had their\r\ndetection rate increase to 30+ over night. We however have to consider the possibility that these 18 detections are\r\ninfluenced by the initial shellcode being burned.\r\nConclusion\r\nReversing the malicious Cobalt Strike DLL turned out to be more interesting than expected. Overall, we noticed\r\nthe presence of noisy operations whose usage weren’t a functional requirement and even turn out to act as a\r\ndetection base. To confirm our hypothesis, we patched the execution flow and observed how our simplified\r\nversion still reaches out to the C2 server with a lowered (almost unaltered) detection rate.\r\nSo why does it matter?\r\nThe Blue\r\nFirst and foremost, this payload analysis highlights a common Cobalt Strike DLL pattern allowing us to further\r\nfine-tune detection rules. While this stager was the first DLL analyzed, we did take a look at other Cobalt Strike\r\nformats such as default beacons and those leveraging a malleable C2, both as Dynamic Link Libraries and\r\nPortable Executables. Surprisingly enough, all formats shared this commonly documented MSSE-%d-server pipe\r\nname and a quick search for open-source detection rules showed how little it is being hunted for.\r\nThe Red\r\nBesides being helpful for NVISO’s defensive operations, this research further comforts our offensive team in their\r\nchoice of leveraging custom-built delivery mechanisms; even more so following the design choices we\r\ndocumented. The usage of named pipes in operations targeting mature environments is more likely to raise red\r\nflags and so far does not seem to provide any evasive advantage without alteration in the generation pattern at\r\nleast.\r\nTo the next actor targeting our customers: I am looking forward to modifying your samples and test the\r\neffectiveness of altered pipe names.\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 20 of 21\n\nMaxime Thiebaut\r\nMaxime Thiebaut is a GCFA-certified intrusion analyst in NVISO’s Managed Detection \u0026 Response team. He\r\nspends most of his time investigating incidents and improving detection capabilities. Previously, Maxime worked\r\non the SANS SEC699 course. Besides his coding capabilities, Maxime enjoys reverse engineering samples\r\nobserved in the wild.\r\nSource: https://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nhttps://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.nviso.eu/2021/04/26/anatomy-of-cobalt-strike-dll-stagers/"
	],
	"report_names": [
		"anatomy-of-cobalt-strike-dll-stagers"
	],
	"threat_actors": [
		{
			"id": "610a7295-3139-4f34-8cec-b3da40add480",
			"created_at": "2023-01-06T13:46:38.608142Z",
			"updated_at": "2026-04-10T02:00:03.03764Z",
			"deleted_at": null,
			"main_name": "Cobalt",
			"aliases": [
				"Cobalt Group",
				"Cobalt Gang",
				"GOLD KINGSWOOD",
				"COBALT SPIDER",
				"G0080",
				"Mule Libra"
			],
			"source_name": "MISPGALAXY:Cobalt",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "f8dddd06-da24-4184-9e24-4c22bdd1cbbf",
			"created_at": "2023-01-06T13:46:38.626906Z",
			"updated_at": "2026-04-10T02:00:03.043681Z",
			"deleted_at": null,
			"main_name": "Tick",
			"aliases": [
				"G0060",
				"Stalker Taurus",
				"PLA Unit 61419",
				"Swirl Typhoon",
				"Nian",
				"BRONZE BUTLER",
				"REDBALDKNIGHT",
				"STALKER PANDA"
			],
			"source_name": "MISPGALAXY:Tick",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "54e55585-1025-49d2-9de8-90fc7a631f45",
			"created_at": "2025-08-07T02:03:24.563488Z",
			"updated_at": "2026-04-10T02:00:03.715427Z",
			"deleted_at": null,
			"main_name": "BRONZE BUTLER",
			"aliases": [
				"CTG-2006 ",
				"Daserf",
				"Stalker Panda ",
				"Swirl Typhoon ",
				"Tick "
			],
			"source_name": "Secureworks:BRONZE BUTLER",
			"tools": [
				"ABK",
				"BBK",
				"Casper",
				"DGet",
				"Daserf",
				"Datper",
				"Ghostdown",
				"Gofarer",
				"MSGet",
				"Mimikatz",
				"Netboy",
				"RarStar",
				"Screen Capture Tool",
				"ShadowPad",
				"ShadowPy",
				"T-SMB",
				"down_new",
				"gsecdump"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "d4e7cd9a-2290-4f89-a645-85b9a46d004b",
			"created_at": "2022-10-25T16:07:23.419513Z",
			"updated_at": "2026-04-10T02:00:04.591062Z",
			"deleted_at": null,
			"main_name": "Bronze Butler",
			"aliases": [
				"Bronze Butler",
				"CTG-2006",
				"G0060",
				"Operation ENDTRADE",
				"RedBaldNight",
				"Stalker Panda",
				"Stalker Taurus",
				"Swirl Typhoon",
				"TEMP.Tick",
				"Tick"
			],
			"source_name": "ETDA:Bronze Butler",
			"tools": [
				"8.t Dropper",
				"8.t RTF exploit builder",
				"8t_dropper",
				"9002 RAT",
				"AngryRebel",
				"Blogspot",
				"Daserf",
				"Datper",
				"Elirks",
				"Farfli",
				"Gh0st RAT",
				"Ghost RAT",
				"HOMEUNIX",
				"HidraQ",
				"HomamDownloader",
				"Homux",
				"Hydraq",
				"Lilith",
				"Lilith RAT",
				"McRAT",
				"MdmBot",
				"Mimikatz",
				"Minzen",
				"Moudour",
				"Muirim",
				"Mydoor",
				"Nioupale",
				"PCRat",
				"POISONPLUG.SHADOW",
				"Roarur",
				"RoyalRoad",
				"ShadowPad Winnti",
				"ShadowWali",
				"ShadowWalker",
				"SymonLoader",
				"WCE",
				"Wali",
				"Windows Credential Editor",
				"Windows Credentials Editor",
				"XShellGhost",
				"XXMM",
				"gsecdump",
				"rarstar"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434004,
	"ts_updated_at": 1775792173,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7b809e9703d64b08d9f13fea0f9e4ab16167f8e0.pdf",
		"text": "https://archive.orkl.eu/7b809e9703d64b08d9f13fea0f9e4ab16167f8e0.txt",
		"img": "https://archive.orkl.eu/7b809e9703d64b08d9f13fea0f9e4ab16167f8e0.jpg"
	}
}