Honeynet Scan of the Month 27

April 2003

Azusa Pacific University Honeynet Project
 Windows 2000 Honeypot Analysis
Bill McCarty, Ph.D. bmccarty@apu.edu
Patrick McCarty mccartyp@apu.edu

Introduction


From the challenge,
"In early March 2003, the Azusa Pacific University Honeynet Project deployed an unpatched Windows 2000 honeypot having a null (blank) administrative password. During its first week of operation, the honeypot was repeatedly compromised by attackers and worms exploiting several distinct vulnerabilities. Subsequent to a successful attack, the honeypot was joined to a large botnet. During operation of the honeypot, a total of 15,164 distinct hosts were seen entering the botnet. The challenge is based on logs from five days of honeypot operation, collected using Snort. The logs have been edited to remove irrelevant traffic and combined into a single file. Also, IP addresses and certain other information have been obfuscated so that the identity of the honeynet is not readily apparent. Your mission is to analyze the log file in order to answer the questions below. Be sure you review the submission rules at the SotM challenge page before submitting your results."

This document presents the judging team's write up of the challenge. Like the reports submitted by the community, this report was prepared under significant time constraints. Although its authors exercised care in its preparation, it likely contains significant errors and omissions. Consequently, its authors disclaim responsibility for the reliability of any information contained herein.

In considering how to organize and present their report, the authors decided to focus their efforts on explaining how they analyzed the data rather than on the conclusions they drew. Several reports submitted by the community provide very clear and comprehensive descriptions of the attacks recorded in the honeypot's logs. The authors hope that beginning analysts will find this approach instructive and helpful. The authors also hope to stimulate discussion among more experienced analysts concerning tools and methods of analysis.

One of the central problems confronting the security analyst is lack of time in which to thoroughly investigate every potential attack. This challenge, which was based on five days of observation that saw dozens of attacks, was difficult—perhaps impossible—to thoroughly analyze in the time available. In that respect, it reflected the situation faced daily by security analysts. The authors, who are not professional security analysts, used a variety of techniques and heuristics intended to make the best use of time available for analysis. The authors are eager to learn more and better techniques for maximizing the effectiveness of security analysts operating in time-constrained situations and invite ongoing discussion of this issue on the honeypots email list and other forums.

Tools


We used the following tools to accomplish our analysis, running them under Red Hat Linux 7.3:
* Note: By default, Argus enables several unwanted options that cannot be disabled on the command line. To replicate our analysis, please rename or remove your ra configuration. By default, the configuration file is /etc/ra.conf.

Setup


First, we downloaded the sotm27.gz file from the Honeynet website and verified the value of its MD5 checksum.

$ wget http://www.honeynet.org/misc/files/sotm27.gz
--20:51:11--  http://www.honeynet.org/misc/files/sotm27.gz
           => `sotm27.gz'
Resolving www.honeynet.org... done.
Connecting to www.honeynet.org[63.107.222.112]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12,914,607 [application/x-gzip]

100%[=======================================================>] 12,914,607   146.21K/s    ETA 00:00

20:52:38 (146.21 KB/s) - `sotm27.gz' saved [12914607/12914607]

$ echo 'b4bfc10fa8346d89058a2e9507cfd9b9  sotm27.gz' >sotm27.gz.md5|md5sum -c sotm27.gz.md5
sotm27.gz: OK

Next, we gunzipped the file sotm27.gz.

$ gunzip sotm27.gz
$ ls -l
total 17792
-rw-r--r--    1 root     root     18119637 Mar 22 14:24 sotm27
-rw-r--r--    1 root     root           44 Apr 29 20:59 sotm27.gz.md5

Next, we ran the file utility on the file, to verify its file type.

$ file sotm27
sotm27: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 1514)

Based on the challenge instructions, we now know that the log file contains a raw binary tcpdump packet capture of ethernet frames. We proceed to process the log file using several tools that produce output useful in subsequent analysis .

First, we run tcpflow, which extracts the application layer data from each TCP connection into a separate file:

$ mkdir tcpflow
$ cd tcpflow
$ tcpflow -r ../sotm27
$ ls |wc -l
   1164
$ ls -l *06667*
-rw-r--r--    1 root     root          282 Apr 30 00:05 063.241.174.144.06667-172.016.134.191.01133
-rw-r--r--    1 root     root           55 Apr 30 00:05 172.016.134.191.01133-063.241.174.144.06667
-rw-r--r--    1 root     root           61 Apr 30 00:05 172.016.134.191.01139-217.199.175.010.06667
-rw-r--r--    1 root     root         1046 Apr 30 00:05 172.016.134.191.01152-209.196.044.172.06667
-rw-r--r--    1 root     root      1082018 Apr 30 00:05 209.196.044.172.06667-172.016.134.191.01152
-rw-r--r--    1 root     root          249 Apr 30 00:05 217.199.175.010.06667-172.016.134.191.01139

We often use Unix tools such as grep, less, and strings to quickly and conveniently search TCP application-layer data presented in the files generated by tcpflow.

Next, we run argus, which aggregates TCP/IP datagrams into units called transactions:

$ argus -X -r sotm27 -w sotm27.argus
$ ra -A -c -n -r sotm27.argus > sotm27-argus.txt
$ cat sotm27-argus.txt |grep 6667|tail  # Grab the last few IRC transactions to illustrate the format.

# Format: time proto srchost dir dsthost pktsin pktsout bytesin bytesout status
06 Mar 03 00:18:39   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  38     39     0      2630      EST
06 Mar 03 00:19:39   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  41     40     0      2956      EST
06 Mar 03 00:20:41   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  47     46     0      3145      EST
06 Mar 03 00:21:42   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  42     44     19     3062      EST
06 Mar 03 00:22:43   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  31     34     0      2347      EST
06 Mar 03 00:23:44   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  35     35     0      2480      EST
06 Mar 03 00:24:44   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  44     47     0      3604      EST
06 Mar 03 00:25:45   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  35     35     19     2305      EST
06 Mar 03 00:26:47   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  43     45     0      3388      EST
06 Mar 03 00:27:47   tcp  172.16.134.191.1152  ->  209.196.44.172.6667  5      5      0      335       EST

Because the data set produced by argus contains less detail than the log file, it provides a useful overview of honeypot activity. Moreover, argus distinguishes TCP clients from TCP servers, by listing the client—that is, the host that initiated a TCP connection— in column 6 and the server in column 8. See the argus man page for details. We often use Unix tools such as grep, awk, and sed to quickly and conveniently query the argus report file.

Beginning Questions

We now address the beginning questions associated with the challenge.

  1. What is IRC?

    2. IRC is a real-time internet chat protocol that utilizes Internet Protocol ("IP," which is defined in RFC791 and RFC1349) for transport, was originally defined by RFC1459 and subsequently updated by RFCs 2810, 2811, 2812, and 2813. An IRC network consists of servers and clients, organized in a client-server architecture. IRC features channels that divide the server into separate distinct conversations. Channels are sometimes referred to as "chat rooms."

    For more information about IRC see the FAQ at mirc.com, or various documents available at irchelp.org.

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

    3. To establish an IRC session as specified in RFCs 1459 and 2812, a client must send two messages and may optionally send a third message. The RFCs refer to these messages as "commands." First, the client must send the USER command. The USER command contains the following arguments: <username> <hostname> <servername> <realname>. Second, the client must send the NICK command. The NICK command contains the argument: <nickname> and optionally contains the parameter <hopcount>, which is used only in server-to-server communication. Per the RFC, "Only after both USER and NICK have been received from a client does a user become registered."

    RFC2812 also specifies an optional connection password command:
    "The PASS command is used to set a 'connection password.' The optional password can and MUST be set before any attempt to register the connection is made. Currently this requires that user send a PASS command before sending the NICK/USER combination."
    After a client is registered to an IRC server, a JOIN command is generally issued in order to join a channel. In addition to a parameter specifying the channel to be joined, the JOIN command can optionally include a channel key. A channel key is used as a password, restricting access to a channel to only those users possessing it.
    The user goes not generally type these and other IRC commands. Instead, the user manipulates a user interface provided by an IRC client, which assembles and sends commands on behalf of the user. All IRC messages sent across the network are sent in plain ASCII text format. The significance of this is that analysis of IRC traffic can be done on a raw packet dump, without having to parse and reformat binary data.

  3. What is a botnet?

    4. A bot is an automated client that is remotely controlled via a network. A set of related bots collectively comprise a distributed communication network called a botnet. IRC is often used as the communication medium linking a botnet.

  4. What are botnets commonly used for?

    5. Botnets are most commonly used for distributed denial of service (DDoS) attacks, flooding, and IRC wars. Botnets are sometimes used for legitimate purposes, such as file or data transfer purposes. Often, the operators of malicious botnets run their bots on compromised systems. Botnets use IRC as a means of communication and control among bots and between bots and their owner.

  5. What TCP ports does IRC generally use?

    6. Public IRC servers generally run on TCP port 6667. Some IRC servers listen on a range of ports, typically TCP ports 6660-6670. Occasionally, an IRC server is run on port 7000, however this port is officially registered to a different service. The IRC service has several other TCP and UDP ports allocated by IANA to its use. However, the other ports are not commonly used and IRC has not been implemented using the UDP protocol.

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

    7. In this context, a binary log file is a file that contains raw packet data. The file that is the basis of this challenge was generated using the libpcap library. libpcap is a common packet capture library used by many capture tools such as tcpdump and snort. These and many programs can accept a binary log file as input, rather than reading frames directly off the wire.

    Here is are example commands showing the use of tcpdump and snort to write binary log files.

    $ tcpdump -i eth0 -w binary.log
$ snort -b -L binary.log

    Such binary log files can be subsequently read by commands such as these:

    $ tcpdump -r binary.log
$ snort -r binary.log

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

    8. The honeypot attempted to communicate with the IRC servers having IP addresses listed in the table below.

    $ grep '\.6667' sotm27-argus.txt \ # Grab only transactions which involve port 6667
    | sed "s/.*->[ ]*//g" \        # Get rid of the first part of the line
    | sed "s/.6667.*$//g" \        # Get rid of the last part of the line, leaving only the IP
    | sort -t. -u -k1,1n -k2,2n -k3,3n -k4,4n # Sort it, and provide only unique IPs
63.241.174.144
66.33.65.58
209.126.161.29
209.196.44.172
217.199.175.10
    This analysis discloses attempted communication with IRC servers running only on the standard port, TCP 6667. Moreover, this analysis does not indicate whether the attempt was successful. The files created by tcpflow indicate which attempts were successful: 
    $ ls -l *06667*
-rw-r--r--    1 bmccarty bmccarty      282 Apr 30 20:06 063.241.174.144.06667-172.016.134.191.01133
-rw-r--r--    1 bmccarty bmccarty       55 Apr 30 20:06 172.016.134.191.01133-063.241.174.144.06667
-rw-r--r--    1 bmccarty bmccarty       61 Apr 30 20:06 172.016.134.191.01139-217.199.175.010.06667
-rw-r--r--    1 bmccarty bmccarty     1046 Apr 30 20:06 172.016.134.191.01152-209.196.044.172.06667
-rw-r--r--    1 bmccarty bmccarty  1082018 Apr 30 20:06 209.196.044.172.06667-172.016.134.191.01152
-rw-r--r--    1 bmccarty bmccarty      249 Apr 30 20:06 217.199.175.010.06667-172.016.134.191.01139
    Using less, it's possible to determine that significant communication occurred only with the server having IP address 209.196.044.172. For instance, the server having IP address 63.241.174.144 timed out: 
    $ less 063.241.174.144.06667-172.016.134.191.01133
NOTICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No Ident response
NOTICE AUTH :*** Found your hostname
:irc4.aol.com 433 * eohisou :Nickname is already in use.
ERROR :Closing Link: [eohisou@255.255.255.255] (Connection Timed Out)

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

    9. During the observation period 4,793 JOIN and 4,922 QUIT messages were seen on the wire. These messages were associated with 5,580 distinct hosts, as determined by unique host name or IP address. However, this is not the only possible way of counting the number of hosts.

    When the compromised honeypot joined the botnet, the IRC server reported 4,752 users online among the four servers in the IRC network. However, this count of users could include legitimate non-bot users. Moreover, a single host having multiple connections to the server would be multiply counted.

    Finally, the output of the NAMES command issued when the honeypot joined the channel indicates that 3,457 distinct nicknames were present in the botnet channel at that time. However, at other times, more or fewer nicknames may have been present. The question asks how many hosts accessed the botnet during the observation period. So, this count isn't as appropriate an answer to the question as the first count. Nevertheless, this count better reflects the known DDoS capacity of the botnet at a particular moment in time than either of the other two counts.
    Here's how these counts were obtained. First, a count of distinct hosts on the botnet, as identified by hostname or ip address:

    $ ls -l 209.196.044.172.06667-172.016.134.191.01152
-rw-r--r--    1 root     root      1082018 Apr 30 00:05 209.196.044.172.06667-172.016.134.191.01152
$ grep -e 'JOIN' 209.196.044.172.06667-172.016.134.191.01152 \
    | sed -e 's/^[^@]*@//' \
    | sed -e 's/ .*//' \
    | sort -fu > hosts ; wc -l hosts
   4793 hosts
$ grep -e 'QUIT' 209.196.044.172.06667-172.016.134.191.01152 \
    | sed -e 's/^[^@]*@//' \
    | sed -e 's/ .*//' \
    | sort -fu > hosts ; wc -l hosts
   4922 hosts
$ grep -e 'JOIN\|QUIT' 209.196.044.172.06667-172.016.134.191.01152 \
    | sed -e 's/^[^@]*@//' \
    | sed -e 's/ .*//' \
    | sort -fu > hosts ; wc -l hosts
   5580 hosts

    Next, the user count as reported by the IRC server:

    $ grep "^[^ ]* 2[0-9][0-9]" 209.196.044.172.06667-172.016.134.191.01152
:irc5.aol.com 251 rgdiuggac :There are 0 users and 4752 invisible on 4 servers
:irc5.aol.com 252 rgdiuggac 1 :IRC Operators online
:irc5.aol.com 254 rgdiuggac 4 :channels formed
:irc5.aol.com 255 rgdiuggac :I have 346 clients and 1 servers
:irc5.aol.com 265 rgdiuggac :Current local  users: 346  Max: 348
:irc5.aol.com 266 rgdiuggac :Current global users: 4752  Max: 4765
:irc5.aol.com 250 rgdiuggac :Highest connection count: 349 (348 clients) (378 since server was (re)started)

    Finally, a count based on the output of the NAMES command:

    $ cat 209.196.044.172.06667-172.016.134.191.01152 \
    | grep "^:irc5.aol.com 353" \                               # Grab the NAMES output lines
    | sed "s/^:irc5.aol.com 353 rgdiuggac @ #x[^x]*x ://g" \    # Get rid of the prefix
    | tr ' ' '\n' \                                             # Translate spaces to newlines
    | tr -d "\15" \                                             # Get rid of a rogue carriage return
    | grep -v "^$" \                                            # Get rid of blank lines
    | sort -u \                                                 # Sort and remove duplicates (for fun)
    | wc -l                                                     # Get the linecount
   3457

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

    10. Taking the figure of 5,580 bots:
    5,580 bots * 56kbps = 312,480kbps aggregate bandwidth.

    The computation could be similarly performed based on other figures for the number of bots in the botnet. The point of the question was that the bandwidth available to the botnet—however the size of the botnet is reasonably determined—is enormous. The botnet has the capacity to seriously disrupt almost any Internet site.

Intermediate Questions

Generally, the official report is prepared independently of, and does not extensively reference, the reports of submitters. However, the large volume of traffic associated with this scan leads us to adopt a different approach in which we freely reference observations and conclusions of submitters.

Moreover, we organize our analysis around the target ports of attacks rather than the IP addresses of attackers. Doing so makes it cumbersome to consider the time sequence of related events and therefore risks ignorance of perhaps the most important clue associating stimuli and responses. However, it also reduces the number of cases that must be analyzed and therefore the time required to perform the analysis. The latter consideration was paramount, owing to the limited time available in which to prepare the analysis.

  1. What IP source addresses were used in attacking the honeypot?

    2. Traffic entering and leaving any honeypot can generally be classified as hostile. Therefore, we generate a complete list of the IP addresses of hosts that accessed the honeypot: 

    $ ra -A -c -n -r sotm27.argus \
    | grep -v man \
    | awk '{printf("%-21s\n%-21s\n",$6,$8)}' \
    | grep -v 172.16.134.191 \	
    | sed -e 's/\.[0-9]* *$//' \
    | sort -t. -u -k1,1n -k2,2n -k3,3n -k4,4n > sotm27-ips.txt
    The output from this command, which includes 171 IP addresses, is available here.

    As several submitters concluded, some of the honeypot traffic was apparently associated with downloading of a forensic toolkit subsequently used to analyze the compromised honeypot. Consequently, our list includes several hosts that seem not to have been associated with an attack. However, without specific knowledge of the activities performed by the honeypot operator, it's not possible to exclude such traffic with complete certainty. Therefore, a careful analyst must consider the possibility that each listed host attacked the honeypot.

  2. What vulnerabilities did attackers attempt to exploit?
  3. Which attacks were successful?

    4. These two questions are closely related and will be answered together.

    Several submitters relied upon Snort alerts as a means of identifying the vulnerabilities that attackers attempted to exploit. However, Snort generates alerts based on signatures. Therefore, Snort is not generally capable of identifying novel attacks of the sort that we hope to capture by deploying honeypots. Rather than rely on Snort, we choose to perform a more thorough analysis.

    However, detailed examination of traffic from all 171 hosts would be quite time consuming. So, we seek ways to exclude some hosts from analysis. Many of the hosts transmitted no application-layer data to the honeypot and therefore cannot have compromised it, unless we entertain the extreme possibility of a vulnerability in the TCP/IP stack itself. Strictly speaking, even these hosts may be said to have attempted to compromise the honeypot. But, in the case of this particular honeypot, the attempts were sufficiently feeble that we may hope to be forgiven for taking this shortcut.

    The following command extracts inbound traffic that involved transmission of application-layer data to the honeypot:

    $ ra -A -c -n -r sotm27.argus -  \
    | grep '\->.*172.16.134.191' \
    | awk '{bytes=$11+$12; if ($5!="man" && bytes>0) print $0; }' \
    > sotm27-attacks.txt
    The output from the command is available here.

    The command is successful in excluding outbound traffic because Argus is consistent in placing the IP address of the host that initiated a connection in column 6 of every report line, despite the direction of traffic flow. A very careful analyst might question the accuracy of Argus's determination, because packet logs may lack SYN or SYN-ACK packets important in determining the direction of a connection. However, given the large volume of data to be analyzed, we can hope to be forgiven this shortcut.

    Notice that only TCP and UDP traffic is shown. Although the honeypot's logs include ICMP traffic, that traffic was excluded from the log file provided for this challenge, in order to reduce file size.


    To determine the possible range of vulnerabilities, we generate a list of the destination ports targeted by the potential attacks: 

    $ awk '{printf("%3s %-21s\n",$5,$8)}' sotm27-attacks.txt \
    | sort -u

    Our list includes the following target ports:

    PortAssociated
    Protocol
    tcp/80HTTP
    tcp/139CIFS
    tcp/445CIFS
    tcp/4899Unknown
    udp/137NetBIOS
    udp/1434SQL Server
    udp/28431Unknown

    Ports tcp/4899 and tcp/28431 are not associated with services that were installed on the honeypot at the time of its deployment. Port tcp/4899 is commonly associated with the Radmin remote administration tool and port tcp/28431 is commonly associated with the Hack-A-Tack trojan. Therefore, we must consider the possibility that an attacker has installed these, or other, services after a successful attack.

    Attack on udp/1434

    Of the possible attacks, two are easily analyzed and can be eliminated from further consideration. The first of these is the possible attack on port udp/1434, associated with Microsoft's SQL Server. The following command reports this traffic:

    ra -A -c -n -r sotm27.argus - udp and port 1434 > sotm27-udp1434.txt
    The output from the command is available here.

    Notice that each request consists of 376 bytes of incoming data and that the honeypot does not appear to respond. This traffic is consistent with that associated with the Slammer worm.

    The following command isolates and examines this traffic:

    $ snort -devp -r sotm27 udp and port 1434 \
  | sort \
  | sed -e 's/^[0-9][0-9]\/[0-9][0-9]-[0-9][0-9].*//' \
  | sed -e 's/[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*:[0-9]* ->.*//' \
  | sed -e 's/^=+.*//' \
  | uniq -c \
  | sort -nr > sotm27-slammer.txt
    The output from the command is available here.

    Notice that each of the 55 packets has the same payload, as indicated by the line counts generated by the uniq command. The payload content is consistent with that elsewhere determined to have resulted from Slammer. The attack was not successful, because Slammer is known to cause compromised hosts to generate outbound traffic on udp/1434, intended to spread the worm. No such outbound traffic is present in the honeypot logs.

    However, the attack may have had an effect on the system. One submitter observed that the honeypot seems to have been temporarily knocked offline by one or more of these attacks. We did not verify this report. So, it is possible that, as the submitter concluded, the honeypot was running SQL Server and experienced one or more temporary denials of service as a result of attacks on udp/1434. We nevertheless chose to classify these attacks as ineffective, since they did not fully achieve what we regard as their intended result. We did not charge this difference of opinion against the score that we assigned to the submitter.


    Attack on udp/28431

    The second attack that is easily dismissed is the one associated with port udp/28341. The following command reports the associated traffic:

    $ ra -A -c -n -r sotm27.argus - udp and port 28431 \
    > sotm27-hackatack.txt
    The output from the command is available here.

    Notice that only one packet, containing a single byte of data, was transmitted to the honeypot. The source port was 28432, consistent with that associated with Hack-A-Tack. Also notice that the honeypot apparently did not respond to the packet. If the traffic was associated with the Hack-A-Tack trojan, the attack was unsuccessful, as demonstrated by the absence of response. However, it remains possible that the traffic did communicate with an unknown UDP service installed on the honeypot by an attacker. Forensic analysis of the honeypot might confirm or disconfirm this possibility. Based solely on examination of the log, our best judgment is that this attack was probably unsuccessful. Because the honeypot did not originally have a service running on udp/28432, it is all but certain that traffic on this port was not responsible for compromising the honeypot.


    Attack on udp/137

    The remaining attacks require somewhat more detailed analysis. Let's first examine the attacks on udp/137. The following command generates a detailed report of the attacks:

    $ tethereal -Vx -r sotm27 udp and udp.port == 137 > sotm27-udp137.txt
    The output from the command is available here.

    Port udp/137 is associated with NetBIOS Name Service (nbns). Attacks on this service generally attempt to discover information about a target host. The following command indicates that the attacks were generally successful:

    $ grep Flags: sotm27-udp137.txt |sort | uniq -ci
    129     Flags: 0x00
     65     Flags: 0x0010 (Name query)
     64     Flags: 0x8400 (Name query response, No error)

    The following command shows the information obtained by attackers, which consists of user, domain, and service names:

    $ grep Name: sotm27-udp137.txt |sort | uniq -ci
     64             Name: *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
     65             Name: *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00> (Workstation/Redirector)
     64             Name: <01><02>__MSBROWSE__<02><01> (Browser)
     28             Name: ADMINISTRATOR<03> (Messenger service/Main name)
     40             Name: INet~Services<1c> (Domain Controllers)
     40             Name: IS~PC0191<00><00><00><00><00><00><00> (Workstation/Redirector)
     24             Name: IWAM_PC0191<03> (Messenger service/Main name)
     64             Name: PC0191<00> (Workstation/Redirector)
     64             Name: PC0191<03> (Messenger service/Main name)
     64             Name: PC0191<20> (Server service)
     64             Name: SBM<00> (Workstation/Redirector)
     64             Name: SBM<1d> (Local Master Browser)
     64             Name: SBM<1e> (Browser Election Service)

    Rather than wade through the large volume of data generated in the detailed tethereal report, we use a small C program to analyze the requests. Alternatively, we could have used Snort to analyze the data in the same way that we analyzed the port udp/1434 data.

    $ gcc -o udpsniff -lpcap -I/usr/include/pcap udpsniff.c
$ ./udpsniff sotm27 'udp and port 137 and dst host 172.16.134.191' >sotm27-udpsniff.txt
    The output from the command is available here.

    We next analyze the program's output to determine whether several requests may be identical:

    $ cut -f 2 -d ' ' test |sort | uniq -ci| sort -n
    The output from the command is available here.

    As we suspected, the command discloses that only five discrete queries were sent among a total of sixty-five requests. Moreover, these requests differ only in the first two bytes, which contain the NetBIOS transaction ID, as determined by scanning the tethereal report. Consequently, analysis of a single query is sufficient to determine the effect of each transaction. This conclusion is bolstered by observation that each attack generated a response having a length of 283 bytes, except for a single request that seems not to have generated a response:

    $ ra -A -c -n -r sotm27.argus - udp and dst port 137 > sotm27-udp137-ra.txt
    The output from the command is available here.

    Inspection of a typical request and response shown in the tethereal report discloses that, apart from the information leakage accomplished by the successful probes of the NetBIOS Name Service, the attacks on port udp/137 caused no harm. So, we move on to consider the remaining attacks.


    Attack on tcp/139

    Port tcp/139 is associated with the NetBIOS Session Service (nbss) and Server Message Block Protocol (SMB). Attacks on this service generally attempt to connect to a shared folder. The following command extracts information about these attacks:

    $ ra -A -c -n -r sotm27.argus - tcp and port 139 | awk '{if ($11>0) print $0}' > sotm27-tcp139.txt
    The output from the command is available here.

    The report contains information about fifty-four transactions. Notice that, other than several transactions that had no payload, the transactions have four sizes. Most transactions consist of exactly 134 bytes. However, three transactions have other sizes; namely, 72, 390, and 411 bytes. Most transactions include brief replies by the session service, consisting of 4 or 8 bytes. Two transactions included longer replies, consisting of 146 bytes.

    The following command generates a detailed report of the attacks on port tcp/139:

    $ tethereal -Vx -r sotm27 tcp and tcp.port == 139 > sotm27-tcp139-details.txt
    The output from the command is available here.

    Using the application-layer data extracted via tcpflow, we determine that several of the connections transferred the same inbound data:

    $ cd tcpflow/tcp139
$ md5sum *-172.16.134.191* > md5dum.txt
$ cut -f 1 -d ' ' md5sum.txt | sort | uniq -c
     21 02bbacdad7786a5de951a4f46416bcf2
     11 291ad8657f45a25942ba086a186a0e8c
      1 58f59ff84bb6eb10c38ea3ebe47d47fc
      1 7b15f30f5fd59c4a2ef3a12f430adfa7
      8 8a4ad4d4f3e4744e4fbfe9dcd79ab2b8
     11 d6bcefb3b55db1126b2fc413e0cc649f
      1 f01d05bbb249ec73f0d5ee1d20904efa

    Therefore, we need examine only seven of the fifty-four connections. We arbitrarily choose an instance of each request:

    02bbacdad7786a5de951a4f46416bcf2  004.064.221.042.33220-172.016.134.191.00139
291ad8657f45a25942ba086a186a0e8c  061.177.154.228.01514-172.016.134.191.00139
58f59ff84bb6eb10c38ea3ebe47d47fc  210.022.204.101.02832-172.016.134.191.00139
7b15f30f5fd59c4a2ef3a12f430adfa7  024.197.194.106.02015-172.016.134.191.00139
8a4ad4d4f3e4744e4fbfe9dcd79ab2b8  024.161.196.103.64773-172.016.134.191.00139
d6bcefb3b55db1126b2fc413e0cc649f  062.201.096.159.62958-172.016.134.191.00139
f01d05bbb249ec73f0d5ee1d20904efa  216.170.214.226.04708-172.016.134.191.00139

    Then, we examine each instance by using tethereal. For example:

    $ tethereal -n -Vx -r sotm27 'ip.addr == 4.64.221.42 and tcp and tcp.port == 139' > sotm27-tcp139-example.txt

    A typical instance can be seen here. Tethereal discloses that the requests were aimed at accessing the shared C drive or the IPC$ share.

    Examining the remaining requests, we find that the server generally responded with a TCP RESET, as also shown in the Argus report generated earlier. However, two of the seven requests—the requests from 24.197.194.106 and 216.170.214.226, which attempted to access the IPC$ share—generated responses consisting of 146 bytes. These responses indicate that the server denied access to the IPC$ share. Host 210.22.204.101 issued a NetBIOS session request, but did not issue an SMB command.

    The following command confirms these results:

    $ grep Path: sotm27-tcp139-details.txt | sort | uniq -ci
     51         Path: \\PC0191\C
      2         Path: \\PC0191\IPC$


    Attack on tcp/80

    To analyze the traffic inbound to port tcp/80, we begin by extracting relevant lines from the argus report:

    $ ra -A -c -n -r sotm27.argus - tcp and dst host 172.16.134.191 and dst port 80 > sotm27-tcp80.txt
    The output from the command is available here.

    Most of the traffic originated from a host having IP address 24.197.194.106, which probed a variety of known web server vulnerabilities. However, most of its requests generated no response from the server. By using less and strings to examine the files generated by tcpflow, we satisfy ourselves that the host did not succeed in compromising the honeypot.

    We could similarly inspect the remaining traffic. Indeed, in order to be confident that we haven't overlooked an unexpected event, we'd have to do so. Nevertheless, we choose to take a shortcut, in order to show how we might focus our analysis efforts in order to make best use of limited available time. The following command discloses that only three hosts transmitted requests having a size of 100 bytes or more. Requests smaller than this are unlikely to be large enough to include a buffer overflow and shell code.

    $ awk '{if ($11>=100) printf("%-21s %5d  %5d\n",$6,$11,$12)}' sotm27-tcp80.txt > sotm27-tcp80-summary.txt
    The output from the command is available here.

    Examining the output, we see that only three hosts other than 24.197.194.106 transmitted suspicious requests:

    IP Address
    68.169.174.108
    210.22.204.101
    218.25.147.83

    Examining the relevant files generated by tcpflow, we see that host 68.169.174.108 seems to have sent routine HTTP requests:

    $ more 068.169.174.108.*
::::::::::::::
068.169.174.108.16378-172.016.134.191.00080
::::::::::::::
GET / HTTP/1.1
Host: 172.16.134.191
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,t
ext/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive

GET /pagerror.gif HTTP/1.1
Host: 172.16.134.191
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,t
ext/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Referer: http://172.16.134.191/
Cookie: ASPSESSIONIDQQQQGSDY=GJEPJAHAEEJPFKPODHGPPBOP

::::::::::::::
068.169.174.108.26956-172.016.134.191.00080
::::::::::::::
GET / HTTP/1.1
Host: 172.16.134.191
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,t
ext/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cookie: ASPSESSIONIDQQQQGSDY=GJEPJAHAEEJPFKPODHGPPBOP
Cache-Control: max-age=0

GET /pagerror.gif HTTP/1.1
Host: 172.16.134.191
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,t
ext/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Referer: http://172.16.134.191/
Cookie: ASPSESSIONIDQQQQGSDY=GJEPJAHAEEJPFKPODHGPPBOP
If-Modified-Since: Thu, 03 Jun 1999 23:13:40 GMT
If-None-Match: "0aa41b716aebe1:8e3"
Cache-Control: max-age=0

    On the other hand, host 210.22.204.101 has attempted a buffer overflow and access to the Windows shell, cmd.exe, eleven times:

    $ strings 210.022.204.101.0* |more
GET /NULL.IDA?CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC%u0aeb%ub890%ubcaf%u77e3%u0000%u0000%u838b%u0094%u0000%u408b
%u0564%u0150%u0000%ue0ff%u9090=x&

                                r


                                p

Z!ffffZ



                                q




PnHek7

&cmd.exe$ HTTP/1.1
Host: 172.16.134.191:80
GET / HTTP/1.0

    The buffer overflow seems to resemble one described by eEye, though the method of exploitation differs, being based on invocation of cmd.exe rather than shellcode. In any case, we see no evidence that this attack successfully compromised the honeypot. However, without more careful analysis, it's not possible to entirely eliminate this possibility.

    Similarly, host 218.25.147.83 appears to have conducted an unsuccessful Code Red II attack:

    $ strings 218.025.147.083.03634-172.016.134.191.00080
GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN[More 'N's here were trimmed]
  HTTP/1.0
8%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a  HTTP/1.0
Content-type: text/xml
HOST:www.worm.com
 Accept: */*
Content-length: 3569
:KERN
EL32
GetP
rocA
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
:LMTHu
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
CKCK
UWSVPj<
X^[_]
uK

    We judge the attack to have been unsuccessful because the honeypot did not itself begin attempting to spread the worm. However, more careful analysis would be required to confidently rule out the possibility that this is a quite subtle attack that masquerades as an unsuccessful Code Red II attack.
    To double-check our somewhat hasty conclusion that the honeypot was not successfully compromised, we examine responses from the server to inbound tcp/80 requests:

    $ mkdir inbound outbound
$ mv *-172.016.134.191.00080 inbound/
$ mv 172.016.134.191.00080-* inbound/
$ mv *172* outbound/

$ cd inbound
$ mv *-172* client
$ mv *172*  server

$ cd server
$ file *
172.016.134.191.00080-068.169.174.108.16378: data
172.016.134.191.00080-068.169.174.108.26956: ASCII English text, with CRLF line terminators
172.016.134.191.00080-210.022.204.101.01565: ASCII English text, with CRLF line terminators
172.016.134.191.00080-213.023.049.158.01445: ASCII text, with CRLF line terminators
$ strings * | less
[output omitted]

    Seeing nothing amiss, we proceed to the next set of attacks, those targeting port tcp/445.

    Attack on tcp/445

    Up to this point, we've seen several successful probes, but no attacks that have successfully compromised the honeypot. However, several attacks on port tcp/445, an alternate port for NetBIOS and SMB used by Windows 2000/XP, were successful.

    NetBIOS and SMB are relatively complex protocols with which many analysts are somewhat unfamiliar. The following references, especially the paper written by 2Lt. Chaboya, provide useful information on these protocols:


    We begin by determining the IP addresses of hosts that accessed port tcp/445:

    $ ra -A -c -n -r sotm27.argus - tcp and dst port 445 > sotm27-tcp445.txt
    The output from the command is available here.

    The following hosts are seen to have access the honeypot via port tcp/445:
    We now create a separate analysis file for each host, containing a protocol tree generated by tethereal:

    $ for i in 129.116.182.239 195.36.247.77 209.45.125.69 210.22.204.101 61.111.101.78 \
    66.139.10.15 66.8.163.125 80.181.116.202 ; do \
	tethereal -Vx -r sotm27 tcp and tcp.port==445 and ip.addr==$i > sotm27-tcp445-$i.txt ; done

    Rather than peruse the file manually, we use a command to print certain interesting lines—those containing the text Path:, Share:, or File Name:— and lines containing the text Status: within the following one hundred lines:

    $ grep -A 100 '\(Path:\|Share:\|File Name:\)' sotm27-tcp445-[0-9]*.txt \
    | grep '\(Path:\|Share:\|File Name:\|Status:\)' \
    >sotm27-tcp445-commands.txt
    The output from the command is available here.

    The results show that each of the seven attacking hosts obtained access to the honeypot sufficient to obtain privileged data from the Security Account Manager (SAMR). Two of the attacking hosts, 210.22.204.101 and 61.111.101.78, uploaded files that further compromised the operation of the honeypot. Several of the reports submitted by community members describe these attacks in detail.

    Attack on tcp/4899

    Analysis of traffic on port tcp/4899 begins by extracting the relevant TCP/IP transactions:

    $ ra -A -c -n -r sotm27.argus - tcp and dst port 4899 > sotm27-tcp4899.txt
    The output from the command is available here.

    The results show that, after several unsuccessful attempts, the host 210.22.204.101 successfully initiated an inbound connection to tcp/4899 at 18:44 on March 3. This host earlier successfully uploaded the file raddrv.dll via tcp/445:

    $ grep -i rad sotm27-tcp445-210.22.204.101.txt
0230  fa 2a e3 f4 f3 ee 4b 3b 52 41 64 fb 04 1c d4 1b   .*....K;RAd.....
        File Name: \WINNT\System32\raddrv.dll
03a0  55 6e 6c 6f 61 64 69 6e 67 20 52 61 64 64 72 76   Unloading Raddrv
0190  65 74 52 41 44 53 65 63 75 72 69 74 79 00 47 65   etRADSecurity.Ge
0150  00 00 53 59 53 54 45 4d 5c 52 41 64 6d 69 6e 5c   ..SYSTEM\RAdmin\
00c0  00 00 06 00 00 00 72 61 64 6d 6d 00 00 00 34 5b   ......radmm...4[

    The file raddrv.dll is associated with the radmin remote administration tool. The W32/Deloder worm, which attacks via tcp/445, uploads and installs the tool in order to establish a backdoor to its compromised hosts. The connection is encrypted and so little can be learned by studying the associated data stream. However, the coincidence of the attack on tcp/445 and the installation of the radmin backdoor are sufficient to tentatively establish the attack as one associated with W32/Deloder or a similar worm.

    Analysis of Outbound Traffic

    We conclude with a cursory analysis of outbound traffic, intended to detect signs of other possible compromises. We begin by extracting data on the related TCP/IP transactions:

    $ ra -A -c -n -r sotm27.argus - tcp and src host 172.16.134.191 > sotm27-outbound.txt
    The output from the command is available here.

    The outbound traffic can be characterized as one of the following:

    The former could be due to activity performed remotely by attackers or locally by honeypot operators. The latter transactions are interesting, because one might expect that they would be characterized as inbound rather than outbound, since they consist of replies to inbound HTTP queries. However, notice that argus decorates the lines with the direction ?> rather than ->. We use tcpdump to view details with an arbitrarily selected transaction:

    $ tcpdump -nn -r sotm27 host 24.197.194.106 and tcp and port 3806
03:43:09.551513 24.197.194.106.3806 > 172.16.134.191.80: F 1594580868:1594580868(0) ack 1256638560 win 17520 (DF)
03:43:09.551515 172.16.134.191.80 > 24.197.194.106.3806: . ack 1 win 17503 (DF)
03:45:57.118969 172.16.134.191.80 > 24.197.194.106.3806: F 1:1(0) ack 1 win 17503 (DF)
03:45:59.759206 172.16.134.191.80 > 24.197.194.106.3806: F 1:1(0) ack 1 win 17503 (DF)
03:46:05.012613 172.16.134.191.80 > 24.197.194.106.3806: F 1:1(0) ack 1 win 17503 (DF)
03:46:36.661844 172.16.134.191.80 > 24.197.194.106.3806: F 1:1(0) ack 1 win 17503 (DF)
03:47:19.670442 172.16.134.191.80 > 24.197.194.106.3806: F 1:1(0) ack 1 win 17503 (DF)

    Apparently, the failure of the attacking host to acknowledge the FIN sent by the honeypot has confused argus, which considers the direction of the transaction as uncertain.

    Conclusions

    Over a five-day period, the Windows 2000 honeypot was compromised several times by hosts exploiting its null administrative password. Attackers used this vulnerability to gain access to Windows File Sharing services provided over port tcp/445. Two attackers uploaded files that compromised operation of the honeypot, providing an encrypted backdoor operating on port tcp/4899 and incorporating the honeypot into an IRC botnet containing thousands of bots, most of which were presumably running on similarly compromised hosts. The aggregate capacity of this botnet was adequate to disrupt the operation of major Internet sites. However, the log provides no evidence that the botnet was used in this fashion.

    Acknowledgments

    The purpose of the monthly challenges is to provide the community with an opportunity to learn and practice analytical skills. The authors of this report thank the community members who participated in this challenge by sharing their methods and findings. The authors appreciate the opportunity of learning from others who invested the considerable time necessary to analyze the relatively large log file that was the basis of this challenge and hope that their own report may be useful and instructive to others.

    Top Four Beginning Submissions

    Top Ten Intermediate Submissions

    Other Intermediate Submissions