Scan of the Month Challenge - Scan 27

Massimo Buso -

April 2003

Last modified: Milan, 26 April 2003


In early March 2003, the Azusa Pacific University Honeynet Project deployed an unpatched Windows 2000 honeypot having a null (blank) administrative password. The challenge is based on logs from five days of honeypot operation, collected using Snort and cleaned from irrelevant traffic. The mission is to analyze the log file in order to answer the questions below.


What is IRC?


IRC (Internet Relay Chat) provides a way of communicating in real time with people from all over the world. It consists of various separate networks (or "nets") of IRC servers, machines that allow users to connect to IRC.
[ ... ]
Generally, the user (such as you) runs a program (called a "client") to connect to a server on one of the IRC nets.

From RFC2810 (please consider RFC1459 as the original and basic RFC for IRC, while RFC2810/RFC2811/RFC2812/RFC2813 are actually updates; so RFC1459 is the reference for this document when IRC is involved):

The IRC Protocol is based on the client-server model, and is well suited to running on many machines in a distributed fashion. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other functions.


An IRC network is defined by a group of servers connected to each other. A single server forms the simplest IRC network. The only network configuration allowed for IRC servers is that of a spanning tree where each server acts as a central node for the rest of the network it sees. A sample small IRC network follows:

                                     A        D---4
                                 2--/ \      /
                                      /      \
                                     3        E

             Servers: A, B, C, D, E         Clients: 1, 2, 3, 4

The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).

What message is sent by an IRC client when it asks to join an IRC network?


The recommended order for a client to register follows (item 1. is not mandatory):

  1. Pass message (connection password)
    PASS <password>
  2. Nick message
    NICK <nickname> [ <hopcount> ]
  3. User message
    USER <username> <hostname> <servername> <realname>

After registration, the JOIN message is used by a client to start listening a specific channel:

What is a botnet?

A botnet is a federation of IRC bot, logically group together thanks to IRC distributed architecture. An IRC bot is a program which connects to an IRC server, joins a specific channel and awaits for commands.

What are botnets commonly used for?

Illegitimate use of bots are IRC channel takeovers (IRC wars), remote access/backdoors, DDOS (Distributed Denial Of Service). Of course, as usual, the botnet concept is not malicious in principle, you can use for example for file sharing, but commonly this name addresses some sort of illegal use.

What TCP ports does IRC generally use?

IANA registered ports for IRC are:

ircu 6665-6669/tcp IRCU
ircu 6665-6669/udp IRCU

In the real Internet world, the most common used port is 6667/tcp and udp is not used because of reliability. Anyway IRC servers tipically listen on several other ports by default including 6660-6669/tcp and 7000/tcp.

What is a binary log file and how is one created?

In this area the term "binary log file" means raw packet logging into a file. Tcpdump and ethereal can save the packets they capture into a binary log file by using "-w <filename>". Snort can produce binary log file in a tcpdump binary format by using a line in the snort configuration file like

output log_tcpdump: <filename>
The tcpdump format (it would be better to call it libpcap format) is not the only one; for example others are snoop/novell LANalyzer/MS network monitor and many more.

What IRC servers did the honeypot, which has the IP address, communicate with?

Looking for TCP connections originated from the honeypot towards outside, we use tcpdump with a filtering expression to capture SYN/ACK packets incoming from outside servers (second phase of TCP/IP three-way handshaking):

tcpdump -n -nn -r sotm27 'tcp and dst host and tcp[13]==18'
By using command above, we build the pipeline:
tcpdump -n -nn -r sotm27 'tcp and dst host and tcp[13]==18'|cut -d ' ' -f 2|sort|uniq
and the output is (each line is in the form <A.B.C.D IP address>.<TCP PORT>):

So IRC servers are:

During the observation period, how many distinct hosts accessed the botnet associated with the server having IP address

First let's examine the traffic generated from/to the IRC server IP We use the textual version of ethereal in this way:

tethereal -x -n -l -r sotm27 'ip.addr== and tcp.port==6667 and irc'
After playing a little bit with the text/hex dump view of our traffic, we decide to write down a little piece of code to print the TCP payload of the interesting packets. The fact of the matter is that ethereal's IRC protocol support is not as strong as we need. No fear: we need only to print the raw TCP payload.
/* Compiled under RedHat 7.3 with:
	gcc -o ircsniff -I/usr/include/pcap -Wall -lpcap ircsniff.c */

#include <stdio.h>
#include <string.h>
#include <pcap.h>
int main(int argc,char **argv)
	u_char emptymsg[]="\x20\x0d\x0a\x00\x00\x00";
	pcap_t *pcap_pkt;
	char ebuf[PCAP_ERRBUF_SIZE];
	struct pcap_pkthdr pcap_h;
	unsigned char *pkt;
	int i;

	pcap_pkt = pcap_open_offline(argc!=2?"-":argv[1],ebuf);
	while ( (pkt=(u_char *)pcap_next(pcap_pkt,&pcap_h)) != NULL )
		if ( !(pcap_h.caplen==60 && !memcmp(pkt+54,emptymsg,6)) ) /* not empty msg */
			for (i=54;i<pcap_h.caplen;i++) printf("%c",*(pkt+i)); 
	return 0;

This piece of code needs libpcap library to be compiled. Minimal approach is used: no error management, no clean parameters management, etc., just it should work for our current job. If it's called exactly with one argument then this must be the filename of tcpdump/pcap binary file from which packets are read, otherwise the standard input is used. Each packet is considered only from each 55th byte, so as to print the TCP payload only.

Using our 'ircsniff' program:

tethereal -l -w- -r sotm27 'ip.addr== and tcp.port==6667 and irc'|./ircsniff > irc.

the file "irc." we get contains (partial):

NOTICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No Ident response
NOTICE AUTH :*** Found your hostname
NICK rgdiuggac
USER rgdiuggac localhost localhost :rgdiuggac 001 rgdiuggac :Welcome to the Internet Relay Network rgdiuggac 002 rgdiuggac :Your host is[], running version 2.8/hybrid-6.3.1
NOTICE rgdiuggac :*** Your host is[], running version 2.8/hybrid-6.3.1 003 rgdiuggac :This server was created Sun Jan 19 2003 at 19:04:03 PST 004 rgdiuggac 2.8/hybrid-6.3.1 oOiwszcrkfydnxb biklmnopstve 005 rgdiuggac WALLCHOPS PREFIX=(ov)@+ CHANTYPES=#& MAXCHANNELS=20 MAXBANS=25 NICKLEN=9 TOPICLEN=120 KICKLEN=90 NETWORK=XNet CHANMODES=be,k,l,imnpst EXCEPTS KNOCK MODES=4 :are supported by this server 251 rgdiuggac :There are 0 users and 4752 invisible on 4 servers 252 rgdiuggac 1 :IRC Operators online 254 rgdiuggac 4 :channels formed 255 rgdiuggac :I have 346 clients and 1 servers 265 rgdiuggac :Current local  users: 346  Max: 348 266 rgdiuggac :Current global users: 4752  Max: 4765 250 rgdiuggac :Highest connection count: 349 (348 clients) (378 since server was (re)started) 375 rgdiuggac :- Message of the Day - 372 rgdiuggac :- - WELCOME TO AMERICA ONLINE'S - IRC SERVER 372 rgdiuggac :- 372 rgdiuggac :- - !!!   WARNING WARNING WARNING WARNING   !!! 372 rgdiuggac :- - !!!  THIS SERVER SCANS FOR OPEN PROXIES !!! 372 rgdiuggac :- - !!!    PORTS: 8080,3128,80,1080,23      !!! 372 rgdiuggac :- -   So if this is a legal problem in your 372 rgdiuggac :- -     country please disconnect NOW! 372 rgdiuggac :- -  We do this to make your IRC experience 372 rgdiuggac :- -  more enjoyable. 376 rgdiuggac :End of /MOTD command.
:rgdiuggac MODE rgdiuggac :+i
MODE rgdiuggac -x
MODE rgdiuggac +i
JOIN #xx :sex0r


Interesting information can be uncovered such as:

Now we are close to the answer: "how many bots populate the botnet".

It's worth to remember that when a JOIN command - used to join an IRC channel - is accepted successfully by an IRC server then it sends back the list of users who are on the channel. If we assume an exact match between users and bot compromised site, in this way we can calculate the number of hosts on the botnet.

The command response code to use is 353 - RPL_NAMREPLY, so we can filter messages like:

grep ' 353 rgdiuggac #xàéüîéðìx' irc.
And finally we build a pipeline with the grep command above and a perl command to clean out just the "grepped" part above:
perl -p -e 's| 353 rgdiuggac #xàéüîéðìx :| |g'

So the final command is:

grep ' 353 rgdiuggac @ #xàéüîéðìx' irc. | perl -p -e 's| 353 rgdiuggac @ #xàéüîéðìx :| |g' > irc.

So now the file "irc." contains the list of users space-separated. Rapidly we do the grand total:

    cat irc. | tr -s ' \n\r' '\n' |sort|uniq|less|wc -l
and the result is 3458.
Because the first line is a pure newline character, the very final number of hosts on the botnet is 3457.

Assuming that each botnet host has a 56 kbps network link, what is the aggregate bandwidth of the botnet?

Because the number of bots compromised host is 3457 then the aggregate bandwidth is
3457 * 56 kbps, which approx equals to 189 Gbps

What IP source addresses were used in attacking the honeypot?

Our analysis is done using a different approach for UDP,TCP and ICMP. The UDP traffic from outside can be processed by

tcpdump -n -nn -r sotm27 'udp and dst host'|cut -d ' ' -f 2|cut -d '.' -f 1-4|sort|uniq
Giving as a result 113 hosts from 100 class B subnets.

TCP traffic from outside can be found running tcpdump and use a capture filter to get packets originating from the honeypot with SYN / ACK flags both set (second phase of the TCP three-way handshaking of a external-originated TCP session):

tcpdump -n -nn -r sotm27 'tcp and src host and tcp[13]==18'|cut -d " " -f 4|cut -d "." -f 1-4|sort|uniq
Giving as a result 69 hosts from 67 class B subnets.

Using again tcpdump we discover that no other protocol except UDP and TCP are in our binary log file:

tcpdump -n -nn -r sotm27 '!(udp or tcp)'

Combing the two results obtained for TCP and UDP we have the following list of 128 attacking hosts:

What vulnerabilities did attackers attempt to exploit?

Snort will be used to uncover potential attacks to the honeypot. We use the standard stable ruleset and the following configuration file (suppose it's located in "/etc/snort/snort.conf"):

var AIM_SERVERS [,,,,,,,,]
var RULE_PATH /etc/snort


preprocessor frag2
preprocessor stream4: detect_scans
preprocessor stream4_reassemble
preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor bo: -nobrute
preprocessor telnet_decode
preprocessor conversation: allowed_ip_protocols all, timeout 60, max_conversations 32000


output alert_full: snort_full
output alert_fast: snort_fast


include classification.config
include reference.config


include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/local.rules
we omitted all the "include" lines for each snort rule file: all available rule file is included.
We will run snort with the configuration file above onto the binary log file by using
snort -c /etc/snort/snort.conf -r sotm27
We summarize snort processing with the following part of the standard output during snort execution:

Snort processed 54536 packets.
Breakdown by protocol:                Action Stats:

    TCP: 54350      (99.659%)         ALERTS: 67        
    UDP: 186        (0.341%)          LOGGED: 67        
   ICMP: 0          (0.000%)          PASSED: 0         
    ARP: 0          (0.000%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 0          (0.000%)

A first inspection to the alert (fast log "snort_fast") suggests to eliminate a FP (False Positive), the one identified with SID (Snort ID) 615 - SCAN SOCKS Proxy attempt.

Then we can trace the IP addresses of the offending hosts by using:

grep -v ':615:' snort_fast|perl -p -e 's|^.*\s(\S+):\S+ ->*|$1|g' | sort | uniq

and so we have back:

The total number of the above hosts is 48. Two possible attack types are indentified by snort:

The first type rappresents the this year most famous worm based on a known vulnerability on Windows 2000 and SQL 2000. Only W2k sp3 or bug fixed systems are immune. Attacks of this type use 1434/udp port of the honeypot. The confirmation of attacks success will be done in the next section.

The second type rappresents attempts to inject a shellcode into an ip session (look at snort rule of sid 1390) which in our case is an HTTP session. The possible attack could have exploit a race condition in the Microsoft web sever (buffer overflow) and later a shellcode is tryed. As a matter of fact Microsoft web servers unpatched (our case) suffer a lot of vulnerabilities (i do not want to start a religion war here): possible candidate!

At a very end we have to notice that because the honeypot administrator password is very trivial (blank password) then sessions not considered by snort (e.g. NBT - NetBios over TCP/IP) are dangerous. We will consider this in the next section.

Which attacks were successful?

We start collecting protocol statistics about the binary log file:

tethereal -n -z io,phs -R '!frame' -r sotm27
Protocol Hierarchy Statistics
Filter: frame

frame                                    frames:54536 bytes:17247037
  eth                                    frames:54536 bytes:17247037
    ip                                   frames:54536 bytes:17247037
      udp                                frames:186 bytes:49962
        nbns                             frames:129 bytes:26852
        data                             frames:2 bytes:120
        dcerpc                           frames:55 bytes:22990
      tcp                                frames:54350 bytes:17197075
        nbss                             frames:3769 bytes:2219209
          smb                            frames:2506 bytes:511805
            dcerpc                       frames:20 bytes:3800
            pipe                         frames:1276 bytes:258208
              dcerpc                     frames:1259 bytes:243638
                samr                     frames:523 bytes:109330
                  malformed              frames:1 bytes:1138
                srvsvc                   frames:4 bytes:1416
              data                       frames:17 bytes:14570
            data                         frames:9 bytes:12466
          data                           frames:69 bytes:104466
            nbss                         frames:13 bytes:19682
              data                       frames:1 bytes:1514
                nbss                     frames:1 bytes:1514
              nbss                       frames:1 bytes:1514
                nbss                     frames:1 bytes:1514
                  nbss                   frames:1 bytes:1514
                    nbss                 frames:1 bytes:1514
                      nbss               frames:1 bytes:1514
                        nbss             frames:1 bytes:1514
        http                             frames:12028 bytes:11481571
        data                             frames:918 bytes:185975
        ssl                              frames:1 bytes:105
        irc                              frames:9809 bytes:1632635
As already noted, no ICMP packets flows from/to the honeypot. This means that any UDP session from outside have found honeypot UDP port open because no "ICMP Port Unreachable" packet is sent back.
Now UDP sessions to the honeypot can be uncovered by
tcpdump -n -nn -r sotm27 'udp and dst host'|cut -d ">" -f 2|cut -d "." -f 5|cut -d ":" -f 1|sort|uniq
and the result is: 137/udp, 1434/udp, 28431/udp.
A following analysis focused specifically onto UDP port 28431 permits to exclude this as an attack.

Similarly to what done for UDP, we would like to collect TCP sessions from outside to the honeypot. By using tcpdump we are looking for TCP packets with flags SYN and ACK active and originated from the honeypot (same idea already used before):

tcpdump -n -nn -r sotm27 'tcp and src host and tcp[13]==18' | cut -d "." -f 6 | cut -d " " -f 1 | sort | uniq
and the result is: 25/tcp, 80/tcp, 135/tcp, 139/tcp, 445/tcp, 4899/tcp.

So a summary of open ports in the whole binary file are:

service ports
smtp 25/tcp
nbt 135/tcp ; 139/tcp ; 445/tcp ; 137/udp
http 80/tcp
radmin 4899/tcp
sql dcerpc 1434/udp

So the suspect that the SQL worm attack were successful is very high. The final word is given by a statistical analysis of the packets over the time:

tethereal -x -n -tad -r sotm27 -R '!frame' -z io,stat,1800
The output of this command shows that there are holes in the bandwidth, sometimes and for hours, just when the 1434/udp packet arrived. This is exactly the effect of the worm; SQL work attack: success!

Then, we have to confirm the shellcode injection into the MS web server. From the snort log file we have that the host originating the attack has IP; then we use tethereal to look to the session it generates:

tethereal -l -x -n -r /root/sotm27 -R 'ip.addr== and http'

We can argue that (ordering by time from the oldest to the newest event):

  1. Browsing home page (with lot of attractive messages for an attacker)
  2. Attempt to exploit the well known '.ida' buffer overflow to inject a x86 shellcode (packet 1839-1840)
  3. Second attempt, same idea (maybe something was changed such as padding characteristics) (packet 1888-1889)
  4. Third and others attempts happen, up to a total number of 11 attempts

Looking through packets from 1841 to 1887 we can suppose that the effect of the malicious code should be to open a socket on the honeypot at port 99/tcp. The attacker is looking for that but that's not happen: attack unsuccessfull!

We are missing two issues:

  1. radmin, Software for Remote Administration
  2. nbt, NetBios over TCP/IP

The first issue, radmin, can be investigated by:

tcpdump -n -nn -r sotm27 'dst host and tcp dst port 4899'|cut -d ' ' -f 2|cut -d '.' -f 1-4|sort|uniq
What results from here is that only the host of IP has session to this tcp port.

However a close analysis:

tethereal -n -l -r sotm27 -R 'ip.addr== and tcp.port==4899'
reveals that at the beginning of the packet captured this port was not opened and this up to packet 1355-1356, and only at packet 2070-2071-2072 the tcp three-way handshaking successfully established a socket.

So the honeypot was violated by host IP, and this happens in the range of packets from 1357 to 2069. This happens exploiting NBT sessions, last chance. In fact the attacker by exploiting the weakness of the Administrator password, copied the radmin server into the honeypot and the put it into execution.

What did you learn about analysis as a result of studying this scan?

Firstable, i understand for what's better tcpdump and for what ethereal, that is the first is better for up-to ISO/OSI level 3 analysis, while ethereal for 4 to 7.

Second, I have studied botnet a little and i have to say that ideas behind are very fashinated.

Finally, to find common attacks is best to think simple.

How do you anticipate being able to apply your new knowledge and skills?

Blocking NBT traffic at border routers.
Enforcing password policy (host basis and eventually at the Domain Controller)
Upgrading operating systems and installed software according to vendors bug/security fixing

How can we improve the SotM challenge? What would you like to see added? What would you like to see done differently?

Minor issues: