Check out the new USENIX Web site.

Botnet Examples

Let us look at three examples which illustrate the operation of our algorithm. Table [*] gives us three items from our evil channel report. The purpose of this selection is to illustrate, on the one hand, the effectiveness of our algorithm in detecting evil channels while on the other hand showing some borderline cases that require additional analysis (e.g., examining port reports) First, we present a botnet client mesh. By definition, the server is off-campus and a few hosts have been captured on-campus to become part of the botnet. We look at two sub-sections of the hourly IRC report to find our evil channel which is named "F7". We look at our evil channel sort, and discover that F7 shown in table [*] is named as a channel in that list and occupies a high rank in the list.

Table: Malign and normal IRC Client Botnet - Evil Channel Report
channel msgs joins privmsgs ipcount wormyhosts evil
F7 118 19 99 6 4 E
s3reporter 2259 25 2234 3 1 E
thespicebox 23 8 15 2 1 E

Channel F7 is high in the evil channel list simply because it has 4 out of 6 hosts with high work weights. The "evil" flag at the end of the column is set to E if a potential evil channel has more than 1 anomalous host. Next we look at the report sub-section which breaks host statistics out for the channel F7.

Table: Malign and Benign Channels - Channel/Host Report
channel/ip tmsg tjoin tping tpong tprivmsg maxchans maxworm server  
F7/net1.1 1205 24 377 376 428 2 42 H  
F7/net1.2 113 6 39 43 25 1 96 H  
F7/net1.3 144 2 60 61 21 1 94 H  
F7/net1.4 46 3 12 14 17 1 90 H  
F7/net1.5 701 2 343 345 11 1 90 H  
F7/net2.1 1300 19 587 593 101 1 16 S  
s3reporter/net1.1 3949 25 844 846 2234 1 5 S  
s3reporter/net2.1 6899 36 794 794 5275 2 90 S  
s3reporter/net3.1 4525 21 704 702 3098 2 19 S  
thespicebox/net1.1 3106 101 433 661 1911 2 83 H  
thespicebox/net2.1 10943 373 1828 2037 6705 4 43 S  

In table [*] we see the part of the report that shows hosts in a channel. In channel F7, we have one remote server and five infected local hosts. Four of those hosts have very high maximum work weights. We know from experience with the work weight (and also by looking at logs from both Ourmon and other systems) that the hosts are performing SYN scanning. Ourmon logs for the syn tuple will typically show that the hosts in question have been performing scanning aimed at Microsoft exploits on port 445 (typically lsass-based exploits, for example, see [4]).

We have used ngrep in the past to prove beyond a shadow of a doubt that examples like our F7 botnet client are indeed malign. At this point in time, we no longer feel the need to use a tool like ngrep to prove that ourmon has detected an evil mesh. However the reader might desire to see such proof and in addition ngrep can still be very useful as an aid in host forensics. For example, one may be able to gather valuable clues about the exploit used. An ngrep sent from a local client to the server in question (net2.1) showed messages like the following:

# ngrep -q host net2.1
T net1.1:1053 -> net2.1:30591 [AP]^
  PRIVMSG #F7 :[Lsass]: Fuxed IP: net1.2

Here we see a report from a bot client back to the server that host net1.2 has been exploited. The exploit used is also mentioned.

The other two examples in table [*] are not evil channels. s3reporter is a IRC game (which is why all participating IP addresses are marked as servers) for which we sometimes get a high work weight. However, since the high work weight is associated with a remote host (see table [*]), we do not consider it further. The third example has a local IP host with a high work weight which implies evil channel. However, this is a borderline case (with only one client) where the high work weight may be because of software glitches (e.g., meetingmaker loss of server causes this type of bot-like behavior) or a p2p outage of some sort. These types of channels require additional analysis where we need to examine port reports in more detail. Some of the specifics that we look for include, for example,

Thus, in the end, while out algorithm clearly shows the presence of evail botnets, for many boderline cases, we need to resort to additional analysis.

root 2006-06-05