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.
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.
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,
root 2006-06-05