Malware
NetDooka Framework Distributed via PrivateLoader Malware as Part of Pay-Per-Install Service
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.
Save to Folio
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.
Attack overview
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.
Loader analysis
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 |
Blocks antivirus vendor domains, install driver and delete loader |
<No ARG> |
Downloads the dropper component, executes itself using the “embedded” and “correct” arguments and creates a scheduled task for downloaded NetDookaDropper |
Table 1. Command-line arguments and their functions
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.
The loader then creates a working directory in the %ProgramFiles% such as "ReservHardwareUpdater" or "ExMultimediaStorage" (please note that the directory name could be in different samples) to keep a copy of itself and other files, such as the next stage payload in there. After that, the malware executes the copy of itself with an embedded/delected argument.
In some variants, the loader downloads the next stage's payload twice: once when the malware runs with no parameters (this binary never runs such as "rsvr_updldr.exe") and once when the loaded executes a copy of itself with an embedded/deletced parameter (this later on binary executes via scheduled task).
The “embedded” argument is responsible for downloading the dropper component and saving it as “%ProgramFiles%\ReservHardwareUpdater\reloadbitex.exe”.
The loader component executes itself again using the “correct” argument. Once this is done, it blocks antivirus vendor domains by modifying the hosts file, redirecting their domains to “0.0.0.0” address and 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 Files\SolidTechnology\protdrv.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.
At the end, the loader creates the following scheduled task for the downloaded dropper:
Dropper analysis
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 “\x11\x42\x91\x50\x7F\xB4\x6C\xAA\x75\x5E\x8D”) 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.
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.
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.
Driver analysis
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.”
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.
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.
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.
RAT analysis
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 18 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”.
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 23.
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 24 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 25 shows the commands supported by the malware while the code snippet in Figure 26 demonstrates how the malware performs these commands.
Conclusion
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.
Indicators of Compromise (IOCs)
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