October 2, 2013 at 12:08Win32 / Napolar - the new in-the-wild bot
Recently, our experts discovered a new malware program that was added to anti-virus databases like Win32 / Napolar . We drew attention to it in mid-August due to interesting methods of anti-debugging and code injection. The bot is used by cybercriminals for several purposes: conducting DoS attacks, organizing SOCKS proxies, and stealing data from infected systems. Like other trojans, Win32 / Napolar can inject its code into browsers in order to obtain data from web forms.
We have been observing Napolar activity since the end of July. Since then, thousands of infections have been recorded, many of which are in South America. Countries like Peru, Ecuador and Colombia have the highest number of infections. More information on the geography of distribution can be found on virusradar.
We were not able to witness the campaign to distribute this malicious code, but indirect evidence indicates the use of the social network Facebook for this purpose. Since Napolar has the ability to steal the credentials of Facebook accounts, botnet operators can reuse this data to send messages to the contacts of a compromised user. The following is a list of the file names that attackers used in Napolar distribution campaigns:
To mask the true file extension and confuse users, double name extensions were used (for example, * .JPG.EXE, * .TXT.EXE. Our colleagues from AVAST confirmed these infection vectors in their analysis .
Anti-debugging tricks
The first thing we noticed was lack of an entry point address in the PE-header.
In this file, the functions that the OS will execute when it starts are located in Thread Local Storage (TLS) . The dropper has two registered TLS functions. The first of them does not perform any functions. The second is responsible for decryption code with isp lzovaniem RC4 algorithm and key 0xDEADBEEF. This decrypted code is recorded as a third TLS function before the function returns the previous OS.
The third TLS function decrypts the rest of the code before executing it. Malicious code uses the following tricks to complicate its analysis:
To transfer control to the decryption function, Win32 / Napolar looks for the 0x55 opcode in memory (corresponds to the push ebp instruction, the expected start of the function). If this instruction is replaced by the 0xCC opcode (i.e., a debug breakpoint is set on it), the decryption of the code will not work, since the function will not be called. Such an anti-debugging mechanism allows you to detect a debugger in the process of dropper operation and take the necessary actions.
In order to complicate dynamic analysis, Win32 / Napolar creates a child process based on its image with the ability to debug it.
This practice of complicating dynamic analysis was mentioned in Analysis of a self-debugging Sirefef cryptor. But in the case of Napolar, the ability to debug itself with malicious code is realized in its main body, and not in the packer.
As soon as the debugged process is started, the Trojan starts the execution cycle of the debugging events returned by the WaitForDebugEvent function . The pseudocode of this cycle is shown below in the screenshot.
The first event to be processed by this code is CREATE_PROCESS_DEBUG_EVENT. A notification about it comes when the debugged process has been started. In this case, the parent (main) process will analyze the header of the image file of the running process for the presence of standard MZ and PE markers to obtain the offset and size of the code with an independent position (position-independent code). Then, a memory block will be allocated in the debugged process, where the code will be implemented. Thus, through a similar operation, two copies of the same code will be created in this process.
The next event to be processed in the loop is EXCEPTION_DEBUG_EVENT. The processing code for this event will overwrite the first TLS function so that it redirects the execution of the code to the beginning of the executable file through the use of push / ret instructions. Then, the main body of Napolar is decrypted and its subsequent execution (in the context of the child process). In the future, the code from the child process is responsible for almost all basic operations, i.e., the implementation of the code in the processes, the launch of child processes and interception of various functions to hide its presence in the system and intercept the necessary information.
The final step in the loop is to receive the EXIT_PROCESS_DEBUG_EVENT event. In this case, the parent code stops debugging by calling DebugActiveProcessStopand ends its own process using NtTerminateProcess .
One of the main features of Win32 / Napolar is its ability to steal information from web page forms that are displayed in a browser. The Trojan program contains a special code to detect the Trusteer security product, which complements the user's browser with special protection functions. If, when enumerating the processes running in the system, a process is found that contains “trusteer” in its name, then it will be forcibly terminated.
Networking
To interact with the C&C command server, Win32 / Napolar uses the HTTP protocol. The first message sent by the bot to the server contains the following information:
Then the server responds with tasks to the bot, which it must complete. These commands are encrypted using RC4, with the Bot ID used as the key for encryption. The bot supports many commands:
Each command has its own unique identifier, stored as one byte, followed by command parameters. The following screenshot shows part of the traffic that was used during the interaction between the bot and the management server.
The following figure shows the decryption of this command using the corresponding key. The first byte “0xC” is the code of the “sleep” command for the bot. The parameter is the string "600", indicating the number of seconds by which the bot should fall asleep.
We have seen at least seven different C&C servers used by Win32 / Napolar. Most of them stayed online for only a few days. After that, the operator moved them to a new network. Such behavior can be explained by the fact that the bot is actively used "in the wild", that is, it has a large number of installations on users' computers. The following is a list of domains found by C&C servers:
Links to TOR were detected in malware configuration files. Perhaps the attackers will use this function later to take advantage of this anonymous network during network communication.
Win32 / Napolar authors seem to be very interested in selling their “product." The website that advertises the bot looks very creative and contains information for potential customers. The full code of the bot’s interaction with the C & C server and the PHP script working with the SQL database can be found on it. In addition, the site contains various examples of plugins that can be used by malicious code operators. The plugins themselves must be written in Delphi.
The site contains information about the changes that were made in different versions of the Trojan program (changelog). Based on these data, the first change was made on July 14, which corresponds to our assumptions, since we observed the first bot samples in early August. The domain registration date for these samples also corresponds to the beginning of August.
We have been observing Napolar activity since the end of July. Since then, thousands of infections have been recorded, many of which are in South America. Countries like Peru, Ecuador and Colombia have the highest number of infections. More information on the geography of distribution can be found on virusradar.
We were not able to witness the campaign to distribute this malicious code, but indirect evidence indicates the use of the social network Facebook for this purpose. Since Napolar has the ability to steal the credentials of Facebook accounts, botnet operators can reuse this data to send messages to the contacts of a compromised user. The following is a list of the file names that attackers used in Napolar distribution campaigns:
- Photo_032.JPG_www.facebook.com.exe
- Photo_032.JPG_www.facebook.com.exe
- Photo_014-WWW.FACEBOOK.COM.exe
To mask the true file extension and confuse users, double name extensions were used (for example, * .JPG.EXE, * .TXT.EXE. Our colleagues from AVAST confirmed these infection vectors in their analysis .
Anti-debugging tricks
The first thing we noticed was lack of an entry point address in the PE-header.
In this file, the functions that the OS will execute when it starts are located in Thread Local Storage (TLS) . The dropper has two registered TLS functions. The first of them does not perform any functions. The second is responsible for decryption code with isp lzovaniem RC4 algorithm and key 0xDEADBEEF. This decrypted code is recorded as a third TLS function before the function returns the previous OS.
The third TLS function decrypts the rest of the code before executing it. Malicious code uses the following tricks to complicate its analysis:
- All addresses of imported functions in the import table are filled in during execution using hashes of the names of these functions.
- The dropper’s interaction with the OS is mainly done by directly calling the undocumented ntdll functions instead of using standard APIs.
To transfer control to the decryption function, Win32 / Napolar looks for the 0x55 opcode in memory (corresponds to the push ebp instruction, the expected start of the function). If this instruction is replaced by the 0xCC opcode (i.e., a debug breakpoint is set on it), the decryption of the code will not work, since the function will not be called. Such an anti-debugging mechanism allows you to detect a debugger in the process of dropper operation and take the necessary actions.
In order to complicate dynamic analysis, Win32 / Napolar creates a child process based on its image with the ability to debug it.
This practice of complicating dynamic analysis was mentioned in Analysis of a self-debugging Sirefef cryptor. But in the case of Napolar, the ability to debug itself with malicious code is realized in its main body, and not in the packer.
As soon as the debugged process is started, the Trojan starts the execution cycle of the debugging events returned by the WaitForDebugEvent function . The pseudocode of this cycle is shown below in the screenshot.
The first event to be processed by this code is CREATE_PROCESS_DEBUG_EVENT. A notification about it comes when the debugged process has been started. In this case, the parent (main) process will analyze the header of the image file of the running process for the presence of standard MZ and PE markers to obtain the offset and size of the code with an independent position (position-independent code). Then, a memory block will be allocated in the debugged process, where the code will be implemented. Thus, through a similar operation, two copies of the same code will be created in this process.
The next event to be processed in the loop is EXCEPTION_DEBUG_EVENT. The processing code for this event will overwrite the first TLS function so that it redirects the execution of the code to the beginning of the executable file through the use of push / ret instructions. Then, the main body of Napolar is decrypted and its subsequent execution (in the context of the child process). In the future, the code from the child process is responsible for almost all basic operations, i.e., the implementation of the code in the processes, the launch of child processes and interception of various functions to hide its presence in the system and intercept the necessary information.
The final step in the loop is to receive the EXIT_PROCESS_DEBUG_EVENT event. In this case, the parent code stops debugging by calling DebugActiveProcessStopand ends its own process using NtTerminateProcess .
One of the main features of Win32 / Napolar is its ability to steal information from web page forms that are displayed in a browser. The Trojan program contains a special code to detect the Trusteer security product, which complements the user's browser with special protection functions. If, when enumerating the processes running in the system, a process is found that contains “trusteer” in its name, then it will be forcibly terminated.
Networking
To interact with the C&C command server, Win32 / Napolar uses the HTTP protocol. The first message sent by the bot to the server contains the following information:
- Bot version
- Username from current account
- Computer name
- Bot ID
- OS version
- Type of system (x32 / x64).
Then the server responds with tasks to the bot, which it must complete. These commands are encrypted using RC4, with the Bot ID used as the key for encryption. The bot supports many commands:
- Information theft
- SOCKS proxy
- DoS attack
- Download additional modules
- Modules execution
- Bot update.
Each command has its own unique identifier, stored as one byte, followed by command parameters. The following screenshot shows part of the traffic that was used during the interaction between the bot and the management server.
The following figure shows the decryption of this command using the corresponding key. The first byte “0xC” is the code of the “sleep” command for the bot. The parameter is the string "600", indicating the number of seconds by which the bot should fall asleep.
We have seen at least seven different C&C servers used by Win32 / Napolar. Most of them stayed online for only a few days. After that, the operator moved them to a new network. Such behavior can be explained by the fact that the bot is actively used "in the wild", that is, it has a large number of installations on users' computers. The following is a list of domains found by C&C servers:
- dabakhost.be
- terra-araucania.cl
- xyz25.com
- yandafia.com
- elzbthfntr.com
- alfadente.com.br
Links to TOR were detected in malware configuration files. Perhaps the attackers will use this function later to take advantage of this anonymous network during network communication.
Win32 / Napolar authors seem to be very interested in selling their “product." The website that advertises the bot looks very creative and contains information for potential customers. The full code of the bot’s interaction with the C & C server and the PHP script working with the SQL database can be found on it. In addition, the site contains various examples of plugins that can be used by malicious code operators. The plugins themselves must be written in Delphi.
The site contains information about the changes that were made in different versions of the Trojan program (changelog). Based on these data, the first change was made on July 14, which corresponds to our assumptions, since we observed the first bot samples in early August. The domain registration date for these samples also corresponds to the beginning of August.