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.
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.
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.
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
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 0×55. 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.
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.
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.
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.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.
Analyzed files
The following are MD5 hashes of the analyzed files:
- 85e5a0951182de95827f1135721f73ad0828b6bc
- 9c159f00292a22b7b609e1e8b1cf960e8a4fa795
- a86e4bd51c15b17f89544f94105c397d64a060bb
- ce24ae6d55c008e7a75fb78cfe033576d8416940
- dacfa9d0c4b37f1966441075b6ef34ec8adc1aa6
Author: Pierre-Marc Bureau
Security Intelligence Program Manager
Security Intelligence Program Manager
No comments:
Post a Comment