Neurevt bot analysis

Just like most malware, the installation of Neurevt starts with it copying itself to a system folder. The folder is selected according to the machine’s characteristics such as the version of Windows, the service pack installed, and whether the OS is 64-bit.

For example, on an x86 machine running Windows XP SP2, the chosen folder is %PROGRAM FILES%\COMMON FILES. The installer creates a sub-folder named ‘winlogon.{2227A280-3AEA-1069-A2DE-08002B30309D}’.

The first part of the folder name, ‘winlogon’, is obtained from the configuration of the bot, and the second part is a special GUID which makes the folder link to the ‘Printers and Faxes’ folder in Windows Explorer. This folder will act as the launching point each time the malware restarts. The installer then launches the new file and exits.

The newly launched copy creates a process of a system application, which also varies under different circumstances, and starts to inject. The injected data is within a continuous block of memory and has the following data layout:

Figure 1. Layout of injected data.

Since this is the first time the malware has injected something into another process, the injected content runs as an independent application. I refer to it as the ‘primary instance’ to distinguish it from other instances that are injected into other processes.

The primary instance searches for all running processes, and injects into those that fulfil the following conditions:

This time, the injected data has the same layout as the primary instance. The only difference is in the ‘local cfg’ part – in which some data fields are modified to act differently since some components should be loaded in the primary instance only.

After injection, there should be one instance of the malware in every running user process. I refer to these as ‘assistant instances’. There is code in every assistant instance that monitors the status of the primary instance. Once, for whatever reason, the primary instance exits, the assistant instance will attempt to restart the malware from its launch point.

After the malware has finished its deployment, the primary instance will start to communicate with the C&C server. The whole process looks like a traditional virus infecting a file system, but instead of infecting files, the malware infects running processes.

The malware performs a system scan to gather information about the system and installed software. The gathered information will be stored in four separate flags, each of which is a single DWORD-length bit-flag.

The first flag contains information about the Windows version, installed service pack, and whether the OS is 32- or 64-bit.

The second flag contains information about the following software or vendors: .Net Framework, Java, Steam, SysInternals tools, mIRC, Hex-Rays, Immunity Inc., CodeBlocks, 7-Zip, PrestoSoft, Nmap, Perl, Visual Studio and Wireshark. It also contains information that indicates if the system:

The third flag contains information about the following software or vendors: Steam, EA Origin, RuneScape, Minecraft, Blizzard, League of Legends, VMware, Skype and Visual Studio.

The fourth flag contains information about installed AV software: Symantec, AVP, AVG, Avira, ESET, McAfee, Trend Micro, Avast, Microsoft Security Client, Bitdefender, BullGuard, Rising, Arcabit, Webroot, Emsisoft, F-Secure, Panda, PC Tools Internet Security and G Data AntiVirus.

The malware creates threads to perform different kinds of jobs, such as communicating with the C&C server, checking data consistency, managing messages passing among threads (components), or monitoring and infecting USB drives. These threads are like software components. In order to load the threads properly, the malware defines a function to create them. The following is the function’s definition:

HANDLE NewComponentThread( 
   LPVOID ThreadProc, 
   LPVOID InputBuf, 
   int SizeOfInputBuf, 
   int idx, 
   int reserved, 
   int *pThreadId, 
   int flag
   );

ThreadProc is the routine that performs a particular job, while idx is the index assigned to it by the malware. 0-0x1E and 0x21 are idx values given to those unique routines for which there should be only one running thread. 0x1F and 0x20 are for multiple instance routines. If the NewComponentThread is called with idx set to these two values, the function will assign a new idx to ThreadProc, which is the first available (unassigned) number from 0x22.

The malware maintains a list to keep track of all the threads that are created by the function. Each ThreadProc takes an entry pointed to by its idx. The entry of the list has the following structure:

typedef struct THREAD_LIST_ENTRY { 
   WORD Size;
   WORD Index;
   DWORD reserved;
   DWORD CreateFlag;
   DWORD SizeOfInputBuffer;
   DWORD InputBuffer;
   CHAR EventName1[96];
   HANDLE Event1;
   HANDLE Event2;
   HANDLE ThreadHandle;
   DWORD ThreadId;
   DWORD StartAddress;
   DWORD StubAddress;
   DWORD CurrentId;
   };

Before actually starting the new ‘component thread’, NewComponentThread adds a short code stub and a wrapper function to ThreadProc.

The code stub will be written into ntdll’s image, at a random location within the MZ header. This random location will serve as the StartAddress when NewComponentThread calls CreateThread. So, the start address of the ‘component thread’ is within the memory range of ntdll’s image. This feature is used when the malware passes messages among its threads.

Figure 2. Code stub

The wrapper function attempts to hide the thread from debuggers and updates the thread list before and after it calls ThreadProc. It also sets a specific TLS slot with a specific value, 1234. Since the malware’s code is always running in an injected process, the API hook will be applied to monitor and manipulate the behaviour of the host process. The specific TLS slot value is used to identify the malware’s own threads for which the API hook should not be applied.

The malware applies the Ring 3 hook in two ways.

First, the malware adds a pre-operation filter for each of the following Zw* APIs:

The filter first checks the specified TLS slot. If its value is 1234, this means that the calling thread belongs to the malware. The filter will do nothing and let the thread call the real API. If the TLS slot is not 1234, the filter examines the object (process, thread, file, registry) on which operation will be performed, if the object belongs to the malware, then the filter will return an error status to the calling thread.

The second way it applies the Ring 3 hook is by applying an inline hook on the following two groups of APIs:

The malware hooks APIs in group 1 to block unwanted hosts. The host list is received from the bot server. Most of the unwanted hosts are the web servers of anti-virus software vendors.

The malware hooks the APIs in group 2 only if the injected process is one of the following browser processes:

The malware receives a list of URLs to be monitored from the bot server. If the browser sends requests to these URLs, the malware will capture the request data and send it back to the bot server.

There are multiple instances of the malware running in the system. To coordinate these instances, the malware creates a thread in each as a handler of application-defined messages. Most of the messages are sent from the primary instance after it has received something from the bot server to notify other instances to update their local data, such as the blocked host list and the monitored URL list mentioned earlier.

If a malware’s thread is about to send a message, it enumerates all the running threads in the system, searching for those that have a start address within ntdll’s image. As described in the ‘Component thread’ section, all the threads created by NewComponentThread fulfil this condition. The sending thread will call PostThreadMessage to send the message to them. Among these threads, only the message handlers (in all the malware instances) have a message queue (by calling IsGuiThread) for messages that are not associated with any window (a feature of messages sent by PostThreadMessage). So the handlers will retrieve the message and response accordingly.

Before a message is sent out, the sending thread will add a pre-defined modifier to the message identifier. This modifier is calculated based on the signature string in the bot configuration and the computer name. Its value is within the range from 0 to 31. The wParam and lParam are also modified since they often carry values with specific meanings like process id or thread id.

Figure 3. Modify message before sending.

In the handler thread, these values will be restored by a reverse calculation before the message is handled. This means that, even if the messages passing among the malware’s threads are being monitored, it’s hard to understand their meanings.

Figure 4. Restore the message before handling.

The messages supported by the handler thread are listed in Table 1:

The malware stores shared data for all instances in registry values. The values will be created under the key HKCU\Software\CLSID\{random guid}\{hash of configuration signature string}. The following are important values used by the malware:

Neurevt has a built-in configuration. The configuration data and the decryption code are both encrypted with RC4. The malware allocates a block of memory on the heap, and decrypts and copies the decryption code into the memory. Then it creates a thread to decrypt the configuration.

The argument passed to the thread is a pointer to the following structure:

typedef struct DECRYPT_CONFIG_STRUCT {
   DWORD cbSize;
   DWORD lpConfigData;
   DWORD lpKey;
   DWORD lpGlobalData;
   DWORD lpKeyForReEncrypt;
   DWORD ImageBase;
   DWORD DecryptFunc;
   DWORD SearchFunc; // To search the PE image for config’s hash
   DWORD AllocMemory;
   DWORD ReleaseMemory;
   DWORD HashString; // To calculate the config’s hash
   DWORD GetCriticalSection;
   DWORD Win32APIList;
};

The fields between DecryptFunc and GetCriticalSection are functions that are used by the decryption function. First, the decryption thread will perform an integrity check by calculating the hash value of the key sequence and comparing it with a value that is embedded in the PE image. If the hash values are consistent, the thread allocates a block of memory and decrypts the configuration data into the memory.

lpKeyForReEncrypt is a pointer to a four-byte key sequence for re-encryption. It is generated randomly after the configuration data has been decrypted. The re-encryption also uses the RC4 algorithm. Its purpose is to protect the configuration data from being discovered in any memory dump. The re-encryption is done by the main thread after the decryption thread exits. Before the decryption thread exits, it stores the memory pointer and the re-encryption key in the memory block that is given by lpGlobalData.

Any access to the configuration data afterwards is carried out using the following steps:

Figure 5. Access configuration data.

Steps 2 and 3 are completed in one function. So, the configuration data remains plain text in the memory for only a short period of time.

The configuration data has a 718-byte header, which contains the fields shown in Table 2.

Figure 6. Configuration (header).

There is an array at 0x2ce of the configuration data. Each entry stores information about a C&C server. Normally there will be more than three entries in one configuration. The size of the entry is 0x280 bytes. The crucial fields are shown in Table 3.

Figure 7. Configuration entry.

Each request contains a 128-byte data block, which contains the fields shown in Table 4.

The malware encrypts the data block with RC4. It uses a 12-byte key sequence, which is a combination of two parts. The first is an eight-byte sequence obtained from the chosen entry of the configuration data, at offset 0x26e. The second part is a random sequence obtained by calling CryptGenRandom. The length of the sequence is within a range from eight to 27 bytes. This part of the key and encrypted data block will be inserted into the query string.

Figure 8. First part of query string

If it is the first request sent to the bot servers, it will also contain the following three CS fields:

Figure 9. Data of CS fields.

These strings are encrypted separately with a loop-XOR algorithm and concatenated into a URL query string.

Figure 10. Extra fields for the first request.

The bot response contains a 0x5c-byte header and a body which consists of at most eight streams (only four streams are actually used). Both the header and the body are encrypted with RC4 and they will be decrypted separately. The first four bytes in the header will be appended to the eight-byte sequence in the configuration to form a 12-byte key sequence for decrypting the header. The following four bytes in the header and another eight-byte sequence in the configuration are concatenated to form another 12-byte key sequence for the response body.

The response header has the structure shown in Table 5.

The Control flag in the response header is a bit-flag which triggers different behaviours of the malware, such as invoking routines that disable security software or fake pop up warning windows to trick the user into giving permission for the malware to bypass the UAC.

Fields from 0x20 to 0x28 are three DWORDs which will be stored in the registry values. They will be copied to the bot server in the next request sent by the malware.

The length array at 0x3C has eight entries – each denotes the length of the corresponding stream in the response body.

According to the response header format, there should be eight streams in the body, but the malware only has handling routines for the first four streams.

The first stream contains bot commands sent back by the bot server. The first word of the stream is the count of the commands in the stream. Each command is stored as a null terminated string preceded by a data block. The size of the data block is 22 bytes. It is not used in any of the malware’s code.

Figure 11. First stream (commands).

The malware identifies the command keyword by hash value. It has a list of handling routines. Each entry in the list has the following structure:

typedef BotCmdEntry {
   DWORD dwHash;
   PVOID lpfnCmdProc;
   DWORD KeywordLength;
}

Figure 12. Handling routine list.

The second stream contains a list of hosts that will be blocked. The list is used in the following hooked functions:

Figure 13. Second entry (blocked hosts).

The third stream contains a list of URLs for which the malware will monitor the HTTP requests sent. The list will be used in the following hooked APIs:

Figure 14. Third entry (monitored URLs).

The fourth stream in the response body contains data which could be used to generate a new configuration. The stream is in a format similar to that of an INI file. The malware compiles the stream into a binary data block which is organized in a structure described in the configuration section.

Figure 15. Fourth entry (new configuration).