NetDooka Framework Distributed via PrivateLoader Malware as Part…

NetDooka Framework Distributed via PrivateLoader Malware as Part of Pay-Per-Install Service

Malware

This report focuses on the components and infection chain ⁠of the NetDooka framework. Its scope ranges from the release of the first payload up until the release of the final RAT that is protected by a kernel driver.

By: Aliakbar Zahravi, Leandro Froes

May 05, 2022

Read time: ( words)

We recently encountered a fairly sophisticated malware framework that we named NetDooka after the names of some of its components. The framework is distributed via a pay-per-install (PPI) service and contains multiple parts, including a loader, a dropper, a protection driver, and a full-featured remote access trojan (RAT) that implements its own network communication protocol. During our analysis, we discovered that NetDooka was being spread via the PrivateLoader malware which, once installed, starts the whole infection chain.

As previously described by Intel471, the PrivateLoader malware is a downloader responsible for downloading and installing multiple malware into the infected system as part of the PPI service. Due to the way the PPI service works, the exact payloads that would be installed might differ depending on the malware version. Some of the known malware families that are reportedly being distributed via PPI services include SmokeLoader, RedLine, and Anubis.

This report focuses on the components and infection chain ⁠of the NetDooka framework. Its scope ranges from the release of the first payload, which drops a loader that creates a new virtual desktop to execute an antivirus software uninstaller and interact with it by emulating the mouse and pointer position — a necessary step to complete the uninstallation process and prepare the environment for executing other components — up until the release of the final RAT that is protected by a kernel driver.

However, while we describe all the different features we found, NetDooka’s features might still vary depending on the malware version since it is still in its development phase.

Figure 1. Infection chain of the attack

The infection starts when a user inadvertently downloads PrivateLoader, usually through pirated software downloads (as mentioned in the Intel471 report), followed by the installation of the first NetDooka malware, a dropper component that is responsible for decrypting and executing the loader component.

The loader then performs certain checks to ensure that it is not running in a virtual environment, after which it downloads another malware from the remote server. It might also install a kernel driver for future use.

The downloaded malware is another dropper component that is executed by the loader. This dropper is responsible for decrypting and executing the final payload, a full-featured RAT containing multiple capabilities such as starting a remote shell, grabbing browser data, taking screenshots, and gathering system information. It might also start the installed kernel driver component to protect the dropped payload.

Upon execution, the loader will deobfuscate strings, such as the command-and-control (C&C) server address, and check for the command-line arguments that were passed. The malware accepts multiple arguments that indicate what action should be taken.

Argument	Function
001	Uninstalls Avira programs
004	Uninstalls Viper programs
006	Uninstalls Total 360 programs
007	Uninstalls ESET programs
008	Uninstalls GData programs
embedded	Downloads the dropper component and renames it to reloadbitex.exe
correct	Executes the dropper component and blocks antivirus vendor domains
<No ARG>	Downloads the dropper component and executes itself using the “embedded” and “correct” arguments

Table 1. Command-line arguments and their functions

Figure 3. NetDookaLoader argument’s check

If no parameter is passed to the loader, it executes a function called “DetectAV()” that queries the registry to automatically identify the antivirus products available in order to uninstall them. The malware does this by creating a new virtual desktop using CreateDesktopA, which is used as a workspace for launching the proper binary uninstaller program. This is accomplished through the use of CreateProcessA with the “create_no_window” flag, as well as through the emulation of human interactions such as controlling the mouse to complete the uninstallation process. Each antivirus uninstaller function has its own removal technique based on uninstallation process. Figure 4 shows an example of the GData antivirus removal.

Figure 4. Uninstalling an antivirus program

The loader then uses the bitsadmin.exe Windows utility to download the dropper component from its C&C server and save it as “C:Program FilesReservHardwareUpdaterrsvr_updldr.exe”.

Figure 5. NetDookaLoader downloading the next stage of the attack via bitsadmin.exe

Figure 6. Self-execution with “embedded” argument

The “embedded” argument is responsible for downloading the dropper component and saving it as “%ProgramFiles%ReservHardwareUpdaterreloadbitex.exe”.

The loader component executes itself again using the “correct” argument. Once this is done, it executes the downloaded dropper, blocks antivirus vendor domains by modifying the hosts file and redirecting their domains to “0.0.0.0” address. Finally, it deletes itself using the following command:

In some variants of the malware, the loader installs a driver to act as a kernel-mode protection for the final payload (RAT component). It accomplishes this by registering as a mini-filter driver and setting callback functions to protect the malware against file deletion and process termination.

The driver binary is Base64-encoded within the loader and, once decoded, has its content written to the “C:Program FilesSolidTechnologyprotdrv.sys” file. Although the loader creates a service to install the driver, it does not start it. Instead, the driver start task is performed by the dropper component.

We discovered two different dropper components involved in the NetDooka attack chain: One is installed by the PrivateLoader that drops the NetDooka loader, while the other one drops the final RAT payload.

The dropper component is a small .NET binary responsible for decrypting and executing a payload it has embedded. The malware starts by reading its own file content and looking for a specific byte sequence (in the sample we analyzed, this was “x11x42x91x50x7FxB4x6CxAAx75x5Ex8D”) to get the bytes next to it.

The payload decryption is achieved by performing an XOR operation in the decrypted payload that uses a single-byte key and subtracts the index value from the final value for each decryption loop iteration. The key is resolved by creating a prime number list of a specific size and iterating through it. For each iteration, the SHA-256 hash of the current list element is generated and the first byte of the hash result is then added to a single-byte variable, with the final sum being the XOR key.

Figure 9. The decryption routine used by NetDookaDropper

Once decrypted, the payload content is written to a file in the %Temp% directory and then executed via a new process. Note that both the location and the file name might be different depending on the malware version.

Figure 10. The decrypted payload being executed

Although the malware has multiple versions exhibiting some differences in behavior such as the XOR key and byte sequence being searched, the dropper’s goal is still the same for all NetDooka’s versions we found: Execute an embedded payload within it. To automate the dropped payload extraction, we developed a Python script that can be downloaded here.

As mentioned in the loader analysis section, some versions of the dropper component are responsible for starting the driver component service. It’s important to mention that the dropper version that contains the driver start step (performed before the final payload decryption and execution) is the one containing the final payload.

Figure 11. The dropper starting the driver component

The driver component acts as a kernel-level protection for the RAT component. It does this by attempting to prevent the file deletion and process termination of the RAT component. The driver registers itself as a mini-filter driver to intercept I/O requests to the file system and set process callback functions to protect the RAT process.

During our analysis, we noticed that the driver based its process protection implementation in the Microsoft driver example implementation and its file deletion protection in an open source project named “Prevent_File_Deletion.”

Figure 12. General view of the driver features

The driver registers as a mini-filter driver and starts it by using both the FltRegisterFilter and FltStartFiltering functions. File systems are typical targets for I/O operations in order to access files. A file system filter is a mechanism that a driver can use to intercept calls destined to the file system. A file system mini-filter is a model created to replace the Windows legacy file system filter mechanism, possessing the advantage of being easier to write — making it the preferred method of developing file system-filtering drivers.

When a mini-filter driver is registered, it can set callback functions to be executed before (PreOperation) and after (PostOperation) I/O requests. For the file deletion protection, the malware registers a PreOperation callback function during the filter registration to intercept I/O requests of specific types to the file system. In this case, the malware intercepts file deletion operations.

Once a file deletion operation is requested, the callback function is called, and the driver checks if the destination file has the name “ougdwieue.exe” (name of the final RAT payload). If so, it changes the permissions of the request to prevent the target file from being deleted.

Figure 13. RAT file name being checked and access being denied

The process protection is achieved by setting a process notification callback routine via the PsSetCreateProcessNotifyRoutine function, which would be called every time a new process is created. When the callback is executed, the malware looks for the string “ougdwieue.exe” in the process command line to determine whether or not the process is the expected target.

Figure 14. The process command line being checked

The driver also sets another callback routine via ObRegisterCallback to check for process operations being performed that involve a process handle creation or duplication.

With these two callbacks in place when a process is created, the driver can check if the process being created is in fact the RAT process and the operation being performed is either a process handle creation or duplication. If so, the driver changes the access permission to avoid applications that try to obtain a handle to the target process and terminate it.

Figure 15. Process creation callback routine.

Figure 16. Access to the process handle being modified

The final payload is a RAT that accepts commands from a remote server to execute a variety of functions such as executing shell commands, performing distributed denial-of-service (DDoS) attacks, downloading and executing files, logging keystrokes on the infected machine, and performing remote desktop operations. Figure 17 shows the list of its functions.

Upon execution, the malware employs various system checks to detect and avoid analysis environments.

The malware creates a mutex named “3f0d73e2-4b8e-4539-90fd-812330bb39c8” to mark its presence on the system. In case it finds the same mutex in the system, it exits.

Before C&C communication, NetDooka generates a 16-byte random session and stores it in a file named “config.cfg”.

Figure 19. Initializing and configuring the C&C server

It then initializes its network communication components and contacts its C&C server to register the victims and retrieve commands.

NetDookaRAT uses a custom protocol to communicate with the C&C server using the format shown in Figure 22.

Figure 22. The packet structure used in C&C communications

Each response splits into the header and data stream. The header stream contains the request type, the size and options of the data to be sent while the data stream contains the return value of the specific function. Table 2 shows a list of type values and their corresponding functions.

Type in decimal	Type in hex	Function
400	0x190	Exfiltrate system information
1000	0x3E8	Send session ID
10	0x0A	Send message
8	0x08	Reverse shell
16	0x10	DDoS attack
19	0x13	Send file
5	0x05	Download file
20	0x14	Copy browser data
9	0x09	Copy browser data
18	0x12	Start HVNC
15	0x0F	Send log
14	0x0E	Microphone capture
17	0x11	Start virtual network computing (VNC)
13	0x0D	Capture webcam

Table 2. The type values and their corresponding functions

The code snippets in Figure 23 demonstrate how the malware constructs and sends the request shown in Table 2.

The malware then starts to listen for incoming TCP connections to receive commands. It then parses the received commands to execute them on the infected machine. Figure 24 shows the commands supported by the malware while the code snippet in Figure 25 demonstrates how the malware performs these commands.

Figure 24. RAT commands and capabilities

Figure 25. Code snippet of the RAT commands

PPI malware services allow malware creators to easily deploy their payloads. The use of a malicious driver creates a large attack surface for attackers to exploit, while also allowing them to take advantage of approaches such as protecting processes and files, bypassing antivirus programs, and hiding the malware or its network communications from the system, among others. Furthermore, with the RAT payload properly installed, malicious actors can perform actions such as stealing several critical information from the infected systems, gaining remote control access to the system, and creating botnet networks. Finally, NetDooka’s capabilities allow it to act as an entry point for other malware.

A list of indicators in text format can be viewed here.

SHA-256	Detection name
PrivateLoader
4d94232ec587f991017ed134ea2635e85c883ca868b96e552f9b5ac5691cdaf5	Trojan.Win32.STOP.EL
Driver
81dbe7ff247d909dc3d6aef5b5894a153886955a9c9aaade6f0e9f47033dc2fb	Trojan.Win64.PROTDRIVE.A
93[.]115[.]21[.]45 IoCs
Dropper
28ad0bc330c7005637c6241ef5f267981c7b31561dc7d5d5a56e24423b63e642	TrojanSpy.MSIL.DOTCRYPT.B
50ab75a7c8685f9a87b5b9eb7927ccb7c069f42fb7427566628969acdf42b345	TrojanSpy.MSIL.DOTCRYPT.B
85e439e13bcd714b966c6f4cea0cedf513944ca13523c7b0c4448fdebc240be2	TrojanSpy.MSIL.DOTCRYPT.B
c64a551e5b0f74efcce154e97e1246d342b13477c80ca84f99c78db5bfeb85ef	TrojanSpy.MSIL.DOTCRYPT.B
8fa89e4be15b11f42e887f1a1cad49e8c9c0c724ae56eb012ac5e529edc8b15c	TrojanSpy.MSIL.DOTCRYPT.B
531f6cb76127ead379d0315a7ef1a3fc61d8fff1582aa6e4f77cc73259b3e1f2	TrojanSpy.MSIL.DOTCRYPT.B
44babb2843da68977682a74675c8375da235c75618445292990380dbc2ac23af	TrojanSpy.MSIL.DOTCRYPT.B
64be1332d1bf602aaf709d30475c3d117f715d030f1c38dee4e7afa6fa0a8523	TrojanSpy.MSIL.DOTCRYPT.B
91791f8c459f32dc9bf6ec9f7ee157e322b252bc74b1142705dcc74fe8eced7e	TrojanSpy.MSIL.DOTCRYPT.B
a49769b8c1d28b5bb5498db87098ee9c67a94d79e10307b67fe6a870c228d402	TrojanSpy.MSIL.DOTCRYPT.B
43dcf8eea02b7286ba481ca84ec1b4d9299ba5db293177ff0a28231b36600a22	TrojanSpy.MSIL.DOTSPY.A
Loader
d20576f0bd39f979759cde5fb08343c3f22ff929a71c3806e8dcf0c70e0f308b	Trojan.MSIL.DNRAT.A
76ed2ef41db9ec357168cd38daeff1079458af868a037251d3fec36de1b72086	Trojan.MSIL.DNRAT.B
40ee0bd60bcb6f015ad19d1099b3749ca9958dd5c619a9483332e95caee42a06	Trojan.MSIL.DNRAT.B
1cc21e3bbfc910ff2ceb8e63641582bdcca3e479029aa425c55aa346830c6c72	Trojan.MSIL.KILLAV.AF
2e37495379eb1a4dfae883d1e669e489877ed73f50ae26d43b5c91d6c7cb5792	Trojan.MSIL.KILLAV.AF
8ed34bfc102f8217dcd6e6bdae2b9d4ee0f3ab951d44255e1e300dc2a38b219e	Trojan.MSIL.KILLAV.AF
5c14a72a6b73b422cafc2596c13897937013fd335eca4299e63d01adee727d54	Trojan.MSIL.KILLAV.AF
bfc99c3f76d00c56149efcf75fd73497ec62b1ed53e12d428cf253525f8be8d0	Trojan.MSIL.KILLAV.AF
ed98187a0895818dfa6b583463b8a6d13ebc709d6dd219b18f789e40a596e40e	Trojan.MSIL.KILLAV.AF
94fb2969eae7cce75c44c667332dacace155369911b425c50476d90528651584	Trojan.MSIL.KILLAV.AF
07aec94afba94eb3b35ba5b2e74b37553c3c0fed4f6de1fbac61c20dae3f29d4	Trojan.MSIL.KILLAV.AG
RAT
62946b8134065b0dab11faf906539fcfcbd2b6a89397e7fb8e187dd2d47ab232	Backdoor.MSIL.DNRAT.A
73664c342b302e4879afeb7db4eeae5efc37942e877414a13902372d25c366c5	Backdoor.MSIL.DNRAT.A
ab7d39e34ad51bc3138fb4d0f7dedc4668be1d4b54a45c385e661869267ef685	Backdoor.MSIL.DNRAT.B
c54a492d086930eb4d9cd0233a2f5255743b6dde22a042f2a2800f2c8fe82ce8	Backdoor.MSIL.DNRAT.B
f53844fb1239792dac2e9a89913ef0ca68b7ffe9f7a9a202e3e729dbf90f9f70	Backdoor.MSIL.DNRAT.B
55247d144549642feba5489761e9f33a74fcb5923abd87619310039742e19431	Backdoor.MSIL.DNRAT.B
ed092406a12d68eac373b2ddb061153cb8abe38e168550f4f6106161f43dcafe	Backdoor.MSIL.DNRAT.C
ba563dfaf572aa5b981043af3f164a09f16a2cf445498d52b299d18bb37ce904	Trojan.MSIL.DNRAT.C
796df2ad288455a4047a503b671d5970788b15328ce15b512c5e3403b0c39a61	Trojan.MSIL.DNRAT.C
89[.]38[.]131[.]151 IoCs
Dropper
60bf7b23526f36710f4ef589273d92cc21d45a996c09af9a4be52368c3233af6	TrojanSpy.MSIL.DOTCRYPT.A
557f35cfdd1606d53d6a3ae8d9f86013b4953c5e1c6fabc2faa57d528c895694	TrojanSpy.MSIL.DOTCRYPT.A
Loader
cdf3aaa9134dc1c5523902afed3ff029574f9c13bc7105c77df70d20c9312288	Trojan.MSIL.VINDOR.A
85d3b0b00759d7b2c7810c65cdae7fcfe46f3a9aec9892c11156d61c99c2d92e	Trojan.Win32.VINDOR.A
RAT
5ec57873c7a4829f75472146d59eb8e44f926d9a0df8d4af51ca21c8cd80bace	Backdoor.MSIL.DNRAT.A

Domains and URLs

hxxp://212.193.30[.]21/

hxxp://93.115.21[.]45

hxxp://89[.]38[.]131[.]155

hxxp://data-file-data-18[.]com

hxxp://file-coin-coin-10[.]com

NetDooka Framework Distributed via PrivateLoader Malware as Part of Pay-Per-Install Service

Table 1. Command-line arguments and their functions

Table 2. The type values and their corresponding functions

Domains and URLs

VMWARE

Helping Public Sector Organisations Define Cloud Strategy

How to change the VLAN ID of the Service Console in ESX from the command line/console

Cisco UCS and Vmware Interfaces (Vnics) HA Design Considerations

Troubleshooting network and TCP/UDP port connectivity issues on ESX/ESXi(2020669)

vSphere Client Parameters

Configuration Templates

CUE Licenses

Trouble shooting Unity Express with Call Manager Integeration & Operational Issues

CME Configuration Example: SIP Trunks to Viatalk and VoIP.ms

SIP Phone registration – CME Configuration

CUE Voicemail + VPIM networking (CUE to unity)

Related Post

VMWARE

Configuration Templates