There is a new bot on the block. ESET identifies it as Win32/Napolar while its author calls it solarbot. This piece of malware came to our attention mid-August because of its interesting anti-debugging and code injection techniques. It recently attracted general attention when it was discussed on various reverse engineering forums.

This malware can serve multiple purposes. The three main ones are to conduct Denial of Service attacks, to act as a SOCKS proxy server, and to steal information from infected systems. The malware is able to hook into various browsers to steal information that is submitted in web forms.

We have uncovered many details about this bot since it became active at the end of July, with in-the-wild infections starting mid-August. There have been reports of thousands of infections, many of them in South America. The countries with the most infections are Peru, Ecuador, and Columbia. More information on the geographical distribution for this threat can be found on virusradar.

The author of Win32/Napolar uses a website to promote it. The website looks very professional and contains detailed information about the bot, including the cost ($200 USD for each build) and even a complete change-log of the evolution of the code.

Although we have not yet directly seen Win32/Napolar being distributed in the wild, it seems likely that this threat has been spread through Facebook. Since malware has the ability to steal Facebook credentials, its operator can reuse those credentials to send messages from compromised accounts and try to infect the victim’s friends. Below is a list of filenames we have seen used by this malware family:

Photo_032.JPG_www.facebook.com.exe
Photo_012-WWW.FACEBOOK.COM.exe
Photo_014-WWW.FACEBOOK.COM.exe

Interestingly enough, the use of doubled file extensions (*.JPG.EXE, *.TXT.EXE and so forth) to obfuscate a file's true extension is an old trick, dating back to Windows 95, but apparently still in use. What is funny about the usage in this particular instance is that the author of Win32/Napolar does not seem to realize that .COM is a valid, if somewhat old, extension for executable files and that these filenames would have allowed their execution without the added .EXE extension. A very recent blog by our colleagues at AVAST confirms they have also seen similar infection vectors.

In this blog post, we will show some of the anti-debugging tricks used by Win32/Napolar. These tricks were seen in early versions of this malware family. Most recent variants also use third party packers to evade antivirus detection and slow down manual reverse engineering.

We will then explain the Win32/Napolar command and control (C&C) protocol. Finally, we will show some of the information that was retrieved from the promotional website before it was taken offline.

Anti-debugging Techniques

When analyzing Win32/Napolar binaries, the first thing to notice is that there is no valid entry point in the PE header, as shown in the figure below.

The first instructions that are executed when the binary is started are saved in the Thread Local Storage (TLS) functions. There are two TLS functions registered. The first TLS function does not do anything. The second function decrypts more code using the RC4 encryption algorithm and the key 0xDEADBEEF. The decrypted code is registered as a third TLS function before the second function returns, as shown in the code extract below.

02_inserting_third_tls

The third TLS function decrypts the rest of the code before calling the main body of the malware. The malware uses other tricks to make itself harder to analyze:

All imports are resolved at runtime using hashes instead of the import names.
Interactions with the operating system are mostly done by directly calling undocumented functions of the NTDLL library instead of using the standard APIs.
All the code is position-independent.

To find the offset of its own code that will be decrypted, Win32/Napolar searches through its memory for the opcode 0x55. This opcode represents “push ebp”, the first instruction of the current function in assembly language. If this instruction is replaced by 0xCC, the opcode for a software breakpoint, the decryption of the code will not work. This is a clever way of altering the behavior of the malware if it is being analyzed with a debugger and if a software breakpoint is put on the first instruction of the TLS.

Win32/Napolar has more anti-debugging tricks. To make dynamic analysis harder, Win32/Napolar will create a sub process of itself and will debug this new instance. The screenshot below shows the call to CreateProcess.

The software protection technique of self-debugging has been seen before but in the case of Win32/Napolar, the trick happens in the main body of the malware, not in the packer.

Once the debugged process is started, Win32/Napolar will enter a loop that handles debugging events returned by the function WaitForDebugEvent. Pseudocode for the loop handling debugging events is presented below.

The first event handled by this code is CREATE_PROCESS_DEBUG_EVENT. This event takes place when the debugged process is started. In this case, the main process will parse the MZ and PE header of the debugged process in order to retrieve the offset and size of the position-independent code. It will then allocate another area of memory in the debugged process in which to inject the code. This creates two copies of the same code in the same process.

The next event is EXCEPTION_DEBUG_EVENT. In this second event, the main process overwrites the first TLS function of the binary so as to redirect execution at the beginning of the executable, using a push – ret instruction. This, once again, decrypts the main body of the malware and lets it execute within the child process. It is the code of the child process that then proceeds to inject itself into all the processes running sub-processes and hooking various functions to hide its presence on the system and capture desired information.

Finally, the main process receives the EXIT_PROCESS_DEBUG_EVENT event; it stops debugging by calling the function DebugActiveProcessStop and terminates its own process using NtTerminateProcess.

chart

One of the main characteristics of Win32/Napolar is its ability to steal information when a user fills a web form in a web browser. Trusteer’s browser protection probably stops the malware from capturing this information. This is why the malware has specific checks for Trusteer products. It will iterate through all the running processes and specifically kill any process that has the string “trusteer” in it. We did not perform any test to confirm whether or not this attempt at disabling Trusteer’s product is successful or not.

Network behavior

When communicating with its command and control server, Win32/Napolar uses the HTTP protocol. The first query sent by the bot to the command and control server contains the following information:

Version of the bot
Current windows username of the infected user
Computer name
A unique bot identifier
Version of the operating system
System type, which can be 32 or 64 bit. Indeed, this bot supports both types of architecture.

The server then responds with commands the bot needs to execute. These commands are encrypted using RC4, The bot unique identifier is used as the encryption key. The bot supports a variety of commands, from information stealing and SOCKS proxying, to denial of service, download, execution and update. Each command has a unique identifier stored as a single byte and the information following this byte contains the command parameters. The following figure shows a traffic dump of the communication between a host infected by Win32/Napolar and its command and control server.

The following figure shows the decryption of this command using the proper key. The first byte of the received content is 0xC, and this instructs the bot to sleep. The parameter is a string, “600”, which represents the number of seconds that the bot needs to sleep.

07_decrypted_cnc_nop

We have seen at least seven different command and control servers used by Win32/Napolar. Most of them only stayed online for a couple of days before the operator moved them to a new network. This might indicate that this bot is being actively used in the wild. Below is a list of domain names where we have recently observed command and control servers:

dabakhost.be
terra-araucania.cl
xyz25.com
yandafia.com
elzbthfntr.com
alfadente.com.br

There are some references to TOR in the malware code. Most precisely, some configuration lines and references to the configuration file for TOR. During our analysis of the malware, it didn’t seem to make any usage of this data. This could be some dormant feature that has not been activated in the samples we have analyzed.

Promotional website

The author of Win32/Napolar seems very frank about wanting to sell his new malware. He has put together a very professional-looking website where he boasts that his bot is a “professional shellcode based bot”, referring to the fact the malware is position-independent.

08_solar_website1

The website also provides information for potential customers. For example, the complete code for the command and control server can be found there, a php script running with an SQL database backend. The code of the command and control server confirms of our analysis of the network protocol used by the Win32/Napolar malware.

The promotional website also provides multiple examples of plugins that can be used by malware operators. The plugins must be written using the Delphi programming language. The example plugins show how one can display a message on an infected victim system, find which version of the antivirus is installed on the victim system, and even how to steal Bitcoin wallets.

Finally, the website even presented a complete log of the changes made to the bot’s source code, including information on new features and bug fixes. The website shows the first changelog entry made on July 14th. This fits our timeline since we saw the first instances of this bot in the wild in the beginning of August. The registration date for the domain name where the content is hosted is the first day of August, another indication that the beginning of the promotion is recent.

09_solar_website2

Conclusions

Win32/Napolar is a new bot that surfaced in July and started to be observed in the wild in August. It has interesting techniques for countering reverse engineering. The most notable point about this malware is how openly it is being promoted on the web by its creator. The advertisement is probably the same that was identified by Dancho Danchev at webroot in July. We have seen many messages on different forums promoting this bot, in addition to the existence of a publicly-accessible website. As it was previously discussed in the Foxxy case, this is another good example of the specialization of cybercrime operations where we now clearly have authors that create malware and sell it to other gangs who will operate it.

Although this bot has functionalities similar to other families like Zeus or SpyEye, it might gain in popularity because its author is actively maintaining it, and because of its ease of use and the simplicity with which plugins can be created.