Anti- Anti-debugging Techniques in Win32/Napolar solarbot

Avast’s report.

this will match the following variations

SHA256 hashes of some selected samples and how they are covered within the AVAST engine:

Dropper 11f11b896cc641db605d70186be468a148a
Win32:Napolar-E [Cryp]
Dropper 2f1a5707963a7e33a925111f09209a92b037
Win32:Napolar-E [Cryp]
Napolar Core Binary463d39dcbf19b5c4c9e314e5ce77bf8a51
Win32:Napolar-D [Trj]
WalletSteal Plugin Download12ca161cd72873477906100f083e43dca9
JS:NapolarPlugin-A [Trj]
WalletSteal Plugin x86bb49fa791915bf49ceb2a0563c91d2acaed
Win32:NapolarPlugin-B [Trj]
WalletSteal Plugin x64ff92206215115c867789dbd5a95132a2bd1
Win32:NapolarPlugin-B [Trj]

The structure of the core executable(s):


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,

cool! right?

code extract:


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 (high level.. to simple things up..)

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 usingNtTerminateProcess.

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.