{
	"id": "25c41600-39d5-4114-a3f0-9890c04f475e",
	"created_at": "2026-04-06T00:11:57.681003Z",
	"updated_at": "2026-04-10T13:12:06.266562Z",
	"deleted_at": null,
	"sha1_hash": "b86bc64e0d8ea568d722e602600f3370ecd4800c",
	"title": "Operation CuckooBees: A Winnti Malware Arsenal Deep-Dive",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2736031,
	"plain_text": "Operation CuckooBees: A Winnti Malware Arsenal Deep-Dive\r\nBy Cybereason Nocturnus\r\nArchived: 2026-04-05 20:22:48 UTC\r\nIn part one of this research, the Cybereason Nocturnus Incident Response Team provided a unique glimpse into\r\nthe Winnti intrusion playbook, covering the techniques that were used by the group from initial compromise to\r\nstealing the data, as observed and analyzed by the Cybereason Incident Response team. \r\nThis part of the research zeroes in on the Winnti malware arsenal that was discovered during the investigation\r\nconducted by the Cybereason IR and Nocturnus teams. In addition, our analysis of the observed malware provides\r\na deeper understanding of the elaborate and multi-layered Winnti infection chain, including evasive maneuvers\r\nand stealth techniques that are baked-in to the malware code, as well as the functionality of the various malware. \r\nPerhaps one of the most interesting and striking aspects of this report is the level of sophistication introduced by\r\nthe malware authors. The infection and deployment chain is long, complicated and interdependent–should one\r\nstep go wrong, the entire chain collapses - making it somewhat vulnerable, yet at the same time provides an extra\r\nlevel of security and stealth for the operation. \r\nThese steps have proven themselves effective time and time again, as the operation remained under-the-radar for\r\nyears. While there have been past reports describing some aspects of these intrusions, at the time of writing this\r\nreport there was no publicly available research that discussed all of the tools and techniques and the manner in\r\nwhich they all fit together, as mentioned in this report. \r\nKey Findings\r\nAttribution to the Winnti APT Group: based on the analysis of the forensic artifacts, Cybereason\r\nestimates with medium-high confidence that the perpetrators of the attack are linked to the notorious\r\nWinnti APT group, a group that has existed since at least 2010 and is believed to be operating on behalf of\r\nChinese state interests and specializes in cyberespionage and intellectual property theft. \r\nDiscovery of New Malware in the Winnti Arsenal: the report exposes previously undocumented\r\nmalware strain called DEPLOYLOG used by the Winnti APT group and highlights new versions of known\r\nWinnti malware, including Spyder Loader, PRIVATELOG, and WINNKIT. \r\nRarely Seen Abuse of the Windows CLFS Feature: the attackers leveraged the Windows CLFS\r\nmechanism and NTFS transaction manipulations which provided them with the ability to conceal their\r\npayloads and evade detection by traditional security products.\r\nIntricate and Interdependent Payload Delivery: the report includes an analysis of the complex infection\r\nchain that led to the deployment of the WINNKIT rootkit composed of multiple interdependent\r\ncomponents. The attackers implemented a delicate “house of cards” approach, meaning that each\r\ncomponent depends on the others to function properly, making it very difficult to analyze each component\r\nseparately. The malware from the Winnti arsenal that are analyzed in this report include: \r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 1 of 43\n\nSpyder: A sophisticated modular backdoor\r\nSTASHLOG: The initial deployment tool “stashing” payloads in Windows CLFS \r\nSPARKLOG: Extracts and deploys PRIVATELOG to gain privilege escalation and achieve\r\npersistence\r\nPRIVATELOG: Extracts and deploys DEPLOYLOG\r\nDEPLOYLOG: Deploys the WINNKIT Rootkit and serves as a userland agent \r\nWINNKIT: The Winnti Kernel-level Rootkit\r\nThe following graph describes the infection chain presented in this attack:\r\nWinnti infection chain as observed in Operation CuckooBees \r\nInitial Payload: Weaving in the Spyder Loader\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 2 of 43\n\nThe Spyder loader is the first malicious binary the attackers execute on a targeted machine. This malware is\r\nexecuted from the batch files we discussed in our blog’s part 1 - cc.bat or bc.bat:\r\nBatch file execution command\r\nThe loader’s purpose is to decrypt and load additional payloads and is being delivered in 2 variations. The first\r\nvariation, is a modified SQLite3 DLL, that uses the export’s ordinal number 138 to serve malicious code, that\r\nloads and executes a file argument provided at runtime, in our case C:\\Windows\\System32\\x64.tlb:\r\nMalicious export ordinal number 138 “sqlite3_profile_v2”\r\nAs seen above, the loader is executed via the famous LOLBIN rundll32.exe, in the following manner:\r\nrundll32.exe \u003cmodified sqlite3.dll file\u003e,#138 C:\\Windows\\System32\\x64.tlb\r\nInterestingly, Cybereason found this loader in different names and in different locations across infected machines:\r\nC:\\Windows\\System32\\iumatl.dll\r\nC:\\Windows\\System32\\msdupld.dll\r\nC:\\Windows\\System32\\mscuplt.dll\r\nC:\\Windows\\System32\\msdupld.dll\r\nC:\\Windows\\System32\\netapi.dll\r\nC:\\Windows\\System32\\rpcutl.dll\r\nC:\\Windows\\System32\\dot3utl.dll\r\nC:\\Windows\\System32\\nlsutl.dll\r\nC:\\Windows\\Branding\\Basebrd\\language.dll\r\nC:\\Program Files\\Internet Explorer\\SIGNUP\\install.dll\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 3 of 43\n\nThe attackers utilized the System32 directory, which holds a multitude of TLB and DLL files, to hide their\r\nexternal “TLB” payload and DLL loader to make it harder to detect.\r\nThis DLL wasn’t the only Spyder Loader we found, as Cybereason discovered a second variation of this malware\r\nin the form of a standalone executable called sqlite3.exe, masquerading as a SQLite3-related executable as well.\r\nThis version featured some improvements, such as logging messages, which shed some light on some of its\r\nfunctionality and capabilities:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 4 of 43\n\nMalicious export ordinal number 138 “sqlite3_profile_v2”\r\nThe Spyder Loader Bag of Tricks\r\nThroughout its execution, the Spider Loader implements a few interesting methods to evade detection and to\r\nmaintain stealth:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 5 of 43\n\nAnti Analysis/Sandboxing\r\nAt the beginning of execution, the loader checks if the file argument exists:\r\nFile argument validation\r\nIf it does, the loader checks for its size: if it is larger than 1.04 MB, it deletes it; if it is smaller than 1.04 MB or\r\nequal to it, it decrypts it in memory using the open-source CryptoPP C++ library and then deletes it from disk.\r\nCybereason assesses this condition is intended to validate that the loader won’t try to decrypt the wrong file, and\r\nas a precaution against analysis environments or Sandboxes.\r\nEDR Bypass Tricks\r\nAfter decrypting the payload, the attackers copy the system ntdll.dll file to\r\nC:\\Windows\\System32\\TN{random_characters}.dll, and load it to memory:\r\nCopying ntdll.dll to C:\\Windows\\System32\\TN{randoms_chars}.dll\r\nThen, they acquire the NtProtectVirtualMemory address from the copied and loaded file and call a specific routine\r\n(which we named as “BypassEdrHook”) multiple times using 2 arguments:\r\nThe acquired address of NtProtectVirtualMemory in the loaded, copied DLL.\r\nA string representing a native api function:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 6 of 43\n\nCalling for the BypassEdrHook routine\r\nThe BypassEdrHook function will compare the first bytes in memory of the native API functions in the loaded\r\nntdll.dll image to the first bytes in memory of the same function in the loaded/copied DLL memory image.\r\nIf the ntdll function’s first bytes are different from the first bytes of the copied DLL in memory, the attackers will\r\nconclude that this native function is hooked by an EDR tool.\r\nTo override it, the attackers count the number of different bytes at the beginning of these two functions, then they\r\nchange the permissions of the relevant patched bytes in the original ntdll.dll image to READWRITE_EXECUTE,\r\ncopy the original bytes from the loaded/copied DLL memory, and restore the previous page protection settings:\r\nCheck for EDR hook and bypass if true\r\nThis procedure will occur for the following native API functions:\r\nLdrLoadDll\r\nKiUserApcDispatcher\r\nNtAlpcConnectPort \r\nNtAllocateVirtualMemory \r\nNtFreeVirtualMemory \r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 7 of 43\n\nNtMapViewOfSection \r\nNtQueueApcThread \r\nNtReadVirtualMemory \r\nNtSetContextThread \r\nNtUnmapViewOfSection \r\nNtWriteVirtualMemory \r\nRtlInstallFunctionTableCallback \r\nRight afterward, the Spyder Loader will execute the payload reflectively, and lastly, will delete\r\nTN{random_characters}.dll to leave no traces.\r\nAttribution of the Spyder Payloads\r\nThe above-mentioned PE files share similar code with other known Spyder loaders, such as the oci.dll payload\r\nmentioned in a SonicWall blog from March 2021:\r\nAllocate memory and save WINAPI functions in array\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 8 of 43\n\nJump to the payload\r\nMoreover, our PE files also share a similar evasion technique in masquerading as a legitimate executable. In the\r\naforementioned blog post, it disguised as D3D DLL - a Direct3D 11 runtime DLL, now it disguise as SQLite3:\r\nSame method with different targeted DLLs\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 9 of 43\n\nThese similarities, in addition to others, have led us to conclude that this file is an evolution of the Winnti Spyder\r\nLoader.\r\nA Long and Winnti(ng) Road: The Winnti Multi-Phased Arsenal Deployment\r\nAfter deploying the initial payload, Winnti employs a sophisticated and unique multi-staged infection chain with\r\nnumerous payloads. Each payload fulfills a unique role in the infection chain, which is successful only upon the\r\ncomplete deployment of all of the payloads.\r\nIn the upcoming sections, we will discuss the following payloads:\r\nSTASHLOG: Stashes encrypted data in a CLFS log\r\nSPARKLOG: Extracts data from the CLFS log and deploys PRIVATELOG while escalating privileges\r\nPRIVATELOG: Extracts data from the CLFS log and deploys DEPLOYLOG. This payload also enables\r\npersistence in some cases\r\nDEPLOYLOG: Extracts data from the CLFS log, deploys the WINNKIT Rootkit driver, and acts as the\r\nuser-mode agent\r\nWINNKIT: The Winnti Kernel-level Rootkit\r\nSeveral unique techniques are used by the Winnti group to store data, evade detection, and thwart investigations\r\nduring this infection flow. One of those techniques, which Winnti heavily uses, is the CLFS mechanism.\r\nAbusing the Rarely Used CLFS Mechanism for Evasion\r\nSo what is CLFS?\r\nCLFS (Common Log File System) is a logging framework that was first introduced by Microsoft in Windows\r\nServer 2003 R2, and is included in later Windows operating systems.\r\nThis mechanism provides a high-performance logging system for a variety of purposes ranging from simple error\r\nlogs to transactional systems and data stream collection.\r\nOne of the main uses of CLFS in the Windows operating system is in the Windows Kernel Transaction Manager\r\n(KTM) for both Transactional NTFS (TxF) and Transactional Registry (TxR) operations. Transactional operations\r\nbring the concept of atomic transactions to Windows, allowing Windows to log different operations on those\r\ncomponents and support the ability to roll back if needed.\r\nThe high-performance aspect of this framework is based on the concept of storing the log data in memory buffers\r\nfor fast writing, reading and flushing them to disk–but not continuously, according to a stated policy.\r\nCLFS employs a proprietary file format that isn't documented, and can only be accessed through the CLFS API\r\nfunctions. As of writing this report, there is no tool which can parse the flushed logs. This is a huge benefit for\r\nattackers, as it makes it more difficult to examine and detect them while using the CLFS mechanism.\r\nOn disk, the CLFS log store consists of:\r\nBase Log File (BLF file): Contains the log metadata.\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 10 of 43\n\nOne or more Container files: Contains the log data, where the container file sizes are registered in the BLF\r\nfile.\r\nAs will be discussed, Winnti group used this mechanism to store and hide the payload that will be extracted from\r\nthe CLFS file and used by other PEs in the execution chain to build the attacker’s next steps.\r\nSTASHLOG: Stashing the Winnti Arsenal via CLFS\r\nSTASHLOG (shiver.exe / forsrv.exe) is a 32 bit executable that is being used to prepare the victim machine for\r\nfurther compromise, and to “stash” a malicious, encrypted payload to a CLFS log file. This payload will be\r\ndecrypted at each phase to deliver the next phase in the infection.\r\nBoth STASHLOG and SPARKLOG, which will be described further in the next section, are executed using a\r\nsecond cc.bat file in the following form:\r\nSTASHLOG and SPARKLOG execution\r\nDifferent Modes of Execution\r\nSTASHLOG has 2 modes of execution:\r\nWithout arguments to initialize the environment towards infection.\r\nWith one argument to store the CLFS file for further use.\r\nNo Arguments Mode\r\nWhen no arguments are passed, STASHLOG prints the following output:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 11 of 43\n\nExecution\r\nexample of STASHLOG without an argument\r\nThis output consists of the machine Globally Unique Identifier (GUID) along with a 56 byte string:\r\nThe machine’s GUID - derived from the HKLM\\SOFTWARE\\Microsoft\\Cryptography registry key.\r\nThe 56 byte string is generated from a random GUID created by the CoCreateGUID function. The string\r\nconsists of the hex representation of the GUID, SHA1 hash of the hex GUID, and a SHA1 hash of the\r\nGUID + SHA1 of the GUID.\r\nThis example demonstrates the process of building the 56 byte string:\r\nLet’s take a random GUID: {4684A5A2-942A-4DF6-AF1D-2A672F78F73E}\r\nThe random GUID’s Hex representation will be: A2A584462A94F64DAF1D2A672F78F73E\r\nIts SHA1 will be: 12C736FE6C9165B1C1026FAAD0051FB9F51DFF35\r\nAnd finally the SHA1 of (GUID + SHA1(GUID)): FAB426F085460CEFD4A65B8A4396C05BF582CB20\r\nThe final string will be:\r\nA2A584462A94F64DAF1D2A672F78F73E\r\n12C736FE6C9165B1C1026FAAD0051FB9F51DFF35\r\nFAB426F085460CEFD4A65B8A4396C05BF582CB20\r\nThe random GUID is then registered as a global atom entry in the form of win::{GUID}:\r\nAn\r\nexample of added Global Atom by STASHLOG\r\nIf an atom prefixed with win:: already exists during execution, then the existing atom will be used instead of the\r\nnewly generated one.\r\nOne Argument Mode\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 12 of 43\n\nUpon execution with command line arguments, STASHLOG checks the existence of the global atom table entry\r\nwin::{GUID}, and the process will quit immediately unless the value exists. \r\nThen, STASHLOG loads the file found in the given argument into memory, checks its content, and stores it in a\r\nCLFS log file. STASHLOG prints log information about this process to the terminal:\r\nPreparing for log format transformation\r\nLog transform step 1 completed\r\nLog transform step 2 completed\r\nLog transform step 3 completed\r\nLog data transform completed\r\nSuccessful STASHLOG execution log\r\nThis output in this operation was redirected to a log file, as can be seen on cc.bat. Breaking down the\r\ntransformation steps from the log:\r\nStep 1: Decrypt the given encrypted file and check the file validity\r\nby looking for the destination BLF file location: C:\\Users\\Default\\NTUSER.DAT{\u003cGUID\u003e}.TM.BLF. If\r\nthe search yields no results, STASHLOG will create this file.\r\nStep 2: Clear the targeted BLF file.\r\nStep 3: Encrypt the malicious data and write it to a CLFS file.\r\nAnti-Analysis Techniques\r\nString Obfuscation\r\nThroughout the execution, STASHLOG uses the same string decryption technique used in other samples by\r\nXORing strings with pre-defined bytes, words or qwords, using the XMM registers. This decryption sequence is\r\npresent at the beginning of every function that uses strings, where those strings are not saved globally, likely in an\r\nattempt to protect them. \r\nAs can be seen in the example below from STASHLOG, it uses it to decrypt several debug strings:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 13 of 43\n\nString\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 14 of 43\n\ndecryption algorithm from shiver.exe\r\nThis technique is also being used in other samples in the chain, including SPARKLOG, PRIVATELOG and\r\nDEPLOYLOG.\r\nAnti-Disassembly\r\nThis sample uses an interesting Anti-Disassembly technique which thwarts the disassembly process and makes the\r\ninvestigation job harder. Each function inside STASHLOG contains a jump list of every node in the function:\r\nPart of a Jump List from a function in STASHLOG\r\nThis jump list is then used as a flow control during the function execution. In some cases the address of the next\r\nnode will be pushed to a register and then there will be a JMP to this register:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 15 of 43\n\nJump to register\r\nThe more interesting use of the jump list is replacing the conditional jump commands like JZ and JNZ with a SET\r\ncommand that changes the register given as an argument to the value of the corresponding checked flag. For\r\nexample, when using SETZ eax, the EAX register will be changed to “1” if the “0” flag is checked. \r\nUsing the set register, there will be a JMP to an address on the function’s jump list. This JMP is usually resolved\r\nfor a switch-case mechanism, and IDA Pro disassembles it as one:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 16 of 43\n\nExample of jmp usage in IDA Pro\r\nUsing this method, the disassembler displays all the available JMP options based on the function’s jump list even\r\nthough there are only two jump options - when the assigned register is either 0 or 1 (in the example above it’s the\r\nECX register). These methods make the disassembled function very hard to read and investigate:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 17 of 43\n\nSingle function\r\ntree as could be seen in IDA Pro\r\nSPARKLOG: Deploying PRIVATELOG, the Next Link in the Infection Chain\r\nSPARKLOG (spark.exe) is a 32 bit executable written in C++, employed in this attack to extract a DLL from the\r\nCLFS file, decrypt it and then launch it for side-loading by Windows services running as SYSTEM. Executing this\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 18 of 43\n\nphase of the attack successfully enables the attackers to gain Privilege Escalation and also Persistence in a specific\r\ncase.\r\nSPARKLOG Execution Flow\r\nThe execution of SPARKLOG starts by creating a non-visible window followed by a message posted to trigger the\r\nexecution of the main thread:\r\nNon-visible window creation\r\nThe PE then retrieves an encrypted DLL content from the CLFS log file, decrypts it and gets the OS version in\r\nuse. This OS version will be required later to understand how to deploy the DLL in the compromised machine.\r\nThen, it decrypts the strings Global\\HVID_ and Global\\APCI#. First, it uses the\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 19 of 43\n\nGetVolumeNameForVolumeMountPointA API call to get the GUID of the operating system volume and acquires a\r\nhandle to a HVID_\u003cOS Volume GUID\u003e event. \r\nThen, it queries the MachineGUID value from the registry HKLM\\SOFTWARE\\Microsoft\\Cryptography key and\r\ncreates an event by the name of Global\\APCI#\u003cMachine GUID\u003e. Using these events is a means of\r\ncommunication between the modules in the attack, and it will be used in further modules as well:\r\nBuilding the HVID_ and APCI# events\r\nNext, it starts to deploy PRIVATELOG based on the OS version. From Windows Vista to Windows 7,\r\nSPARKLOG uses a popular DLL side loading technique that involves dropping the DLL with the name\r\nwlbsctrl.dll to the %SYSTEM32%\\WindowsPowershell\\v1.0 directory. It then stops IKEEXT, a service that was\r\ncompromised by WINNTI in the past, changes the configuration using ChangeServiceConfigA based on the\r\nargument count, then starts it again:\r\nStopped IKEEXT service\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 20 of 43\n\nChange IKEEXT service configuration based on argument count\r\nAfter a successful service start, the service executes and triggers the DLL side-loading vulnerability using\r\nSYSTEM privileges. It is interesting to note that in this case, if a command line argument is provided, the DLL\r\nwill be deleted after the execution starts. This might be due to the fact that abusing wlbsctrl.dll is pretty common,\r\nand might trigger EDR vendors later on.\r\nFrom Windows Server 2012 to Windows 10, SPARKLOG acts in a similar fashion, but with a different name and\r\nlocation:\r\nIt drops PRIVATELOG with the name prntvpt.dll to the %SYSTEM32%\\spool\\drivers\\x64\\3 directory \r\nIt then stops, changes configuration and starts the PrintNotify service to side-load the DLL (PrintNotify is a\r\nlegitimate Windows service like IKEEXT, also running as SYSTEM):\r\nOpening and querying the PrintNotify service\r\nIn both cases, the attackers gain stealth by deploying PRIVATELOG while masquerading legitimate file names in\r\nprivileged locations, as well as gaining persistence and privilege escalation to execute their next step as SYSTEM,\r\nthe most privileged user in a local machine:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 21 of 43\n\nSpark.exe execution as seen in Cybereason’s XDR Platform\r\nPRIVATELOG: Extracting and Deploying DEPLOYLOG\r\nPRIVATELOG is a module that exists in 2 forms: \r\nWlbsctrl.dll: A DLL to be side-loaded by the IKEEXT service, aiming to execute on Windows Vista to\r\nWindows 7 operating systems.\r\nPrntvpt.dll: A DLL to be side loaded by the PrintNotify service, aiming to execute on Windows Server\r\n2012 to Windows 10 operating systems.\r\nAs both of the DLLs are being loaded by native Windows services, they both live in the context of the svchost\r\nprocess, but differ in their execution flow.\r\nThe IKEEXT Hijacker\r\nAt the beginning of its execution, wlbsctrl.dll is loaded by the IKEEXT service and verifies similarly to prntvpt.dll\r\nthat it’s being executed from svchost using the right command line (netsvcs). After this check, wlbsctrl.dll goes\r\nstraight to dropping DEPLOYLOG.\r\nThe PrintNotify Hijacker\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 22 of 43\n\nAt the beginning of its execution, prntvpt.dll verifies it is being loaded by the correct process with the right\r\ncommand line (svchost -k print), similar to wlbsctrl.dll. This command line is the one being executed upon starting\r\nthe PrintNotify service.\r\nWhen the PrintNotify service starts, it also loads PrintConfig.dll, which is being executed from its ServiceMain\r\nfunction. To hijack the execution flow, prntvpt.dll loads PrintConfig.dll and acquires the address of its\r\nServiceMain function. Then, it patches this function, and adds a jump instruction to itself, to continue its\r\nexecution.\r\nThe prntvpt.dll component is different, as it is also the persistence tool for the infection, as opposed to the\r\nprevious samples we discussed which execute only once to infect the machine, this tool runs every time the\r\nPrintNotify service is executed. From this point on, the different DLL files act almost the same.\r\nDropping DEPLOYLOG\r\nPRIVATELOG decrypts DEPLOYLOG in memory from the CLFS log file, then it copies dbghelp.dll from its\r\noriginal place in C:\\Windows\\System32\\dbghelp.dll to\r\nC:\\Windows\\System32\\WindowsPowerShell\\v1.0\\dbghelp.dll. Next, the attackers use a rather unique technique to\r\noverwrite the copied dbghelp.dll with the aforementioned decrypted buffer using Windows Transactional NTFS\r\n(TxF).\r\nTransactional NTFS is a component introduced in Windows Vista that allows developers to create, edit and delete\r\nfiles and directories while giving them the option to roll back in case of errors. This mechanism is used in major\r\noperating system components like Windows Update, Task Scheduler and System Restore.\r\nUsing Transactional NTFS, the attackers can perform file operations using unconventional methods that can be\r\nhard to detect for some security products. They leverage it to create a new malicious dbghelp.dll using the\r\nfollowing steps:\r\n1. 1. A transaction handle is created for dbghelp.dll:\r\nCreateTransaction: Creates a new transaction object\r\nCreateFileTransactedA: with GENERIC_READ_WRITE access. \r\n2. The file is overwritten with the decrypted payload:\r\nWriteFile: On the transacted file handle.\r\n3. Load the file to a memory section (more about this method is covered here): \r\nNtCreateSection: with the SEC_IMAGE section attribute.\r\nNtMapViewOfSection: Mapping the file view in the created section which validates the PE\r\nheader and splits the section, but doesn’t build the import address table and set section\r\npermissions.\r\n4. Set the right section permissions and resolve the imports of the DLL:\r\nFixing section permissions using VirtualProtect calls.\r\nBuilding the DLL’s import address table with LoadLibrary and GetProcAddress calls.\r\n5. Execute the DEPLOYLOG payload entry point followed by the SvcMain.\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 23 of 43\n\nDEPLOYLOG: The Winnti Rootkit Deployment and A Usermode Agent\r\nDEPLOYLOG (dbghelp.dll) is a 64 bit DLL, with two purposes:\r\nThe first one is responsible for extracting and executing the attackers’ rootkit, dubbed WINNKIT, from the\r\nCLFS log file. \r\nAfter a successful deployment of the WINNKIT rootkit, DEPLOYLOG switches to its second task, which\r\nis communicating both with the remote C2 and the kernel-level rootkit. \r\nIt’s noteworthy to mention that to evade detection, the attackers deployed DEPLOYLOG as dbghelp.dll, a generic,\r\nwidely used name leveraged to masquerade as a legitimate file at the same location as PRIVATELOG\r\n(C:\\Windows\\System32\\WindowsPowerShell\\v1.0). \r\nDEPLOYLOG Initialization\r\nOnce DEPLOYLOG is executed, it starts with a sleep of 7777 milliseconds:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 24 of 43\n\nFigure #: Sleep\r\nbefore the main method\r\nAfterward, it tries to acquire a handle to the earlier HVID_\u003cOS Volume GUID\u003e event, and If it doesn’t exist it\r\ncreates it. Then, it initializes the communication channel with the future deployed rootkit:\r\nFirst, it tries to acquire a handle to the Beep device object: \\\\?\\GLOBALROOT\\Device\\Beep. \r\nIf it fails, it tries to do the same for \\\\?\\GLOBALROOT\\Device\\Null. To test if the rootkit was deployed in\r\nthe past and is running, DEPLOYLOG tries to send the IOCTL 15E030 to the acquired device handle:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 25 of 43\n\nDEPLOYLOG gets handles to device objects and sends an IOCTL\r\nWINNKIT Deployment\r\nUpon succeeding the earlier steps, DEPLOYLOG extracts the rootkit from the CLFS log file, decrypts its content,\r\nthen stops the amdk8 service. This service is the AMD K8 processor kernel driver service. Aiming for this specific\r\nservice can tell something about the Winnti modus operandi, indicating they aim only for AMD-related machines\r\nto be infected, which could also indicate having a prior knowledge of the victim's infrastructure.\r\nThen, DEPLOYLOG decrypts the string SystemRoot\\System32\\drivers\\bqDsp.sys and changes the amdk8 service\r\nconfiguration to point to this path:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 26 of 43\n\nChanging amdk8 service configuration to execute WINNKIT\r\nNext, DEPLOYLOG writes the bqDsp.sys rootkit driver from the CLFS log file to the\r\nC:\\WINDOWS\\system32\\drivers directory and starts the service again, this time to execute its malicious payload.\r\nBy doing so, DEPLOYLOG finishes deploying the rootkit. To cover its tracks, DEPLOYLOG will then stop the\r\nservice, restore its previous configuration to point to the amdk8.sys driver, and finally delete WINNKIT:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 27 of 43\n\nSending WINNKIT the IOCTL 0x8000C004 using Pipe2PortCtrl\r\nDEPLOYLOG as a User-Mode Agent \r\nOnce deployed, DEPLOYLOG turns to its second mission, effectively acting as a user-mode agent whose purpose\r\nis to bridge the newly deployed rootkit and the remote C2. The DLL will start communicating with the C2 servers\r\nwhich will send data that will be intercepted by the driver, as will be explained in the next section discussing\r\nWINNKIT. Using this agent, the attackers will load new modules, pop a CMD shell, drop MFSDLL.exe for\r\ncredential grabbing and more:\r\nDEPLOYLOG loaded by svchost.exe as seen in the Cybereason XDR Platform\r\nBehold WINNKIT, The Evasive Winnti Rootkit\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 28 of 43\n\nThe final payload deployed by Winnti is also the most evasive and sophisticated: a driver acting as a rootkit,\r\ndubbed WINNKIT. WINNKIT’s previous version was researched in the past, and its purpose is to act as a kernel-mode agent, interacting with the user-mode agent and intercepting TCP/IP requests, by talking directly to the\r\nnetwork card. The almost zero detection rate in VirusTotal, together with the compilation timestamp from 2019,\r\nillustrates just how evasive this rootkit really is, staying in the shadows for 3 years:\r\nLow detection rate in VirusTotal\r\nThe\r\nrootkit’s compilation timestamp\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 29 of 43\n\nWINNKIT contains an expired BenQ digital signature, which is leveraged to bypass the Driver Signature\r\nEnforcement (DSE) mechanism that requires drivers to be properly signed with digital signatures in order to be\r\nloaded successfully. This mechanism was first introduced in Windows Vista 64-bit, and is affected for all versions\r\nof Windows since then:\r\n Revoked rootkit certificate and file version\r\ninformation as seen in VirusTotal\r\nAfter successfully loading, WINNKIT hooks network communication, and operates based on custom commands\r\nthat are being sent from the aforementioned user-mode agent, DEPLOYLOG.\r\nAt the beginning of its execution, the driver validates the NDIS version, making sure the system is Windows Vista\r\nor above. By using the NDIS API, it communicates directly with the network card, skipping higher level\r\ncommunication protocols:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 30 of 43\n\nWINNKIT’s communication with the network card\r\nAfter establishing a connection with the network card, the rootkit tries to open the event \\\\BaseNamedObjects\\\\\r\n{75F09225-CD50-460B-BF90-5743B8404D73}. In case it fails, it creates this event, and then hooks the\r\n\\\\Device\\\\Null device. Hooking this device is somehow risky, as this device is often being targeted by modern\r\nrootkit, thus making it relatively exposed to detection. Nevertheless, it enabled the authors to stay undetected for\r\nyears.\r\nUsing the above mentioned mechanisms enables WINNKIT a mean of communication with the user mode agent:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 31 of 43\n\nWINNKIT event creation\r\nWINNKIT hooks the \\\\Device\\\\Null device object \r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 32 of 43\n\nThe switch case that handling different commands\r\nA summary of the communication flow of DEPLOYLOG and WINNKIT, can be seen in the following diagram:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 33 of 43\n\nRootkit high level operation diagram\r\nBelow are the functionality we believe that each code represents, according to our findings and previous\r\nconducted research:\r\nCommand Operation\r\n0x100 Hide driver\r\n0x200 Determine version\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 34 of 43\n\n0x300 Access IRQL shared data\r\n0x400 Map and allocate buffer\r\n0x500 Map a buffer\r\n0x800 Clean up\r\nWinnti Auxiliary Plugins\r\nWinnti used reflective loading injection in order to evade detection. The malicious modules are reflectively\r\ninjected into the legitimate svchost processes. The following modules were detected by Cybereason and seem\r\nconsistent with previously reported Winnti plugins:\r\nCmp2.o: The plugin's purpose is to provide access to the system command line and appears to be a variant\r\nof the Winnti \"CmdPlus\" plugin. \r\nFmg2.o: This plugin is responsible for listing and modifying files on the targeted machine and appears to\r\nbe the Winnti \"ListFileManager\" module.\r\nSrv2.o: The purpose of the plugin is to display information about system services and is assessed to be the\r\nWinnti “ListService” plugin.\r\nSck2.o: The purpose of the plugin is to transfer data over the network using a SOCKS5 proxy server and is\r\nassessed to be the “Socks5Client” plugin. \r\nPrc2.o: This plugin can list or kill running processes on the targeted machine. \r\nTrs2.o: This plugin was also used for data transfer via Socks5 proxy.\r\nCme2.o: The purpose of this plugin is to enable Remote Desktop access to Winnti:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 35 of 43\n\nExample: svchost process that loaded sck2.o and trs2.o modules reflectively, as seen in the Cybereason XDR\r\nPlatform\r\nConclusions\r\nIn part two of the research, we provided a deep dive into the Winnti malware arsenal that was observed by the\r\nCybereason IR and Nocturnus teams. Our analysis provides a unique and holistic view of Winnti operational\r\naspects, capabilities and modus operandi. While some of the tools mentioned in the research were previously\r\nreported on, some tools such as DEPLOYLOG were previously undocumented and first analyzed in this report. In\r\naddition, our analysis provides further insights regarding some of the known Winnti tools. \r\nPerhaps one of the most interesting things to notice is the elaborate and multi-phased infection chain Winnti\r\nemployed. The malware authors chose to break the infection chain into multiple interdependent phases, where\r\neach phase relies on the previous one in order to execute correctly. This demonstrates the thought and effort that\r\nwas put into both the malware and operational security considerations, making it almost impossible to analyze\r\nunless all pieces of the puzzle are assembled in the correct order. \r\nFurthermore, the rare abuse of the Windows’ own CLFS logging system and NTFS manipulations provided the\r\nattackers with extra stealth and the ability to remain undetected for years. \r\nWe hope that this report helps to shed light on Winnti operations, tools and techniques, and that it will assist to\r\nexpose further intrusions. \r\nAcknowledgments \r\nThis research has not been possible without the tireless effort, analysis, attention to details and contribution of the\r\nCybereason Incident Response team. Special thanks and appreciation goes to Matt Hart, Yusuke Shimizu, Niamh\r\nO’Connor, Jim Hung, and Omer Yampel. \r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 36 of 43\n\nIndicators of Compromise\r\nLOOKING FOR THE IOCs? CLICK ON THE CHATBOT DISPLAYED IN LOWER-RIGHT OF YOUR SCREEN\r\nFOR ACCESS. Due to the sensitive nature of the attack, not all IOCs observed by Cybereason can be shared in\r\nour public report. Please contact us for more information.\r\nMITRE ATT\u0026CK BREAKDOWN\r\nReconnaissance\r\nInitial\r\nAccess\r\nExecution Persistence\r\nPrivilege\r\nEscalation\r\nDefense\r\nEvasion\r\nGather Victim\r\nIdentity\r\nInformation:\r\nCredentials\r\nExploit\r\nPublic-Facing\r\nApplication\r\nScheduled\r\nTask/Job\r\nServer\r\nSoftware\r\nComponent:\r\nWeb Shell\r\nCreate or\r\nModify\r\nSystem\r\nProcess:\r\nWindows\r\nService\r\nHijack\r\nExecution\r\nFlow: DLL\r\nSide-Loading\r\nGather Victim\r\nNetwork\r\nInformation\r\nSupply Chain\r\nCompromise\r\nInter-process\r\ncommunication\r\n \r\nHijack\r\nExecution\r\nFlow: DLL\r\nSide-Loading\r\nRootkit\r\n   \r\nExploitation for\r\nClient Execution\r\n \r\nProcess\r\nInjection:\r\nDynamic-link Library\r\nInjection\r\nMasquerading:\r\nMatch\r\nLegitimate\r\nName or\r\nLocation\r\n   \r\nCommand and\r\nScripting\r\nInterpreter:\r\nWindows\r\nCommand Shell\r\nScheduled\r\nTask/Job:\r\nScheduled\r\nTask\r\nScheduled\r\nTask/Job:\r\nScheduled\r\nTask\r\nProcess\r\nInjection:\r\nDynamic-link\r\nLibrary\r\nInjection\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 37 of 43\n\nCommand and\r\nScripting\r\nInterpreter:\r\nVisual Basic\r\nValid\r\nAccounts:\r\nDomain\r\nAccounts\r\nValid\r\nAccounts:\r\nDomain\r\nAccounts\r\nReflective Code\r\nLoading\r\n    Native API\r\nValid\r\nAccounts:\r\nLocal\r\nAccounts\r\nValid\r\nAccounts:\r\nLocal\r\nAccounts\r\nSigned Binary\r\nProxy\r\nExecution:\r\nRundll32\r\n         \r\nValid Accounts:\r\nDomain\r\nAccounts\r\n         \r\nValid Accounts:\r\nLocal Accounts\r\nCredential\r\nAccess\r\nDiscovery\r\nLateral\r\nmovement\r\nCollection Exfiltration\r\nCommand\r\nand Control\r\nOS\r\nCredential\r\nDumping\r\nSystem Network\r\nConfiguration\r\nDiscovery\r\nExploitation of\r\nRemote\r\nServices\r\nArchive\r\nCollected\r\nData: Archive\r\nvia Utility\r\nAutomated\r\nExfiltration\r\nApplication\r\nLayer Protocol:\r\nWeb Protocols\r\n \r\nRemote System\r\nDiscovery\r\nRemote\r\nServices:\r\nRemote\r\nDesktop\r\nProtocol\r\nAutomated\r\nCollection\r\n  Proxy\r\n \r\nPassword Policy\r\nDiscovery\r\n       \r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 38 of 43\n\nPermission\r\nGroups\r\nDiscovery\r\n       \r\n \r\nNetwork Share\r\nDiscovery\r\n       \r\n \r\nSystem Service\r\nDiscovery\r\n       \r\n \r\nSystem Time\r\nDiscovery\r\n       \r\n \r\nSystem Network\r\nConnections\r\nDiscovery\r\n       \r\n \r\nAccount\r\nDiscovery\r\n       \r\n \r\nSystem\r\nOwner/User\r\nDiscovery\r\n       \r\n \r\nSystem\r\nInformation\r\nDiscovery\r\n       \r\n \r\nProcess\r\nDiscovery\r\n       \r\nAbout the Researchers:\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 39 of 43\n\nChen Erlich\r\nChen has almost a decade of experience in Threat Intelligence \u0026 Research, Incident Response and Threat\r\nHunting. Before joining Cybereason, Chen spent three years dissecting APTs, investigating underground\r\ncybercriminal groups and discovering security vulnerabilities in known vendors. Previously, he served as a\r\nSecurity Researcher in the military forces.\r\nFusao Tanida\r\nFusao spent over 10 years in the security industry. Before joining, he worked as a mobile malware researcher and\r\na developer at the security vendor and then worked at the global mobile phone manufacturer for the development\r\nof AntiVirus, VPN client on their Android mobile phone.\r\nFusao joined Cybereason in 2019 and was previously the Senior Security Analyst at the Advanced Services Team\r\nin Cybereason Japan where delivered various security professional services, Incident Response, consultation and\r\ntriage malware activity alerts in SOC.\r\nOfir Ozer\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 40 of 43\n\nOfir is a Incident Response Engineer at Cybereason who has a keen interest in Windows Internals, reverse\r\nengineering, memory analysis and network anomalies. He has years of experience in Cyber Security, focusing on\r\nMalware Research, Incident Response and Threat Hunting. Ofir started his career as a Security Researcher in the\r\nmilitary forces and then became a malware researcher focusing on Banking Trojans.\r\nAkihiro Tomita\r\nAkihiro is the Senior Manager of Global Security Practice, leading Incident Response team in the APAC region\r\nand Japan. Akihiro has led a substantial number of large-scale Incident Response, Digital Forensics and\r\nCompromise Assessment engagements during recent years. Akihiro was also a former Team lead of Advanced\r\nSecurity Services team responsible for managing, developing, delivering a variety of professional services\r\nincluding Proactive threat hunting, Security Posture Assessment, Advanced security training and consulting\r\nservices at Cybereason.\r\nNiv Yona\r\nNiv, IR Practice Director, leads Cybereason's incident response practice in the EMEA region. Niv began his career\r\na decade ago in the Israeli Air Force as a team leader in the security operations center, where he specialized in\r\nincident response, forensics, and malware analysis. In former roles at Cybereason, he focused on threat research\r\nthat directly enhances product detections and the Cybereason threat hunting playbook, as well as the development\r\nof new strategic services and offerings.\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 41 of 43\n\nDaniel Frank\r\nWith a decade in malware research, Daniel uses his expertise with malware analysis and reverse engineering to\r\nunderstand APT activity and commodity cybercrime attackers. Daniel has previously shared research at RSA\r\nConference, the Microsoft Digital Crimes Consortium, and Rootcon.\r\nASSAF DAHAN, HEAD OF THREAT RESEARCH\r\nAssaf has over 15 years in the InfoSec industry. He started his career in the military forces Cybersecurity unit\r\nwhere he developed extensive experience in offensive security. Later in his career he led Red Teams, developed\r\npenetration testing methodologies, and specialized in malware analysis and reverse engineering.\r\nAbout the Author\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 42 of 43\n\nCybereason Nocturnus\r\n \r\nThe Cybereason Nocturnus Team has brought the world’s brightest minds from the military, government\r\nintelligence, and enterprise security to uncover emerging threats across the globe. They specialize in analyzing\r\nnew attack methodologies, reverse-engineering malware, and exposing unknown system vulnerabilities. The\r\nCybereason Nocturnus Team was the first to release a vaccination for the 2017 NotPetya and Bad Rabbit\r\ncyberattacks.\r\nAll Posts by Cybereason Nocturnus\r\nSource: https://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nhttps://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive\r\nPage 43 of 43",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive"
	],
	"report_names": [
		"operation-cuckoobees-a-winnti-malware-arsenal-deep-dive"
	],
	"threat_actors": [
		{
			"id": "5bbced13-72f7-40dc-8c41-dcce75bf885e",
			"created_at": "2022-10-25T15:50:23.695735Z",
			"updated_at": "2026-04-10T02:00:05.335976Z",
			"deleted_at": null,
			"main_name": "Winnti Group",
			"aliases": [
				"Winnti Group"
			],
			"source_name": "MITRE:Winnti Group",
			"tools": [
				"PipeMon",
				"Winnti for Windows",
				"PlugX"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "c7d9878a-e691-4c6f-81ae-84fb115a1345",
			"created_at": "2022-10-25T16:07:23.359506Z",
			"updated_at": "2026-04-10T02:00:04.556639Z",
			"deleted_at": null,
			"main_name": "APT 41",
			"aliases": [
				"BrazenBamboo",
				"Bronze Atlas",
				"Double Dragon",
				"Earth Baku",
				"G0096",
				"Grayfly",
				"Operation ColunmTK",
				"Operation CuckooBees",
				"Operation ShadowHammer",
				"Red Kelpie",
				"SparklingGoblin",
				"TA415",
				"TG-2633"
			],
			"source_name": "ETDA:APT 41",
			"tools": [
				"9002 RAT",
				"ADORE.XSEC",
				"ASPXSpy",
				"ASPXTool",
				"AceHash",
				"Agent.dhwf",
				"Agentemis",
				"AndroidControl",
				"AngryRebel",
				"AntSword",
				"BLUEBEAM",
				"Barlaiy",
				"BlackCoffee",
				"Bladabindi",
				"BleDoor",
				"CCleaner Backdoor",
				"CHINACHOPPER",
				"COLDJAVA",
				"China Chopper",
				"ChyNode",
				"Cobalt Strike",
				"CobaltStrike",
				"Crackshot",
				"CrossWalk",
				"CurveLast",
				"CurveLoad",
				"DAYJOB",
				"DBoxAgent",
				"DEADEYE",
				"DEADEYE.APPEND",
				"DEADEYE.EMBED",
				"DEPLOYLOG",
				"DIRTCLEANER",
				"DUSTTRAP",
				"Derusbi",
				"Destroy RAT",
				"DestroyRAT",
				"DodgeBox",
				"DragonEgg",
				"ELFSHELF",
				"EasyNight",
				"Farfli",
				"FunnySwitch",
				"Gh0st RAT",
				"Ghost RAT",
				"HDD Rootkit",
				"HDRoot",
				"HKDOOR",
				"HOMEUNIX",
				"HUI Loader",
				"HidraQ",
				"HighNoon",
				"HighNote",
				"Homux",
				"Hydraq",
				"Jorik",
				"Jumpall",
				"KEYPLUG",
				"Kaba",
				"Korplug",
				"LATELUNCH",
				"LOLBAS",
				"LOLBins",
				"LightSpy",
				"Living off the Land",
				"Lowkey",
				"McRAT",
				"MdmBot",
				"MessageTap",
				"Meterpreter",
				"Mimikatz",
				"MoonBounce",
				"MoonWalk",
				"Motnug",
				"Moudour",
				"Mydoor",
				"NTDSDump",
				"PACMAN",
				"PCRat",
				"PINEGROVE",
				"PNGRAT",
				"POISONPLUG",
				"POISONPLUG.SHADOW",
				"POTROAST",
				"PRIVATELOG",
				"PipeMon",
				"PlugX",
				"PortReuse",
				"ProxIP",
				"ROCKBOOT",
				"RbDoor",
				"RedDelta",
				"RedXOR",
				"RibDoor",
				"Roarur",
				"RouterGod",
				"SAGEHIRE",
				"SPARKLOG",
				"SQLULDR2",
				"STASHLOG",
				"SWEETCANDLE",
				"ScrambleCross",
				"Sensocode",
				"SerialVlogger",
				"ShadowHammer",
				"ShadowPad Winnti",
				"SinoChopper",
				"Skip-2.0",
				"SneakCross",
				"Sogu",
				"Speculoos",
				"Spyder",
				"StealthReacher",
				"StealthVector",
				"TERA",
				"TIDYELF",
				"TIGERPLUG",
				"TOMMYGUN",
				"TVT",
				"Thoper",
				"Voldemort",
				"WIDETONE",
				"WINNKIT",
				"WINTERLOVE",
				"Winnti",
				"WyrmSpy",
				"X-Door",
				"XDOOR",
				"XMRig",
				"XShellGhost",
				"Xamtrav",
				"ZXShell",
				"ZoxPNG",
				"certutil",
				"certutil.exe",
				"cobeacon",
				"gresim",
				"njRAT",
				"pwdump",
				"xDll"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "4d5f939b-aea9-4a0e-8bff-003079a261ea",
			"created_at": "2023-01-06T13:46:39.04841Z",
			"updated_at": "2026-04-10T02:00:03.196806Z",
			"deleted_at": null,
			"main_name": "APT41",
			"aliases": [
				"WICKED PANDA",
				"BRONZE EXPORT",
				"Brass Typhoon",
				"TG-2633",
				"Leopard Typhoon",
				"G0096",
				"Grayfly",
				"BARIUM",
				"BRONZE ATLAS",
				"Red Kelpie",
				"G0044",
				"Earth Baku",
				"TA415",
				"WICKED SPIDER",
				"HOODOO",
				"Winnti",
				"Double Dragon"
			],
			"source_name": "MISPGALAXY:APT41",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "945a572f-ebe3-4e2f-a288-512fe751cfa8",
			"created_at": "2022-10-25T16:07:24.413971Z",
			"updated_at": "2026-04-10T02:00:04.97924Z",
			"deleted_at": null,
			"main_name": "Winnti Group",
			"aliases": [
				"G0044",
				"Leopard Typhoon",
				"Wicked Panda",
				"Winnti Group"
			],
			"source_name": "ETDA:Winnti Group",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"FunnySwitch",
				"RbDoor",
				"RibDoor",
				"RouterGod",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "2a24d664-6a72-4b4c-9f54-1553b64c453c",
			"created_at": "2025-08-07T02:03:24.553048Z",
			"updated_at": "2026-04-10T02:00:03.787296Z",
			"deleted_at": null,
			"main_name": "BRONZE ATLAS",
			"aliases": [
				"APT41 ",
				"BARIUM ",
				"Blackfly ",
				"Brass Typhoon",
				"CTG-2633",
				"Earth Baku ",
				"GREF",
				"Group 72 ",
				"Red Kelpie ",
				"TA415 ",
				"TG-2633 ",
				"Wicked Panda ",
				"Winnti"
			],
			"source_name": "Secureworks:BRONZE ATLAS",
			"tools": [
				"Acehash",
				"CCleaner v5.33 backdoor",
				"ChinaChopper",
				"Cobalt Strike",
				"DUSTPAN",
				"Dicey MSDN",
				"Dodgebox",
				"ForkPlayground",
				"HUC Proxy Malware (Htran)"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434317,
	"ts_updated_at": 1775826726,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b86bc64e0d8ea568d722e602600f3370ecd4800c.pdf",
		"text": "https://archive.orkl.eu/b86bc64e0d8ea568d722e602600f3370ecd4800c.txt",
		"img": "https://archive.orkl.eu/b86bc64e0d8ea568d722e602600f3370ecd4800c.jpg"
	}
}