# Operation CuckooBees: A Winnti Malware Arsenal Deep- Dive **[cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive](https://www.cybereason.com/blog/operation-cuckoobees-a-winnti-malware-arsenal-deep-dive)** Written By Cybereason Nocturnus May 4, 2022 | 19 minute read ----- In [part one of this research, the](https://www.cybereason.com/blog/operation-cuckoobees-deep-dive-into-stealthy-winnti-techniques) [Cybereason Nocturnus Incident Response Team provided a](https://www.cybereason.com/services/incident-response) unique glimpse into the Winnti intrusion playbook, covering the techniques that were used by the group from initial compromise to stealing the data, as observed and analyzed by the Cybereason Incident Response team. This part of the research zeroes in on the Winnti malware arsenal that was discovered during the investigation conducted by the Cybereason IR and Nocturnus teams. In addition, our analysis of the observed malware provides a deeper understanding of the elaborate and multilayered Winnti infection chain, including evasive maneuvers and stealth techniques that are baked-in to the malware code, as well as the functionality of the various malware. Perhaps one of the most interesting and striking aspects of this report is the level of sophistication introduced by the malware authors. The infection and deployment chain is long, complicated and interdependent–should one step go wrong, the entire chain collapses - making it somewhat vulnerable, yet at the same time provides an extra level of security and stealth for the operation. These steps have proven themselves effective time and time again, as the operation remained under-the-radar for years. While there have been past reports describing some aspects of these intrusions, at the time of writing this report there was no publicly available research that discussed all of the tools and techniques and the manner in which they all fit together, as mentioned in this report. ## Key Findings **Attribution to the Winnti APT Group: based on the analysis of the forensic artifacts,** Cybereason estimates with medium-high confidence that the perpetrators of the attack [are linked to the notorious Winnti APT group, a group that has existed since at least 2010](https://attack.mitre.org/groups/G0044/) and is believed to be operating on behalf of Chinese state interests and specializes in cyberespionage and intellectual property theft. **Discovery of New Malware in the Winnti Arsenal: the report exposes previously** undocumented malware strain called DEPLOYLOG used by the Winnti APT group and highlights new versions of known Winnti malware, including Spyder Loader, PRIVATELOG, and WINNKIT. **Rarely Seen Abuse of the Windows CLFS Feature: the attackers leveraged the** Windows CLFS mechanism and NTFS transaction manipulations which provided them with the ability to conceal their payloads and evade detection by traditional security products. ----- **Intricate and Interdependent Payload Delivery: the report includes an analysis of the** complex infection chain that led to the deployment of the WINNKIT rootkit composed of multiple interdependent components. The attackers implemented a delicate “house of cards” approach, meaning that each component depends on the others to function properly, making it very difficult to analyze each component separately. The malware from the Winnti arsenal that are analyzed in this report include: **Spyder: A sophisticated modular backdoor** **STASHLOG: The initial deployment tool “stashing” payloads in Windows CLFS** **SPARKLOG: Extracts and deploys PRIVATELOG to gain privilege escalation and** achieve persistence **PRIVATELOG: Extracts and deploys DEPLOYLOG** **DEPLOYLOG: Deploys the WINNKIT Rootkit and serves as a userland agent** **WINNKIT: The Winnti Kernel-level Rootkit** The following graph describes the infection chain presented in this attack: _Winnti infection chain as observed in Operation CuckooBees_ ## Initial Payload: Weaving in the Spyder Loader ----- The [Spyder loader is the first malicious binary the attackers execute on a targeted machine.](https://st.drweb.com/static/new-www/news/2021/march/BackDoor.Spyder.1_en.pdf) This malware is executed from the batch files we discussed in our blog’s part 1 - cc.bat or _bc.bat:_ _Batch_ _file execution command_ The loader’s purpose is to decrypt and load additional payloads and is being delivered in 2 variations. The first variation, is a modified SQLite3 DLL, that uses the export’s ordinal number 138 to serve malicious code, that loads and executes a file argument provided at runtime, in our case C:\Windows\System32\x64.tlb: _Malicious export ordinal number 138 “sqlite3_profile_v2”_ As seen above, the loader is executed via the famous LOLBIN rundll32.exe, in the following manner: _rundll32.exe ,#138 C:\Windows\System32\x64.tlb_ Interestingly, Cybereason found this loader in different names and in different locations across infected machines: C:\Windows\System32\iumatl.dll C:\Windows\System32\msdupld.dll C:\Windows\System32\mscuplt.dll C:\Windows\System32\msdupld.dll C:\Windows\System32\netapi.dll C:\Windows\System32\rpcutl.dll C:\Windows\System32\dot3utl.dll C:\Windows\System32\nlsutl.dll ----- C:\Windows\Branding\Basebrd\language.dll C:\Program Files\Internet Explorer\SIGNUP\install.dll [The attackers utilized the System32 directory, which holds a multitude of TLB and DLL files, to](https://docs.microsoft.com/en-us/windows/win32/midl/com-dcom-and-type-libraries) hide their external “TLB” payload and DLL loader to make it harder to detect. This DLL wasn’t the only Spyder Loader we found, as Cybereason discovered a second variation of this malware in the form of a standalone executable called sqlite3.exe, masquerading as a SQLite3-related executable as well. This version featured some improvements, such as logging messages, which shed some light on some of its functionality and capabilities: ----- _Malicious export ordinal number 138 “sqlite3_profile_v2”_ ### The Spyder Loader Bag of Tricks Throughout its execution, the Spider Loader implements a few interesting methods to evade detection and to maintain stealth: ----- **Anti Analysis/Sandboxing** At the beginning of execution, the loader checks if the file argument exists: _File argument validation_ If 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 equal to it, it decrypts it in memory using the open-source CryptoPP C++](https://cryptopp.com/) library and then deletes it from disk. Cybereason assesses this condition is intended to validate that the loader won’t try to decrypt [the wrong file, and as a precaution against analysis environments or](https://attack.mitre.org/techniques/T1523/) [Sandboxes.](https://attack.mitre.org/techniques/T1497/) **EDR Bypass Tricks** After decrypting the payload, the attackers copy the system ntdll.dll file to _C:\Windows\System32\TN{random_characters}.dll, and load it to memory:_ _Copying ntdll.dll to C:\Windows\System32\TN{randoms_chars}.dll_ Then, they acquire the NtProtectVirtualMemory address from the copied and loaded file and call a specific routine (which we named as “BypassEdrHook”) multiple times using 2 arguments: The acquired address of NtProtectVirtualMemory in the loaded, copied DLL. ----- A string representing a native api function: _Calling for the BypassEdrHook routine_ The BypassEdrHook function will compare the first bytes in memory of the native API functions in the loaded ntdll.dll image to the first bytes in memory of the same function in the loaded/copied DLL memory image. If the ntdll function’s first bytes are different from the first bytes of the copied DLL in memory, the attackers will conclude that this native function is hooked by an EDR tool. To override it, the attackers count the number of different bytes at the beginning of these two functions, then they change the permissions of the relevant patched bytes in the original ntdll.dll image to READWRITE_EXECUTE, copy the original bytes from the loaded/copied DLL memory, and restore the previous page protection settings: _Check for EDR hook and bypass if true_ This procedure will occur for the following native API functions: LdrLoadDll ----- KiUserApcDispatcher NtAlpcConnectPort NtAllocateVirtualMemory NtFreeVirtualMemory NtMapViewOfSection NtQueueApcThread NtReadVirtualMemory NtSetContextThread NtUnmapViewOfSection NtWriteVirtualMemory RtlInstallFunctionTableCallback Right afterward, the Spyder Loader will execute the payload reflectively, and lastly, will delete _TN{random_characters}.dll to leave no traces._ ### Attribution of the Spyder Payloads The above-mentioned PE files share similar code with other known Spyder loaders, such as the _[oci.dll payload mentioned in a SonicWall blog from March 2021:](https://securitynews.sonicwall.com/xmlpost/chinas-winnti-spyder-module/)_ _Allocate memory and save WINAPI functions in array_ ----- _Jump to the payload_ Moreover, our PE files also share a similar evasion technique in masquerading as a legitimate executable. In the aforementioned blog post, it disguised as D3D DLL - a Direct3D 11 runtime DLL, now it disguise as SQLite3: ----- _Same method with different targeted DLLs_ These similarities, in addition to others, have led us to conclude that this file is an evolution of the Winnti Spyder Loader. ## A Long and Winnti(ng) Road: The Winnti Multi-Phased Arsenal Deployment After deploying the initial payload, Winnti employs a sophisticated and unique multi-staged infection chain with numerous payloads. Each payload fulfills a unique role in the infection chain, which is successful only upon the complete deployment of all of the payloads. In the upcoming sections, we will discuss the following payloads: **STASHLOG: Stashes encrypted data in a CLFS log** **SPARKLOG: Extracts data from the CLFS log and deploys PRIVATELOG while** escalating privileges **PRIVATELOG: Extracts data from the CLFS log and deploys DEPLOYLOG. This payload** also enables persistence in some cases **DEPLOYLOG: Extracts data from the CLFS log, deploys the WINNKIT Rootkit driver, and** acts as the user-mode agent **WINNKIT: The Winnti Kernel-level Rootkit** Several unique techniques are used by the Winnti group to store data, evade detection, and thwart investigations during this infection flow. One of those techniques, which Winnti heavily uses, is the CLFS mechanism. ### Abusing the Rarely Used CLFS Mechanism for Evasion **So what is CLFS?** [CLFS (Common Log File System) is a logging framework that was first introduced by Microsoft](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-the-common-log-file-system) in Windows Server 2003 R2, and is included in later Windows operating systems. This mechanism provides a high-performance logging system for a variety of purposes ranging from simple error logs to transactional systems and data stream collection. ----- One of the main uses of CLFS in the Windows operating system is in the Windows Kernel Transaction Manager (KTM) for both Transactional NTFS (TxF) and Transactional Registry (TxR) operations. Transactional operations bring the concept of atomic transactions to Windows, allowing Windows to log different operations on those components and support the ability to roll back if needed. The high-performance aspect of this framework is based on the concept of storing the log data in memory buffers for fast writing, reading and flushing them to disk–but not continuously, according to a stated policy. CLFS employs a proprietary file format that isn't documented, and can only be accessed through the CLFS API functions. As of writing this report, there is no tool which can parse the flushed logs. This is a huge benefit for attackers, as it makes it more difficult to examine and detect them while using the CLFS mechanism. On disk, the CLFS log store consists of: Base Log File (BLF file): Contains the log metadata. One or more Container files: Contains the log data, where the container file sizes are registered in the BLF file. As will be discussed, Winnti group used this mechanism to store and hide the payload that will be extracted from the CLFS file and used by other PEs in the execution chain to build the attacker’s next steps. ### STASHLOG: Stashing the Winnti Arsenal via CLFS [STASHLOG (shiver.exe / forsrv.exe) is a 32 bit executable that is being used to prepare the](https://www.mandiant.com/resources/unknown-actor-using-clfs-log-files-for-stealth) victim machine for further compromise, and to “stash” a malicious, encrypted payload to a CLFS log file. This payload will be decrypted at each phase to deliver the next phase in the infection. ----- Both STASHLOG and SPARKLOG, which will be described further in the next section, are executed using a second cc.bat file in the following form: _STASHLOG and SPARKLOG execution_ **Different Modes of Execution** STASHLOG has 2 modes of execution: Without arguments to initialize the environment towards infection. With one argument to store the CLFS file for further use. No Arguments Mode When no arguments are passed, STASHLOG prints the following output: _Execution_ _example of STASHLOG without an argument_ This output consists of the machine Globally Unique Identifier (GUID) along with a 56 byte string: The machine’s GUID - derived from the HKLM\SOFTWARE\Microsoft\Cryptography registry key. The 56 byte string is generated from a random GUID created by the CoCreateGUID function. The string consists of the hex representation of the GUID, SHA1 hash of the hex GUID, and a SHA1 hash of the GUID + SHA1 of the GUID. This example demonstrates the process of building the 56 byte string: Let’s take a random GUID: {4684A5A2-942A-4DF6-AF1D-2A672F78F73E} The random GUID’s Hex representation will be: A2A584462A94F64DAF1D2A672F78F73E Its SHA1 will be: 12C736FE6C9165B1C1026FAAD0051FB9F51DFF35 ----- And finally the SHA1 of (GUID + SHA1(GUID)): FAB426F085460CEFD4A65B8A4396C05BF582CB20 The final string will be: A2A584462A94F64DAF1D2A672F78F73E 12C736FE6C9165B1C1026FAAD0051FB9F51DFF35 FAB426F085460CEFD4A65B8A4396C05BF582CB20 The random GUID is then registered as a global atom entry in the form of win::{GUID}: _An_ _example of added Global Atom by STASHLOG_ If an atom prefixed with win:: already exists during execution, then the existing atom will be used instead of the newly generated one. One Argument Mode Upon execution with command line arguments, STASHLOG checks the existence of the global atom table entry win::{GUID}, and the process will quit immediately unless the value exists. Then, STASHLOG loads the file found in the given argument into memory, checks its content, and stores it in a CLFS log file. STASHLOG prints log information about this process to the terminal: Preparing for log format transformation Log transform step 1 completed Log transform step 2 completed Log transform step 3 completed Log data transform completed Successful STASHLOG execution log This output in this operation was redirected to a log file, as can be seen on cc.bat. Breaking down the transformation steps from the log: **Step 1: Decrypt the given encrypted file and check the file validity** by looking for the destination BLF file location: _C:\Users\Default\NTUSER.DAT{}.TM.BLF. If the search yields no results,_ STASHLOG will create this file. **Step 2: Clear the targeted BLF file.** **Step 3: Encrypt the malicious data and write it to a CLFS file.** Anti-Analysis Techniques _String Obfuscation_ ----- Throughout the execution, STASHLOG uses the same string decryption technique used in other samples by XORing strings with pre-defined bytes, words or qwords, using the XMM registers. This decryption sequence is present at the beginning of every function that uses strings, where those strings are not saved globally, likely in an attempt to protect them. As can be seen in the example below from STASHLOG, it uses it to decrypt several debug strings: ----- _String_ _decryption algorithm from shiver exe_ ----- This technique is also being used in other samples in the chain, including SPARKLOG, PRIVATELOG and DEPLOYLOG. _Anti-Disassembly_ This sample uses an interesting Anti-Disassembly technique which thwarts the disassembly process and makes the investigation job harder. Each function inside STASHLOG contains a jump list of every node in the function: _Part of a Jump List from a function in STASHLOG_ This jump list is then used as a flow control during the function execution. In some cases the address of the next node will be pushed to a register and then there will be a JMP to this register: ----- _Jump_ _to register_ The more interesting use of the jump list is replacing the conditional jump commands like JZ and JNZ with a SET command that changes the register given as an argument to the value of the corresponding checked flag. For example, when using SETZ eax, the EAX register will be changed to “1” if the “0” flag is checked. Using the set register, there will be a JMP to an address on the function’s jump list. This JMP is usually resolved for a switch-case mechanism, and IDA Pro disassembles it as one: ----- _Example of jmp usage in IDA Pro_ Using this method, the disassembler displays all the available JMP options based on the function’s jump list even though there are only two jump options - when the assigned register is either 0 or 1 (in the example above it’s the ECX register). These methods make the disassembled function very hard to read and investigate: ----- _Single function_ _tree as could be seen in IDA Pro_ ### SPARKLOG: Deploying PRIVATELOG, the Next Link in the Infection Chain [SPARKLOG (spark.exe) is a 32 bit executable written in C++, employed in this attack to extract](https://twitter.com/ESETresearch/status/1433819571207774209?s=20&t=vQjvuSCLkka_ZKrngChcYg) a DLL from the CLFS file, decrypt it and then launch it for side-loading by Windows services running as SYSTEM. Executing this phase of the attack successfully enables the attackers to ----- gain [Privilege Escalation and also](https://attack.mitre.org/tactics/TA0004/) [Persistence in a specific case.](https://attack.mitre.org/tactics/TA0003/) **SPARKLOG Execution Flow** The execution of SPARKLOG starts by creating a non-visible window followed by a message posted to trigger the execution of the main thread: _Non-visible window creation_ The PE then retrieves an encrypted DLL content from the CLFS log file, decrypts it and gets the OS version in use. This OS version will be required later to understand how to deploy the DLL in the compromised machine. Then, it decrypts the strings Global\HVID_ and Global\APCI#. First, it uses the GetVolumeNameForVolumeMountPointA API call to get the GUID of the operating system volume and acquires a handle to a HVID event ----- Then, it queries the MachineGUID value from the registry _HKLM\SOFTWARE\Microsoft\Cryptography key and creates an event by the name of_ _Global\APCI#. Using these events is a means of communication between the_ modules in the attack, and it will be used in further modules as well: _Building the HVID_ and APCI# events_ Next, it starts to deploy PRIVATELOG based on the OS version. From Windows Vista to Windows 7, SPARKLOG uses a popular DLL side loading technique that involves dropping the DLL with the name wlbsctrl.dll to the %SYSTEM32%\WindowsPowershell\v1.0 directory. It then stops [IKEEXT, a service that was compromised by WINNTI in the](https://github.com/securycore/Ikeext-Privesc) [past, changes the](https://speakerdeck.com/aragorntseng/winnti-is-coming-evolution-after-prosecution-at-hitcon2021?slide=23) configuration using ChangeServiceConfigA based on the argument count, then starts it again: _Stopped IKEEXT service_ ----- _Change IKEEXT service configuration based on argument count_ After a successful service start, the service executes and triggers the DLL side-loading vulnerability using SYSTEM privileges. It is interesting to note that in this case, if a command line argument is provided, the DLL will be deleted after the execution starts. This might be due to the fact that [abusing wlbsctrl.dll is pretty common, and might trigger EDR vendors later on.](http://elastic.co/guide/en/security/current/suspicious-dll-loaded-for-persistence-or-privilege-escalation.html) From Windows Server 2012 to Windows 10, SPARKLOG acts in a similar fashion, but with a different name and location: It drops PRIVATELOG with the name prntvpt.dll to the %SYSTEM32%\spool\drivers\x64\3 directory It then stops, changes configuration and starts the PrintNotify service to side-load the DLL (PrintNotify is a legitimate Windows service like IKEEXT, also running as SYSTEM): _Opening and querying the PrintNotify service_ In both cases, the attackers gain stealth by deploying PRIVATELOG while masquerading legitimate file names in privileged locations, as well as gaining persistence and privilege escalation to execute their next step as SYSTEM, the most privileged user in a local machine: ----- _Spark.exe execution as seen in Cybereason’s XDR Platform_ ### PRIVATELOG: Extracting and Deploying DEPLOYLOG [PRIVATELOG is a module that exists in 2 forms:](https://www.mandiant.com/resources/unknown-actor-using-clfs-log-files-for-stealth) _Wlbsctrl.dll: A DLL to be side-loaded by the IKEEXT service, aiming to execute on_ Windows Vista to Windows 7 operating systems. _Prntvpt.dll: A DLL to be side loaded by the PrintNotify service, aiming to execute on_ Windows Server 2012 to Windows 10 operating systems. As both of the DLLs are being loaded by native Windows services, they both live in the context of the [svchost process, but differ in their execution flow.](https://en.wikipedia.org/wiki/Svchost.exe) **The IKEEXT Hijacker** At the beginning of its execution, wlbsctrl.dll is loaded by the IKEEXT service and verifies similarly to prntvpt.dll that it’s being executed from svchost using the right command line (netsvcs). After this check, wlbsctrl.dll goes straight to dropping DEPLOYLOG. **The PrintNotify Hijacker** ----- At the beginning of its execution, prntvpt.dll verifies it is being loaded by the correct process with the right command line (svchost -k print), similar to wlbsctrl.dll. This command line is the one being executed upon starting the PrintNotify service. When the PrintNotify service starts, it also loads PrintConfig.dll, which is being executed from its ServiceMain function. To hijack the execution flow, prntvpt.dll loads PrintConfig.dll and acquires the address of its ServiceMain function. Then, it patches this function, and adds a jump instruction to itself, to continue its execution. The prntvpt.dll component is different, as it is also the persistence tool for the infection, as opposed to the previous samples we discussed which execute only once to infect the machine, this tool runs every time the PrintNotify service is executed. From this point on, the different DLL files act almost the same. **Dropping DEPLOYLOG** PRIVATELOG decrypts DEPLOYLOG in memory from the CLFS log file, then it copies _dbghelp.dll from its original place in C:\Windows\System32\dbghelp.dll to_ _C:\Windows\System32\WindowsPowerShell\v1.0\dbghelp.dll. Next, the attackers use a rather_ unique technique to overwrite the copied dbghelp.dll with the aforementioned decrypted buffer using [Windows Transactional NTFS (TxF).](https://docs.microsoft.com/en-us/windows/win32/fileio/transactional-ntfs-portal) Transactional NTFS is a component introduced in Windows Vista that allows developers to create, edit and delete files and directories while giving them the option to roll back in case of errors. This mechanism is used in major operating system components like Windows Update, Task Scheduler and System Restore. Using Transactional NTFS, the attackers can perform file operations using unconventional methods that can be hard to detect for some security products. They leverage it to create a new malicious dbghelp.dll using the following steps: ----- 1. 1. A transaction handle is created for dbghelp.dll: _CreateTransaction: Creates a new transaction object_ _CreateFileTransactedA: with GENERIC_READ_WRITE access._ 2. The file is overwritten with the decrypted payload: _WriteFile: On the transacted file handle._ [3. Load the file to a memory section (more about this method is covered here):](https://www.ired.team/offensive-security/code-injection-process-injection/ntcreatesection-+-ntmapviewofsection-code-injection) _NtCreateSection: with the SEC_IMAGE section attribute._ _NtMapViewOfSection: Mapping the file view in the created section which_ validates the PE header and splits the section, but doesn’t build the import address table and set section permissions. 4. Set the right section permissions and resolve the imports of the DLL: Fixing section permissions using VirtualProtect calls. Building the DLL’s import address table with LoadLibrary and GetProcAddress calls. 5. Execute the DEPLOYLOG payload entry point followed by the SvcMain. ### DEPLOYLOG: The Winnti Rootkit Deployment and A Usermode Agent DEPLOYLOG (dbghelp.dll) is a 64 bit DLL, with two purposes: The first one is responsible for extracting and executing the attackers’ rootkit, dubbed WINNKIT, from the CLFS log file. After a successful deployment of the WINNKIT rootkit, DEPLOYLOG switches to its second task, which is communicating both with the remote C2 and the kernel-level rootkit. ----- It s noteworthy to mention that to evade detection, the attackers deployed DEPLOYLOG as _dbghelp.dll, a generic, widely used name leveraged to masquerade as a legitimate file at the_ same location as PRIVATELOG (C:\Windows\System32\WindowsPowerShell\v1.0). **DEPLOYLOG Initialization** Once DEPLOYLOG is executed, it starts with a sleep of 7777 milliseconds: _Figure #: Sleep_ _before the main method_ Afterward, it tries to acquire a handle to the earlier HVID_ event, and If it doesn’t exist it creates it. Then, it initializes the communication channel with the future deployed rootkit: First, it tries to acquire a handle to the Beep device object: \\? _\GLOBALROOT\Device\Beep._ If it fails, it tries to do the same for \\?\GLOBALROOT\Device\Null. To test if the rootkit [was deployed in the past and is running, DEPLOYLOG tries to send the IOCTL 15E030 to](https://en.wikipedia.org/wiki/Ioctl) the acquired device handle: ----- _DEPLOYLOG gets handles to device objects and sends an IOCTL_ **WINNKIT Deployment** Upon succeeding the earlier steps, DEPLOYLOG extracts the rootkit from the CLFS log file, decrypts its content, then stops the _[amdk8 service. This service is the AMD K8 processor](http://revertservice.com/7/amdk8/)_ kernel driver service. Aiming for this specific service can tell something about the Winnti modus operandi, indicating they aim only for AMD-related machines to be infected, which could also indicate having a prior knowledge of the victim's infrastructure. Then, DEPLOYLOG decrypts the string SystemRoot\System32\drivers\bqDsp.sys and changes the amdk8 service configuration to point to this path: ----- _Changing amdk8 service configuration to execute WINNKIT_ Next, DEPLOYLOG writes the bqDsp.sys rootkit driver from the CLFS log file to the _C:\WINDOWS\system32\drivers directory and starts the service again, this time to execute its_ malicious payload. By doing so, DEPLOYLOG finishes deploying the rootkit. To cover its tracks, DEPLOYLOG will then stop the service, restore its previous configuration to point to the _amdk8.sys driver, and finally delete WINNKIT:_ ----- _Sending WINNKIT the IOCTL 0x8000C004 using Pipe2PortCtrl_ **DEPLOYLOG as a User-Mode Agent** Once deployed, DEPLOYLOG turns to its second mission, effectively acting as a user-mode agent whose purpose is to bridge the newly deployed rootkit and the remote C2. The DLL will start communicating with the C2 servers which will send data that will be intercepted by the driver, as will be explained in the next section discussing WINNKIT. Using this agent, the attackers will load new modules, pop a CMD shell, drop MFSDLL.exe for credential grabbing and more: _DEPLOYLOG loaded by svchost.exe as seen in the Cybereason XDR Platform_ ----- ### Behold WINNKIT, The Evasive Winnti Rootkit The final payload deployed by Winnti is also the most evasive and sophisticated: a driver acting [as a rootkit, dubbed WINNKIT. WINNKIT’s previous version was researched in the past, and its](https://exatrack.com/public/winnti_EN.pdf) 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 network card. The almost zero detection rate in VirusTotal, together with the compilation timestamp from 2019, illustrates just how evasive this rootkit really is, staying in the shadows for 3 years: _Low detection rate in VirusTotal_ ----- _The_ _rootkit’s compilation timestamp_ WINNKIT contains an expired BenQ digital signature, which is leveraged to bypass the Driver Signature Enforcement (DSE) mechanism that requires drivers to be properly signed with digital signatures in order to be loaded successfully. This mechanism was first introduced in Windows Vista 64-bit, and is affected for all versions of Windows since then: _Revoked rootkit certificate and file version_ _information as seen in VirusTotal_ After successfully loading, WINNKIT hooks network communication, and operates based on custom commands that are being sent from the aforementioned user-mode agent, DEPLOYLOG. [At the beginning of its execution, the driver validates the NDIS version, making sure the system](https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-drivers) is Windows Vista or above. By using the NDIS API, it communicates directly with the network card, skipping higher level communication protocols: ----- _WINNKIT’s communication with the network card_ After establishing a connection with the network card, the rootkit tries to open the event _\\BaseNamedObjects\\{75F09225-CD50-460B-BF90-5743B8404D73}. In case it fails, it creates_ this event, and then hooks the \\Device\\Null device. Hooking this device is somehow risky, as this device is often being targeted by modern rootkit, thus making it relatively exposed to detection. Nevertheless, it enabled the authors to stay undetected for years. Using the above mentioned mechanisms enables WINNKIT a mean of communication with the user mode agent: ----- _WINNKIT event creation_ _WINNKIT hooks the \\Device\\Null device object_ ----- _The switch case that handling different commands_ A summary of the communication flow of DEPLOYLOG and WINNKIT, can be seen in the following diagram: ----- _Rootkit high level operation diagram_ Below are the functionality we believe that each code represents, according to our findings and previous conducted research: **Command** **Operation** 0x100 Hide driver 0x200 Determine version 0x300 Access IRQL shared data 0x400 Map and allocate buffer ----- 0x500 Map a buffer 0x800 Clean up ### Winnti Auxiliary Plugins Winnti used reflective loading injection in order to evade detection. The malicious modules are reflectively injected into the legitimate svchost processes. The following modules were detected [by Cybereason and seem consistent with previously reported Winnti plugins:](https://securelist.com/winnti-1-0-technical-analysis/37002/) **Cmp2.o: The plugin's purpose is to provide access to the system command line and** appears to be a variant of the Winnti "CmdPlus" plugin. **Fmg2.o: This plugin is responsible for listing and modifying files on the targeted machine** and appears to be the Winnti "ListFileManager" module. **Srv2.o: The purpose of the plugin is to display information about system services and is** assessed to be the Winnti “ListService” plugin. **Sck2.o: The purpose of the plugin is to transfer data over the network using a SOCKS5** proxy server and is assessed to be the “Socks5Client” plugin. **Prc2.o: This plugin can list or kill running processes on the targeted machine.** **Trs2.o: This plugin was also used for data transfer via Socks5 proxy.** **Cme2.o: The purpose of this plugin is to enable Remote Desktop access to Winnti:** _Example: svchost process that loaded sck2.o and trs2.o modules reflectively, as seen in the_ _Cybereason XDR Platform_ ## Conclusions ----- In part two of the research, we provided a deep dive into the Winnti malware arsenal that was observed by the Cybereason IR and Nocturnus teams. Our analysis provides a unique and holistic view of Winnti operational aspects, capabilities and modus operandi. While some of the tools mentioned in the research were previously reported on, some tools such as DEPLOYLOG were previously undocumented and first analyzed in this report. In addition, our analysis provides further insights regarding some of the known Winnti tools. Perhaps one of the most interesting things to notice is the elaborate and multi-phased infection chain Winnti employed. The malware authors chose to break the infection chain into multiple interdependent phases, where each phase relies on the previous one in order to execute correctly. This demonstrates the thought and effort that was put into both the malware and operational security considerations, making it almost impossible to analyze unless all pieces of the puzzle are assembled in the correct order. Furthermore, the rare abuse of the Windows’ own CLFS logging system and NTFS manipulations provided the attackers with extra stealth and the ability to remain undetected for years. We hope that this report helps to shed light on Winnti operations, tools and techniques, and that it will assist to expose further intrusions. ## Acknowledgments This research has not been possible without the tireless effort, analysis, attention to details and contribution of the Cybereason Incident Response team. Special thanks and appreciation goes to Matt Hart, Yusuke Shimizu, Niamh O’Connor, Jim Hung, and Omer Yampel. ## Indicators of Compromise _LOOKING FOR THE IOCs? CLICK ON THE CHATBOT DISPLAYED IN LOWER-RIGHT OF_ _YOUR SCREEN FOR ACCESS. Due to the sensitive nature of the attack, not all IOCs_ _observed by Cybereason can be shared in our public report. Please contact us for more_ _information._ ## MITRE ATT&CK BREAKDOWN **Reconnaissance** **Initial** **Access** **Execution** **Persistence** **Privilege** **Escalation** **Defense** **Evasion** ----- Gather Victim Identity Information: Credentials Gather Victim [Network](https://attack.mitre.org/techniques/T1590/) Information Exploit PublicFacing Application Supply Chain Compromise Scheduled Task/Job Inter-process communication Exploitation for Client Execution Command and Scripting Interpreter: Windows Command Shell Command and Scripting Interpreter: Visual Basic Server Software Component: Web Shell Scheduled Task/Job: Scheduled Task Valid Accounts: Domain Accounts Create or Modify System Process: Windows Service Hijack Execution [Flow: DLL](https://attack.mitre.org/techniques/T1574/002/) SideLoading Process Injection: [Dynamic-](https://attack.mitre.org/techniques/T1055/001/) link Library Injection Scheduled Task/Job: Scheduled Task Valid Accounts: Domain Accounts Valid Accounts: Local Accounts Hijack Execution Flow: DLL Side-Loading [Rootkit](https://attack.mitre.org/techniques/T1014/) Masquerading: Match [Legitimate](https://attack.mitre.org/techniques/T1036/005/) Name or Location Process Injection: [Dynamic-link](https://attack.mitre.org/techniques/T1055/001/) Library Injection Reflective Code Loading Signed Binary Proxy Execution: Rundll32 Valid Accounts: Domain Accounts Valid Accounts: Local Accounts [Native API](https://attack.mitre.org/techniques/T1106/) Valid Accounts: Local Accounts ----- **Credential** **Access** OS [Credential](https://attack.mitre.org/techniques/T1003/) Dumping **Discovery** **Lateral** **movement** System Network Configuration Discovery Remote [System](https://attack.mitre.org/techniques/T1018/) Discovery Password [Policy](https://attack.mitre.org/techniques/T1201/) Discovery Permission [Groups](https://attack.mitre.org/techniques/T1069/) Discovery Network Share Discovery System [Service](https://attack.mitre.org/techniques/T1007/) Discovery System Time Discovery System Network Connections Discovery Account Discovery **Collection** **Exfiltration** **Command** **and** **Control** Exploitation of [Remote](https://attack.mitre.org/techniques/T1210/) Services Remote Services: [Remote](https://attack.mitre.org/techniques/T1021/001/) Desktop Protocol Archive Collected Data: Archive via Utility Automated Collection Automated Exfiltration Application Layer [Protocol:](https://attack.mitre.org/techniques/T1071/001/) Web Protocols [Proxy](https://attack.mitre.org/techniques/T1090/) ----- System [Owner/User](https://attack.mitre.org/techniques/T1033/) Discovery System [Information](https://attack.mitre.org/techniques/T1082/) Discovery Process Discovery ## About the Researchers: **Chen Erlich** Chen has almost a decade of experience in Threat Intelligence & Research, Incident Response and Threat Hunting. Before joining Cybereason, Chen spent three years dissecting APTs, investigating underground cybercriminal groups and discovering security vulnerabilities in known vendors. Previously, he served as a Security Researcher in the IDF. Fusao Tanida Fusao spent over 10 years in the security industry. Before joining, he worked as a mobile malware researcher and a developer at the security vendor and then worked at the global mobile phone manufacturer for the development of AntiVirus, VPN client on their Android mobile phone ----- Fusao joined Cybereason in 2019 and was previously the Senior Security Analyst at the Advanced Services Team in Cybereason Japan where delivered various security professional services, Incident Response, consultation and triage malware activity alerts in SOC. Ofir Ozer Ofir is a Incident Response Engineer at Cybereason who has a keen interest in Windows Internals, reverse engineering, memory analysis and network anomalies. He has years of experience in Cyber Security, focusing on Malware Research, Incident Response and Threat Hunting. Ofir started his career as a Security Researcher in the IDF and then became a malware researcher focusing on Banking Trojans. Akihiro Tomita Akihiro is the Senior Manager of Global Security Practice, leading Incident Response team in the APAC region and Japan. Akihiro has led a substantial number of large-scale Incident Response, Digital Forensics and Compromise Assessment engagements during recent years. Akihiro was also a former Team lead of Advanced Security Services team responsible for managing, developing, delivering a variety of professional services including Proactive threat hunting, Security Posture Assessment, Advanced security training and consulting services at Cybereason. ----- Niv Yona Niv, IR Practice Director, leads Cybereason's incident response practice in the EMEA region. Niv began his career a decade ago in the Israeli Air Force as a team leader in the security operations center, where he specialized in incident response, forensics, and malware analysis. In former roles at Cybereason, he focused on threat research that directly enhances product detections and the Cybereason threat hunting playbook, as well as the development of new strategic services and offerings. Daniel Frank With a decade in malware research, Daniel uses his expertise with malware analysis and reverse engineering to understand APT activity and commodity cybercrime attackers. Daniel has previously shared research at RSA Conference, the Microsoft Digital Crimes Consortium, and Rootcon. ASSAF DAHAN, HEAD OF THREAT RESEARCH Assaf has over 15 years in the InfoSec industry. He started his career in the Israeli Military 8200 Cybersecurity unit where he developed extensive experience in offensive security. Later in his career he led Red Teams, developed penetration testing methodologies, and specialized in malware analysis and reverse engineering ----- ### Operation CuckooBees Indicators of Compromise (IOCs) **Hashes** BB93AE0FEE817FE56C31BDC997F3F7D57A48C187 - STASHLOG 4D1B8791D0715FE316B43FC95BDC335CB31A82CA - STASHLOG 2D336978AF261E07B1ECFAF65DC903B239E287A4 - STASHLOG F2D04FE529E2D8DAB96242305255CFB84CE81E9C - STASHLOG F8D46895E738254238473D650D99BDC92C34EE44 - SPARKLOG 9267FE0BB6D367FC9186E89EA65B13BAA7418D87 - PRIVATELOG A009A0F5A385683AEA74299CBE6D5429C609F2D2 - PRIVATELOG 1316F715D228AE6CC1FBA913C6CC309861F82E14 - PRIVATELOG 1275894D8231FE25DB56598DDCF869F88DF5AD8D - WINNKIT 9139C89B2B625E2CEEE2CBF72AEF6C5104707A26 - WINNKIT 082DBCA2C3CA5C5410DE9951A5C681F0C42235C8 - WINNKIT **File Names & Paths** C:\Windows\temp\bc.bat C:\Windows\AppPatch\Custom\Custom64\cc.bat C:\Windows\temp\cc.log C:\Windows\AppPatch\Custom\Custom64\log.dat C:\Windows\Branding\Basebrd\x64.tlb C:\Windows\Branding\Basebrd\language.dll C:\Windows\System32\mscuplt.dll C:\Windows\System32\rpcutl.dll C:\Windows\System32\dot3utl.dll C:\Windows\System32\iumatl.dll C:\Windows\System32\Nlsutl.dll C:\Windows\System32\WindowsPowerShell\v1.0\dbghelp.dll C:\Windows\System32\drivers\bqDsp.sys C:\Windows\apppatch\en-us\MFSDLL.exe C:\Windows\System32\spool\drivers\x64\3\prntvpt.dll C:\Windows\System32\WindowsPowerShell\v1.0\wlbsctrl.dll C:\Windows\assembly\gac_msil\dfsvc\foserv.exe C:\Windows\assembly\temp\foserv.exe C:\Windows\apppatch\custom\custom64\shiver.exe C:\Windows\apppatch\custom\custom64\spark.exe mktzx64.dll **Winnti Malware Modules Names** Cmp2.o Fmg2.o Srv2.o ----- Sck2.o Prc2.o Trs2.o Cme2.o **Events** \BaseNamedObjects\{75F09225-CD50-460B-BF90-5743B8404D73} \BaseNamedObjects\{7D0DF5FC-3991-4047-921F-32308B1A0459} \BaseNamedObjects\{B73AB0F4-A1D0-4406-9066-41E00BA78E9F} Global\APCI# Global\HVID_ **Named Pipes** Pipe2PortCtrl **Scheduled Task Name** test About the Author **Cybereason Nocturnus** The Cybereason Nocturnus Team has brought the world’s brightest minds from the military, government intelligence, and enterprise security to uncover emerging threats across the globe. They specialize in analyzing new attack methodologies, reverse-engineering malware, and exposing unknown system vulnerabilities. The Cybereason Nocturnus Team was the first to release a vaccination for the 2017 NotPetya and Bad Rabbit cyberattacks. [All Posts by Cybereason Nocturnus](https://www.cybereason.com/blog/authors/cybereason-nocturnus) -----