Neurevt botnet: new generation


He Xu

Fortinet, Canada
Editor: Helen Martin


Neurevt first appeared over a year ago – its many components cover a large number of the most popular malicious functionalities, including downloading malware, DDoS attacks and website sniffing. He Xu discusses the major changes that have been introduced into the most recent generation of the botnet.

The infamous Neurevt (a.k.a. Betabot) botnet first appeared in March 2013. It has many components, covering a large number of the most popular malicious functionalities – such as downloading malware, DDoS attacks and website sniffing. In this article, we discuss the major changes that have been introduced into the latest generation of the botnet.

Single bot splits into loader and module

The latest version of Neurevt doesn’t execute its malicious code directly, but instead acts as a normal loader (Figure 1). It finds the encrypted block (shown in red in Figure 1) by looking out for the 0x10 length signature in the block’s header. Then it extracts the module binary from the block and places it in a newly allocated section of memory (the block structure detail is listed below as enc_block). It then replaces the module’s default config block with its own local config block (shown in blue in Figure 1) – the block size may differ a little between loader and module.

typedef struct enc_block {
 CHAR Signature[0x10];
 DWORD key;
 DWORD EncSize;
   DWORD DecSize;
CHAR Block[*]
The bot acts as a normal loader.

Figure 1. The bot acts as a normal loader.

Next, the loader updates the values of the two DWORD bitsmarks in the replaced config block, changing them from the default 0 to 1 (see Figure 2), and loads the config block according to the module’s PE structure. Finally, the loader calls the entry point of the module.

Bitsmark update.

Figure 2. Bitsmark update.

Abnormal PE structure

The module cannot run independently because it requires the loader’s initialization. In addition, its structure differs from the standard PE structure. Let’s look at the section table (Figure 3).

Special section table of module.

Figure 3. Special section table of module.

The raw sizes are all too large to run independently. As a result, the loader and module are inseparable. This also means that the embedded binary can remain stable for a long time without needing to change anything. This is much easier for maintenance.

Special injection mechanism

The previous variant’s preferred injection target was C:\windows\system32\wuauclt.exe, but the latest version injects its main code into a newly created process, C:\windows\explorer.exe.

However, it does not modify the entry point code of the compromised process or create a new remote thread starting from its malicious code. Instead, it modifies ntdll.dll’s export function ZwContinue (Figure 5), and then jumps to a tiny section of newly allocated memory to recover the API’s original code (Figure 4) and create a new thread which executes the malware’s major code.

Original code of ZwContinue.

Figure 4. Original code of ZwContinue.

Modified code of ZwContinue.

Figure 5. Modified code of ZwContinue.

Copy API code and backup API

To avoid deep analysis and tracking by security researchers, the bot copies various API codes to itself – in particular those that start with ‘Zw’ and which are mostly ntdll.dll export functions. This means that most API breakpoints don’t work for Neurevt.

Let’s look at an example for calling the ZwResumeThread API. The default API code is shown in Figure 6.

Default code of ZwResumeThread.

Figure 6. Default code of ZwResumeThread.

After the bot’s modification, all of the code is copied to local memory, as shown in Figure 7.

Code is copied to local memory.

Figure 7. Code is copied to local memory.

Things are a little different because the bot merges the code of two APIs together locally. This could be used as a possible clue for indicating that a system has been infected by Neurevt. As a backup, the bot still supports normal API calls when the copy code mechanism fails.

New replication path and protection

Since the special ClsID directory name feature has become well known, the bot has stopped using it. It still replicates itself in the %COMMONPROGRAMFILES%\ directory, but the subsequent child directory is hard-coded in the binary, so different variants have different directory names. The following list shows several of the replication paths that we have observed. The filename is random on each replication attempt:

  • %COMMONPROGRAMFILES%\CreativeAudio\jnmhzdjtt.exe

  • %COMMONPROGRAMFILES%\nvv svc\rjmynangs.exe

  • %COMMONPROGRAMFILES%\Winsys\nrmhzdjtb.exe

  • %COMMONPROGRAMFILES%\WindowsUpdaterAgent0\jwvzdqgtr.exe

Without the protection of the special ClsID directory name, the bot adds an advanced inline hook feature in order to hide itself.

Random C&C link parameters

To make detection more difficult, the bot adds a random parameter to the end of its C&C link. It will randomly select one of the following parameters while communicating with the C&C server:


Our investigation suggests that these parameters are actually meaningless. The number values do not provide real information relating to the system. However, this information gives us another tip for identifying the latest generation of the malware.

Random send package structure

Let’s look at the last variant first. The earlier variant uses fixed parameter names in the post content (see Figure 8). The initial package uses ps0, ps1, cs1, cs2 and cs3 to carry local information to the C&C server. This makes it easy to detect according to these parameters.

Previous variant’s send package.

Figure 8. Previous variant’s send package.

The encryption for the ps1 value is RC4 and the key is taken from the initial config block. Figure 9 shows the sending package after decryption.

Ps1 block plain text.

Figure 9. Ps1 block plain text.

The cs1, cs2 and cs3 values are encrypted using a simple XOR encryption (see Figure 10). The DWORD keys are hard-coded in the bot’s code and should be the same among most variants: \x1D\xCC\xB9\xEA.

The cs1, cs2 and cs3 values use a simple XOR encryption.

Figure 10. The cs1, cs2 and cs3 values use a simple XOR encryption.

Now let’s get back to the latest generation, which makes detection significantly more difficult by changing most of the parameter names to random strings (Figure 11). The number of parameters has increased from five to eight – so it can carry more information.

Most parameter names are random strings.

Figure 11. Most parameter names are random strings.

There are still some small signs that could be used by a filter to detect the package – for example, starting from the fourth parameter, the name tail is always a number, and it increases by one each time.

The encryption has changed too, and can be categorized in two parts. The first (or the second) parameter whose value is not only numbers is added to a random key that will be combined with a hard-coded key as the final RC4 key to decrypt the third parameter (Figure 12) – which should be the same as ps1 in the previous variant.

Decryption of third parameter.

Figure 12. Decryption of third parameter.

The second part is for decryption of the name-tail-number-increasing parameters: the encryption is XOR with a fixed DWORD key \x22\xF0\x71\xC2 that has already changed from old variants.

XOR with fixed DWORD key.

Figure 13. XOR with fixed DWORD key.

So finally, we get the complete plain text of the sending package. Comparing this with Figure 10, the bot could collect two more pieces of information about the compromised system, such as CPU and video card information. We can see that the bot is executed under the VirtualBox system, so the C&C server could refuse its connection or never give a real response.

Received package improvement

The received package structure and algorithm has also been updated. First, the two-byte fixed signature at the start, \xD8\xFF, has been removed, so the total package could be treated as a random data block before decryption.

The current structure is as follows:

typedef struct recv_pack{
 DWORD HdrKey;
 DWORD BodyKey;
 CHAR Header[0x5C];
 CHAR Body[*]

The detailed Header structure is the same as before, as is the body. However, the key-generation mechanism has changed slightly – the bot will not use the hard-coded key directly, but uses a XOR db algorithm with db key ‘\xCB’ to decrypt the header. It uses another hard coded key combined with the second DWORD value and then uses a XOR db algorithm with db key ‘\x1F’ to decrypt the body.

Figure 14 shows the final decrypted pack.

Decrypted pack.

Figure 14. Decrypted pack.

As we have seen, the C&C server only uses the first block for executing specific commands. It spreads other malware using the .dwfile command with additional parameters. Our investigations show that the current variant is spreading the Andromeda and Dorkbot malware.

The block types vary according to the size list in the config header. Currently, the bot only uses the first four blocks, which is the same as the previous variant. The first block is for commands, the second is for the domain blacklist, the third is for the website sniffer, and the fourth block is for updating the configuration.

The bot could support 0x25 / 38d different commands and there is a trick: the bot does not save any command string locally, only a checksum list for comparing the calculated command string value. So unless we received the actual command, we would not know it is plain text.

The bot does not save any command string locally.

Figure 15. The bot does not save any command string locally.

Since we first saw Neurevt we have collected the following commands and their related indexes:

.dwfile0x05Download and run other malware
.update0x07Download and run its update binary
.botkill0x11Erase all local system information
.ddos0x12DDoS attack
.browser0x19Open Internet browser

Second block acts as DDoS attack

In the second block, the bot has changed the fake IP from the local to a real Internet IP – currently only that belonging to Google, so it likes a special DDoS.

DDoS function.

Figure 16. DDoS function.


With its newly designed random parameters, Neurevt’s communication with its C&C server is much safer than before. The modification for encrypting the sending and receiving of packages, could cause many vendors’ detections to fail. The compatible commands structure could prompt previous purchasers of the malware to update to the latest version and without too much adaptation. Needless to say, we will continue to track the activity of the Neurevt botnet.



Latest articles:

APT vs Internet service providers – a threat hunter's perspective

Organizations in the telecommunications sector are faced with a multitude of threats, ranging from targeted attacks to malicious actions attributable to the criminal or activist world. Telsy researcher Emanuele De Lucia reports what he observed in…

VB2019 paper: APT cases exploiting vulnerabilities in region‑specific software

Some APT attacks are carried out by exploiting vulnerabilities in region-specific software. Government agencies frequently use such localized software, and this tends to be the target of attackers. In Japan, there have been many cases where attacks…

Detection of vulnerabilities in web applications by validating parameter integrity and data flow graphs

Web application vulnerabilities are an important entry vector for threat actors. In this paper researchers Abhishek Singh and Ramesh Mani detail algorithms that can be used to detect SQL injection in stored procedures, persistent cross-site scripting…

VB2019 paper: Cyber espionage in the Middle East: Unravelling OSX.WindTail

It’s no secret that many nation states possess offensive macOS cyber capabilities, though such capabilities are rarely publicly uncovered. However, when such tools are detected, they provide unparalleled insight into the operations and techniques…

VB2019 paper: 2,000 reactions to a malware attack – accidental study

This paper presents an analysis of 1,976 unsolicited answers received from the targets of a malicious email campaign, who were mostly unaware that they were not contacting the real sender of the malicious messages. Many of the victims were unaware…

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.