Win32 / Napolar - new in-the-wild bot
Recently, our specialists discovered a new malware that was added to the anti-virus database as Win32 / Napolar . We paid attention to it in mid-August due to interesting anti-debugging methods and code injection. The bot is used by attackers for several purposes: conducting DoS attacks, organizing a SOCKS proxy server, stealing data from infected systems. Like other Trojans, Win32 / Napolar is able to inject its code into browsers in order to get data from web forms.
We have observed Napolar activity since the end of July. Since then, thousands of infections have been recorded, many of them in South America. Countries such as Peru, Ecuador and Colombia account for the largest number of infections. More information on the geography of distribution can be found at virusradar .
')
We were not able to witness the campaign to distribute this malicious code, but indirect evidence points to the use of the social networking site Facebook for this purpose. Since Napolar has the ability to steal Facebook account credentials, botnet operators can reuse this data to send messages to compromised users. Below is a list of file names that attackers used in Napolar distribution campaigns:
To disguise the true file extension and confuse users, double name extensions were used (for example, * .JPG.EXE, * .TXT.EXE. Our AVAST colleagues confirmed these infection vectors in their analysis.
Anti-debugging tricks
The first thing we noticed was the absence of the entry point address in the PE header.
In such a file, the functions that will be executed by the OS when it is launched are located in Thread Local Storage (TLS) . Dropper has two registered TLS functions. The first one does not perform any functions. The second is responsible for decoding the code using the RC4 algorithm and the key 0xDEADBEEF. This decoded code is registered as the third TLS function before the previous function returns control to the OS.
The third TLS function decrypts the rest of the code before it is executed. The malicious code uses the following tricks to complicate its analysis:
To transfer control to the decryption function, Win32 / Napolar searches in memory for the opcode 0x55 (corresponds to the push ebp instruction, the expected start of the function). If this instruction is replaced by the opxcode 0xCC (i.e., a debug breakpoint will be supplied to it), the decryption of the code will not work, since the function will not be called. This anti-debugging mechanism allows the debugger to be detected during the dropper operation and to 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 the article "Analysis of a self-debugging Sirefef cryptor" . But in the case of Napolar, the ability to debug the malicious code itself is implemented in its main body, and not in the packer.
As soon as the debugged process is launched, the Trojan program will start executing the debugging event processing loop 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. Notification about it comes when the debugged process has been launched. 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 the size of the code with independent position (independent position) code. Then a block of memory will be allocated in the process being debugged, where code injection will be performed. Thus, through a similar operation, two copies of the same code will be created in this process.
The next event to be handled in a 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 there is a decryption of the main body of Napolar and its subsequent execution (in the context of the child process). Further, the code from the child process is responsible for almost all the basic operations, i.e., embedding the code into processes, launching child processes and intercepting various functions to hide its presence in the system and intercept 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 DebugActiveProcessStop and terminates its own process using NtTerminateProcess .
One of the main features of Win32 / Napolar is its ability to steal information from forms of web pages that are displayed in the browser. The Trojan program contains a special code for detecting the Trusteer security product, which complements the user's browser with special protection functions. If, when listing processes running in the system, a process is found that contains “trusteer” in its name, it will be forcibly terminated.
Networking
Win32 / Napolar uses the HTTP protocol to interact with the command C & C server. The first message sent by the bot to the server contains the following information:
Then the server responds with bot tasks that it must perform. These commands are encrypted using RC4, with the Bot ID being used as the encryption key. The bot supports many commands:
Each command has its own unique identifier, stored as one byte, followed by the command parameters. The following screenshot shows a part of the traffic that was used in the interaction between the bot and the managing server.
The following figure shows the decryption of this command using the appropriate key. The first byte of “0xC” is the code of the “sleep” command for the bot. The parameter is the string "600", meaning the number of seconds for 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. Below is a list of domains detected by C & C servers:
Links to TOR were found in the configuration files of the malicious program. Perhaps the attackers will use this feature later to take advantage of this anonymous network for network interaction.
The authors of Win32 / Napolar, apparently, are very interested in selling their "product". The website advertising the bot looks very creative and contains information for potential customers. It can be found the full code of the bot interaction with the C & C server and a PHP script working with the SQL database. In addition, the site contains various examples of plug-ins that can be used by operators of malicious code. The plugins themselves must be written in Delphi.
The site contains information about changes that were made in different versions of the Trojan program (changelog). Based on these data, the first change was made on July 14th, which corresponds to our assumptions, since we observed the first samples of the bot in early August. The domain registration date for these samples also corresponds to the beginning of August.
We have observed Napolar activity since the end of July. Since then, thousands of infections have been recorded, many of them in South America. Countries such as Peru, Ecuador and Colombia account for the largest number of infections. More information on the geography of distribution can be found at virusradar .
')
We were not able to witness the campaign to distribute this malicious code, but indirect evidence points to the use of the social networking site Facebook for this purpose. Since Napolar has the ability to steal Facebook account credentials, botnet operators can reuse this data to send messages to compromised users. Below is a list of 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 disguise the true file extension and confuse users, double name extensions were used (for example, * .JPG.EXE, * .TXT.EXE. Our AVAST colleagues confirmed these infection vectors in their analysis.
Anti-debugging tricks
The first thing we noticed was the absence of the entry point address in the PE header.
In such a file, the functions that will be executed by the OS when it is launched are located in Thread Local Storage (TLS) . Dropper has two registered TLS functions. The first one does not perform any functions. The second is responsible for decoding the code using the RC4 algorithm and the key 0xDEADBEEF. This decoded code is registered as the third TLS function before the previous function returns control to the OS.
The third TLS function decrypts the rest of the code before it is executed. The malicious code uses the following tricks to complicate its analysis:
- All addresses of imported functions in the import table are filled in the process of execution using hashes of the names of these functions.
- Dropper's interaction with the OS is mainly performed by directly calling the undocumented ntdll functions instead of using standard APIs.
To transfer control to the decryption function, Win32 / Napolar searches in memory for the opcode 0x55 (corresponds to the push ebp instruction, the expected start of the function). If this instruction is replaced by the opxcode 0xCC (i.e., a debug breakpoint will be supplied to it), the decryption of the code will not work, since the function will not be called. This anti-debugging mechanism allows the debugger to be detected during the dropper operation and to 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 the article "Analysis of a self-debugging Sirefef cryptor" . But in the case of Napolar, the ability to debug the malicious code itself is implemented in its main body, and not in the packer.
As soon as the debugged process is launched, the Trojan program will start executing the debugging event processing loop 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. Notification about it comes when the debugged process has been launched. 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 the size of the code with independent position (independent position) code. Then a block of memory will be allocated in the process being debugged, where code injection will be performed. Thus, through a similar operation, two copies of the same code will be created in this process.
The next event to be handled in a 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 there is a decryption of the main body of Napolar and its subsequent execution (in the context of the child process). Further, the code from the child process is responsible for almost all the basic operations, i.e., embedding the code into processes, launching child processes and intercepting various functions to hide its presence in the system and intercept 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 DebugActiveProcessStop and terminates its own process using NtTerminateProcess .
One of the main features of Win32 / Napolar is its ability to steal information from forms of web pages that are displayed in the browser. The Trojan program contains a special code for detecting the Trusteer security product, which complements the user's browser with special protection functions. If, when listing processes running in the system, a process is found that contains “trusteer” in its name, it will be forcibly terminated.
Networking
Win32 / Napolar uses the HTTP protocol to interact with the command C & C server. 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
- The type of system (x32 / x64).
Then the server responds with bot tasks that it must perform. These commands are encrypted using RC4, with the Bot ID being used as the encryption key. The bot supports many commands:
- Theft of information
- SOCKS proxy
- DoS attack
- Loading additional modules
- Module execution
- Update bot.
Each command has its own unique identifier, stored as one byte, followed by the command parameters. The following screenshot shows a part of the traffic that was used in the interaction between the bot and the managing server.
The following figure shows the decryption of this command using the appropriate key. The first byte of “0xC” is the code of the “sleep” command for the bot. The parameter is the string "600", meaning the number of seconds for 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. Below is a list of domains detected by C & C servers:
- dabakhost.be
- terra-araucania.cl
- xyz25.com
- yandafia.com
- elzbthfntr.com
- alfadente.com.br
Links to TOR were found in the configuration files of the malicious program. Perhaps the attackers will use this feature later to take advantage of this anonymous network for network interaction.
The authors of Win32 / Napolar, apparently, are very interested in selling their "product". The website advertising the bot looks very creative and contains information for potential customers. It can be found the full code of the bot interaction with the C & C server and a PHP script working with the SQL database. In addition, the site contains various examples of plug-ins that can be used by operators of malicious code. The plugins themselves must be written in Delphi.
The site contains information about changes that were made in different versions of the Trojan program (changelog). Based on these data, the first change was made on July 14th, which corresponds to our assumptions, since we observed the first samples of the bot in early August. The domain registration date for these samples also corresponds to the beginning of August.
Source: https://habr.com/ru/post/196086/
All Articles