 | |||
|
|
||
|
|||
| |
|
Home > Tracking botnets |
| |
|
|
|
|
| Book Excerpt: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||
In this section, we present a technical realization to track botnets. The methodology is based on some building blocks that are introduced in this book: [IMAGE]Figure 11.5 Schematic view of botnet mitigation. As you can see, tracking botnets is clearly a multistep operation: First one needs to gather some data about an existing botnet. This can, for instance, be obtained with the help of honeynets or via an analysis of captured malware. The most successful way is to use nepenthes to automatically capture autonomous spreading malware. Via automated analysis of the captured binary, we can extract all information related to the botnet from the file. With the help of this information, it is then possible to smuggle a client into the network. The whole process of stopping such a network is depicted in Figure 11.5.With
the help of nepenthes, we can now automate step 1 to a high degree. Without
supervision, this platform can collect malware that currently propagates within a
network. We are currently working on step 2: an automated mechanism to extract
the sensitive information of a remote control network from a given binary.With the
help of honeypots, we can automate this step to a certain degree. In addition, we
explore possible ways to use sandbox-like techniques to extract this information
during runtime. (We present more details about this step in Chapter 12). Step 3 in
the whole process can be automated as outlined in a study by Freiling et al. [28].
We impersonate a legal victim and infiltrate the network. This allows us to study
the attacker and his techniques, collect more information about other victims, or
learn about new trends. Finally, step 4 can be automated to a limi...
ted degree with the help of techniques such as stooping the communication channel between victims and remote control server or other ways to shut down the main server itself. This step also needs some further research, but it seems viable that this can also be automated to a high degree. We present some methods in a later section in this chapter. The whole process would then allow us to automatically defend against these kind of attacks in a proactive manner. An automated system is desirable, since this kind of attacks is a growing threat within the attacker community. What kind of information do we need to automate the process? Basically the necessary information includes all data needed to describe how the attacker can send commands to his bots, such as the following: As just outlined, we can get all this information with the help of different honeypots and automated malware analysis. We now present a possible way to observe a given botnet based on this information.We introduce a tool called botspy and show how it can help us to get more insight about a botnet. 11.2.1 Observing Botnets Once we have collected all sensitive information of the botnet, we start to infiltrate the botnet as we have all the necessary data. In a first approach, it is possible to set up a normal IRC client and try to connect to the network. If the operators of the botnets do not detect this client, logging all the commands can be enabled. This way, all bot commands and all actions can be observed. If the network is relatively small (i.e., less then 50 clients), there is a chance that the bogus client will be identified, since it does not answer to valid commands. In this case, the operators of the botnets tend to either ban and/or DDoS the suspicious client. But often it is possible to observe a botnet simply with a normal IRC client, to which you feed all information related to the botnet. However, there are some problems with this approach. Some botnets use a very strongly stripped-down C&C server that is not RFC compliant so that a normal IRC client cannot connect to this network. A possible way to circumvent this situation is to find out what the operator has stripped out and modify the source code of the IRC client to override it. Furthermore, this approach does not scale very well. Tracking more than just a few botnets is not possible, since a normal IRC client will be overwhelmed with the amount of logging data, and it does not offer a concise overview of what is happening. Therefore, we use an IRC client optimized for botnet tracking called botspy. This software was developed by Claus Overbeck in his master's thesis and offers several decent techniques for observing botnets. It is inspired by the tool drone, developed by some members of the German Honeynet Project, and shares many characteristics with it: When observing more than a couple of networks, we began to check if some of them are linked and group them, if possible. Link-checking is simply realizable: Our client just joins a specific channel on all networks and detects if more than one client is there, thus concluding that the networks controlled by several C&C servers are linked. Surprisingly, many networks are linked.
[IMAGE] |
|
|
|||||||||||||||||||||||
|
|
 |  |  | |  | |  | |  | |  | |  | |  | |  | |
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
