Scan 27 - April 2003

Author: Diego González Gómez
[email protected]

Table of contents:


The first step is to download and verify the binary file:

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

Then I tried to extract the contents:

$ gzip -d sotm27.gz
gzip: sotm27.gz: not in gzip format
$ file sotm27.gz
sotm27.gz: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 1514)

It seems to be a tcpdump file, so I can work directly with Ethereal and tethereal. If it were compressed it would occupy 13 MBs.


General Approach

The first step is to take a general perspective of the contents of the binary file. I entered various tethereal commands to obtain summary information which allowed me to view the most significant activity.

$ tethereal -nr sotm27.gz -z "io,phs" > stats.txt

The results show that, over the link layer (ethernet), there is only IP traffic. The protocols figured in the next layer are only TCP and UDP.

Because of those results I decided to get more detailed statistics.

$ tethereal -nr sotm27.gz -z "smb,rtt" >> stats.txt
$ tethereal -nr sotm27.gz -z "io,users,ip" >> stats.txt

The first command was not really necessary. But the use of NetBIOS appears to be important, and I decided to investigate in more detail SMB protocol activity.

The Server Message Block Protocol (SMB), resides in the application and presentation layers of the OSI model. It is used to implement network session control, network file and print sharing and messaging. File sharing via FTP or NFS plus network printing via LPR may be compared to SMB. They are functionally similar and are protocols found within the TCP/IP suite. SMB requires a transport /session protocol and the early versions of IBM's implementation were closely linked with NetBIOS. In general SMB runs either over the NetBIOS Frames Protocol (NBF), NetBIOS over TCP/IP, or NetBIOS over IPX. [1]

The number of SMB 'Transactions' (641) and 'Session Setup AndX' (198) is significant. We can observe that there are 'Write AndX' and 'Delete' commands too.

The second command displays ip activity in terms of IP addresses. The list of IP addresses is quite long. There are a total of 168 lines. It could be possible that many of the shown IP-related communications were initiated from the honeypot.


Identifying the suspects

After reading again the intermediate questions, I understood that I needed to know what IP addresses attacked the honeypot. So, to obtain the IP source addresses used to access the honeypot (, I used the tethereal utility with the filter displayed below, and I analyzed the output file with a perl script:

$ tethereal -nr sotm27.gz "(ip.dst == and ((tcp.flags == 0x02) or (ip.proto == 0x11))" | >suspects.txt

With that command I am filtering all TCP traffic originated from outside (0x02 = SYN flag), and the UDP traffic, since UDP is stateless. I ignore the response activity and all connections initiated by the honeypot. The suspects list contains about 136 different addresses. Below are listed the most significant ones:    1231  77.764%     105   6.633%     10   0.632%         6   0.379%        6   0.379%        5   0.316%        5   0.316%          4   0.253%      4   0.253%        4   0.253%        4   0.253%        4   0.253%

The first is by far the most active, with 77.7% activity. The second one has ten times less active (6.63%) than the primary suspect. And the rest of the IP addresses have less than 1% activity. It does not necessarily indicate that the rest ot the suspects have not been successful in their attacks.

Before analyzing the activity of those IP addresses in depth, I used snort to check how many intrusions it may have detected.

$ snort -A full -c snort.conf -r sotm27.gz

The most important part of the command output is shown here:

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

TCP:   54350 (99.659%)  ALERTS: 155
UDP:   186   (0.341%)   LOGGED: 56
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%)

It confirms that the most significant concerns are related to TCP traffic, followed by some minor activity of UDP traffic (less than 0.5%). There were 155 alerts and 56 were logged.

A brief exam of the Alerts log file reveals this information:

A lot of MS-SQL Worm propagation attempts (UDP packets to local port number 1434) from various  IP addresses (identified below).
  [Classification: Misc Attack]
  More information: [Xref => url] [Xref => bugtraq 5311] [Xref => bugtraq 5310]
A SCAN SOCKS Proxy attempt from (TCP SYN packet to port number 1080).
  [Classification: Attempted Information Leak]
  More information: [Xref => url]
Portscans from (honeynet) to remote IP addresses with port number 80, 6 targets 6 ports in (18-26) seconds. (Not of interest. I am only looking for attacks.)
A long list of alerts of portscan alerts detected from address. The most popular in my suspects list.

The snort alerts, helped me to reduce my suspects list. I extracted the suspicious IP addresses from the alert.ids log file and removed them from my suspects list.

$ grep 1434 alert.ids | cut -d ' ' -f 2 | cut -d ':' -f 1 > snort_attack.txt
$ snort_attack.txt > snort_attack_uniq.txt
$ snort_attack_uniq.txt

just makes a list of unique IP addresses from an IP address list. removes any corresponding IP address in file A (suspects.txt) from each line of file B (snort_attack_uniq.txt).

I added the IP address to snort_attack_uniq.txt file too. While simplifying ( the snort attackers list, I observed that there were some duplicated IP addresses in snort_attack_uniq.txt. The unique IP addresses numbered 48. All of them are attackers, not suspects, so I removed them from my suspects list and tagged them as attackers.

Then, I had to analyze 'only' 88 (136 - 48) IP addresses. I placed them in a file called suspects_reduced.txt.


Discovering the attackers and their methods

There are a lot of IP addresses to examine if you were to use manually-typed filters in Ethereal. In this case, I wrote a short perl script to simplify the analysis process. It writes a log file with each IP address activity ordered as they appear in my suspects list. I used it to process the less significant active IP addresses, from the fourth must active one till the end of the list. I analyzed the first four IP addresses with ethereal.

$ tethereal -nr sotm27.gz > sotm27.txt
$ suspects_reduced_stripped.txt

Despite the varied capabilities of computer attacks, they usually result in violation of only four different security properties: availability, confidentiality, integrity, and control. These violations are described below:

Therefore a 'successful attack' means a violation of any caracteristic that was mentioned before.

 Address  Comments (beginning with trace number when neccesary)  Attack  Success

  • (21001) Performs a TCP SYN scan from port 1 to 80. Not considered as an attack itself, but an information leak.

  • (21307) Access to 137 UDP port, sending an UDP packet with "CKAAAAA..." data string, probably using 'NBSTAT -A' command. This attack is used by network.vbs worm, but it doesn't seem to be that in this case. It doesn't try to open \\<COMPUTER>\\C after that. This attack is documented. [2]

  • (21332) Opens a short TCP session on port 139, and tries to open \\PC0191\IPC$ share with 'HT AUTHORIZED CUSTOM' username under 'HEWLETTPACKARD' domain. It fails to authenticate.

  • (21344) Tries to open ports 25 (SMTP) and 110 (POP) but they are closed.

  • (21370) Begins an aggressive and long HTTP vulnerability scan, probably using a script, lasting more than twenty minutes. The script sends a very long list of HTTP GET and HEAD commands, using unicode chars combinations. It tries attacks such as directory traversal for cmd.exe command (to get files like user.dat, boot.ini, or autoexec.bat), or buffer overflow [3]. The web server doesn't answer the malformed requests or stop its service. Those attacks do not appear to be successful.


  • (901) Tries to open TCP port 1433 (ms-sql-s), but it is closed.

  • (907) It opens a TCP session on 139 and 445 ports. It performs a null login to \\\\IPC$ resource. After that it succesfully uses several SAMR (Security Account Manager remote interface) commands to obtain several information such as administrator account details, default domain names, open users or active groups with success.

  • (1346) Several attempts to connect to port number 4899. Below is the explanation.

  • (1357) Here begins a very interesting TCP session on port 139. The attacker tries to open \\C$ (bad typed share) and fails. Then successfully opens \\\C$. After that, uses it to send and install three files called r_server.exe, raddrv.dll and admdll.dll under \WINNT\System32\ share resource. A TCP dump of this session revealed all the relevant information. The application is called 'Remote Administrator', a remote control program for windows based systems, developed by Famatech [4]. The zipped file from their website occupies only about 1.3 MBs. It is an ideal tool to control the honeypot.

  • (1829) It does not seem sufficient for this attacker. Here the attacker begins to send several 'HTTP GET /NULL.IDA?CCCCCCCC....[buffer with about 240 bytes] HTTP/ 1.1' commands to perform an overflow attack, without success. [3]

  • (2070) The attacker uses the installed remote administrator to control the honeypot using, to my surprise, the default tool port number, 4899. That explains the earlier attempts of the attacker in 1346, 1353, 1355 traces to connect to that port.

    It is a successful attack, of course.


  • (32902) It begins trying to open TCP port 57, described by IANA as 'any private terminal access', but the port is closed.

  • (32908) Tries to open TCP port 1433 (ms-sql-s), but it is closed.

  • (32914) Opens a TCP session on ports 139 and 445. It performs a null login to \\\\IPC$ resource. After that it uses several SAMR (Security Account Manager remote interface) commands to successfully get information such as administrator account details, default domain names, open users or active groups with success.

  • (33160) It opens a NETBIOS session using 139 and 445 TCP ports. It performs a null login to \\\\IPC$. It tries to open \\\\C$ share but it does not exist.

    Its attempts to access 'not public' share resources, turns it into an attack.


  • Opens a TCP session on ports 139 and 445. It performs a null login to \\\\IPC$ resource. After that it uses several SAMR (Security Account Manager remote interface) commands to successfully get information such as administrator account details, default domain names, open users or active groups with success.

  • Opens TCP sessions on 139 and 445 ports. Tries to login repeated times with several users like Guest, IUSR_PC0191, IWAM_PC0191, TSInternetuser, with no success. This is sufficient to affirm that it is an attacker.

    It is an attacker since it tried to access a 'non public' share resource. I will apply this category for the IP addresses below with the same behaviour.


  • (33217) Opens TCP sessions on 139 and 445 ports like IP address above. Then it opens \\\ADMIN$ share and sends and install PSEXESVC.EXE file to \WINNT\System32\ share resource. A TCP dump of the session revealed that it is a tool developed by Systinternals. The version of the program is 1.23. As described in its web site, PsExec [5] is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. It is a well known utility between windows administrators.

  • It deletes C$ share with 'share /delete C$ /y' command.

  • It deletes D$ share with 'share /delete D$ /y' command.

  • It deletes E$ share with 'share /delete E$ /y' command.

  • It deletes ADMIN$ share with 'share /delete ADMIN$ /y' command. Before logging out, it verifies twice the closed status of this share.

    It is a successful attack.


  • Opens a TCP session on ports 139 and 445. It performs a null login to \\\\IPC$ resource. After that it uses several SAMR (Security Account Manager remote interface) commands to successfully get information such as administrator account details, default domain names, open users or active groups with success. After that, it verifies (at 414 trace) that \\\ADMIN$ resource is shared. Then it logs out.


  • (20948) Tries to open TCP 1433 port, but it is closed.

  • (16) Opens a TCP session on port 80, with 'HTTP HEAD / HTTP/1.0' command, and gets 'HTTP HTTP/1.1 200 OK' response.

  • Then it tries to open TCP 57 port, but it is closed.

  • (32448) Similar behaviour like IP address before, but it does not receive any HTTP response from the honeypot.

  • At different times, it uses SYN/RST packets to only scan destination port TCP 139.

  • (793) TCP SYN scans against port 1433 (ms-sql-s).

  • (51179) Opens TCP sessions on ports 139 and 445. It performs a null login to \\\\IPC$ resource. Then it tries to access \\\C$ (no such device) and \\\\C$ (bad network name), shares but without success. The second share resource typed was deleted by address beforehand.

  • (51214) Opens a TCP session on port 80 and sends 'HTTP OPTIONS / HTTP/1.1' to get information.


  • (20956) Opens TCP sessions on ports 139 and 445. It performs a null login to \\\\IPC$ resource. Uses nbtstat or net commands to get the names of the share resources (ADMIN$ C$ IPC$), but does not open any of them.


  • The behaviour of these addresses is very similar to the one described at 'port 137 scan' page by SANS. [2]

    • They send a 'NBTSTAT -A' command (UDP packet to port 137).

    • Then open a TCP session on port 139, and try to connect to \\<COMPUTERNAME>\C share resource (where COMPUTERNAME = PC0191).

    • That share resource does not exist, and the honeypot sends RST packets.

  • As observed, this attack comes from a long list of source addresses. This behavior is more similar to the one of a worm, like network.vbs that to the one of a script.


  • (867) Scans destination port TCP 139 to verify if it is open. Opens a TCP session on ports 139 and 445 and tries to open \\PC0191\IPC$ share with 'DTMILWMANGE\DMMD' username\domain with no success.


  • (56 and 231)) Opens a TCP session on port 80, with 'HTTP GET / HTTP/1.1' command. It receives a HTML page with an error message.

  • (32882) Opens a TCP session on port 80, and tries an overflow attack with 'GET /default.ida?NNNN..[buffer]' command. A further reading at the TCP layer revealed that the HOST option of a 'HTTP/1.0' command inside the buffer has the value ''. At the end of the command is the code of a web page. Using this information on Google, I discover that it is probably caused by Code Red worm [6]. The attack has not success.


  • These IP addresses have little activity and in most cases try to obtain information through scans or nbstat commands. They did not seem to be successful in attacking the honeypot. Their methods are summarized here, by order of frequency, to simplify the analysis process:

    • 'NBTSTAT -A' or net commands (UDP packet to port 137).

    • TCP SYN/RST scans to port 139.

    • UDP scan from port 28432 to destination port 28431, probably to detect Trojans. This method is described in detail in an analysis from SANS. [7]

    • TCP SYN scans to port 21.

    • TCP SYN scan to port 1433.

    • TCP SYN scan to port 111 (sunrpc - SUN Remote Procedure Call).

    They aren't considered attackers, since they don't exploit any particular attack, such as buffer overflow, directory traversal, brute force login, access to share resources, etc. These intruders are only collecting information by utilising port scans or related software, it indicates that they might make an attack in the near future.

  • These IP addresses are the ones that snort detected. They used MS-SQL Worm to attack the honeypot, sending UDP packets to port 1434. [8] They had no success in their attacks.


  • (162) This IP address was detected by snort too. It performs a TCP SYN scan to port 1080, to check if a SOCK PROXY is running. [9] The port is closed.

Note: Maybe this section/table seems too long. I have tried to make it as simple as possible, always maintaining the most important information. Nevertheless, due to the nature of the analysis, I had to examine all the discovered suspect IP addresses.



After the analysis of the complete list of suspect IP addresses I have the following results, with some additional considerations:


Beginning Questions

1. What is IRC?
IRC is a multi-user chat system, written by Jarkko Oikarunen in 1988. It stands for "Internet Relay Chat", and it is defined in RFC-1459 (updated by RFC-2810, RFC-2811, RFC-2812, RFC-2813). IRC protocol, based on the client-server model, was designed as a replacement for the "talk" program. It is used as a text based conferencing system. [10]

 2. What message is sent by an IRC client when it asks to join an IRC network?
The client sends a TCP SYN packet to the IRC server port (usually 6667). Once connected, to join a channel, the client must use JOIN command using the following syntax: /JOIN #[nameofchannel].

 3. What is a botnet?
A botnet is a network of IRC bots that communicate with one another. A bot [11] is a script run from a client or a separate program. It is normally used to protect channels from takeovers and abusers, and to perform other functions as logging events. In a botnet, the bots share a means of communication whereby all speak to one another and exchange information. [12]

4. What are botnets commonly used for?
They are useful for keeping and maintaining a channel by acting as a group of channel bots that work together with a common goal. With a Botnet, even if an IRC bot dies, there still remains the rest of the bots on the Botnet to continue maintaining the channel and the loss of the one bot means nothing as the other bots do its exact same job.

Unfortunately, many people use bots created with Trojans from computer victims to create really big botnets (sometimes with thousands of bots). They take advantage of botnet's capacities to perform Denial of Service attacks against servers. Because the bots are making many home computers attack, from all over the world, those attacks are called Distributed Denial of Service attack (DDoS).

5. What TCP ports does IRC generally use?
As specified by IANA [13], the TCP ports used by IRC are:

irc 194/tcp Internet Relay Chat Protocol
irc-serv 529/tcp IRC-SERV
ircs 994/tcp irc protocol over TLS/SSL
ircu 6665-6669/tcp IRCU

The most commonly used ports are listed in the last line, from 6665 to 6669.

6. What is a binary log file and how is one created?
A binary log file is a log file format used by tools based on
libpcaplibraries like Ethereal, tcpdump or Snort, to log and analyze network traffic. Libpcapsupplies the underlying function libraries and data structures to allow this type of capture. A binary log file represents many advantages over a traditional ASCII file format. For example, it requires less space than text log files (the IP addresses only needs 4 bytes, usually less space than the same representation in text files), and its contents can be accessed more rapidly and analyzed.

To create a binary log file with Snort, for example, it is necessary to use '-b' parameter, like this:
$ snort -b -l blogfile.log

Ethereal it's sufficient to specify that the output type must be 'libpcap (tcpdump, ethereal, etc).'

Note: This question was already made in SotM23 (number one).

7. What IRC servers did the honeypot, which has the IP address, communicate with?
For this question, I used the following filter. It selects the traffic originated from the honeypot using IRC common remote ports:

(ip.src == and ((tcp.dstport >= 6665) and (tcp.dstport <= 6669))

After that, I used a perl script to extract the IP addresses. The IRC servers accessed by the honeypot were:

8. During the observation period, how many distinct hosts accessed the botnet associated with the server having IP address
I used the following filter with

(ip.addr ==

to obtain the IRC session. At trace number 35794, effectively, begins a long IRC communication. The TCP stream extracted from there is recorded in a file called irc_session.log.

To calculate the number of bots I stripped the log file, leaving only the names from the channel joined, and used 'wc -w [logfile]'command to count the words (3457 different nicknames). After that I only had to count the number of QUITS (222) and JOINS (175) (with 'grep [QUIT/JOIN] [logfile] | wc -l') and make some simple operations:

3457 - 222 + 175  =  3410 distinct hosts accessed the botnet during the observation period.

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

3410 (bots) * 56 (kbps) = 190.960.000 kbps = 190.960 Mbps is the aggregate bandwith of the botnet.

As comparison, a typical LAN is capable of 10 or 100 Mbps. It helps to give an idea of the power of DoS attacks a botnet can perform.


Intermediate Questions

1. What IP source addresses were used in attacking the honeypot?
As described in the analysis process, the computer attacks, usually result in violation of only four different security properties: availability, confidentiality, integrity, and control. These violations are described below:

Following that description, I have identified the following 117 IP addresses in the SotM27 binary log file as attackers, ordered by address number:

The IP address list corresponds to the IP addresses in the analysis table above that match the 'Attack' column. Some of them have been able to glean some information such as remote usernames, domains, group names, etc. but not their passwords or similar critical information. I do not consider that those constitute a successful attack. Nevertheless, all the traffic of a honeypot is considered as a potential intrusion or attack. It hasn't production activity.

2. What vulnerabilities did attackers attempt to exploit?
The attackers attempted to exploit multiple vulnerabilities. I have identified the following ones, trying to order them by popularity:

The methods described above were used to attack the honeypot. Nevertheless, I think that the answer is more complete if I describe the most popular approaches used to probe the honeypot. They aren't considered attacks, since they don't exploit any specific attack, such as buffer overflow, directory traversal, brute force login, access to share resources, etc. It indicates that they probably will make an attack in the near future. The methods are summarized here, by order of frequency.

3. Which attacks were successful?
A 'successful attack' means a violation of any caracteristic that was mentioned in the answer to the first question. The analysis process revealed that there were only two definite penetration attacks with success. Both of them successfully installed at least some type of remote administration tool to control the honeypot.


General Questions (not judged)

1. What did you learn about analysis as a result of studying this scan?
I have discovered new methods to analyze network traffic, and a binary log file. For the analysis of big log files it's very useful to find script languages that permit to process text files, such as Perl. I think that to extract all the necessary information, first it's necessary to find an efficient method of analysis. I haven't seen any clear information about analysis methodologies.

On the other hand, I have learned that it's very important to pay attention to the details. There is a lot of information in a network traffic dump file, even in a single packet. It's incredible how much data we can obtain from a short network packet stream. Every network administrator should dedicate every day a little amount of time to analyze in depth the most abnormal network data. Unfortunately in most times there isn't sufficient time to do that and is almost impossible to detect some short attacks between great amounts of normal traffic. I can only see a solution by well knowing the own network 'normal' traffic, and having an excellent domain with the use of filters.

2. How do you anticipate being able to apply your new knowledge and skills?
One of the things I was doing is to make detailed logs of network traffic, using an Intrusion Detection System like
snort. I agree that an IDS is not a silver bullet, but helps to identify a lot of attacks, and to prevents many of them. Another one of the tools that I use is the vulnerability scanners such as nessus. It not only indicates what vulnerabilities has my network, but it lets me analyze those attacks by examining network log files.

I will continue learning in the analysis of binary log files. Probably I will improve my knowledge on network traffic analysis and log tools such as etherealand languages such as Perl.

I am very interested in honeynet/honeypot related material, and I will probably install one in a near future for investigation and research purposes, always respecting the legal issues.

3. How can we improve the SotM challenge? What would you like to see added? What would you like to see done differently?
SotM challenges are very interesting and well presented. I wrote below several things that I would like to comment on:


The most important points of this conclusion are discussed under the General Questions section.

One of the main objectives of this challenge was to learn to analyze a complete log file. And to be able to study it from a general layer to a more specific one, noting every detail.

Tools like Ethereal help to analyze binary log files but in the end, they are only tools. It is essential to have an efficient analysis method that allows you to analyze most of the network-traffic dumps. That method shouldn’t be tool or language (eg. Perl) dependent.

A honeypot has some advantages over other security methods. For example, because the honeypot isn’t employed in real production activities, it only receives hostile traffic therefore removing false alarms from the IDS. Another advantage is that it is an ideal tool to identify new and/or undocumented attacks/exploits on the internet.

If the honeypot legal issues are respected, it is an excellent resource, not just for research purposes but also to improve system security in general.


  1. Richard Sharpe. What is SMB? v1.2. October 2002. <>.

  2. Sans Intrusion Detection FAQ. Port 137 Scan. May, 2000. <>.

  3. Additional Details Released on the IIS Remote Buffer Overflow. June, 2001. <>

  4. Famatech. Famatech's Remote Administrator. <>.

  5. Mark Russinovich, Sysinternals.PsExec. Updated April, 2002. <>.

  6. eEye Digital Security. .ida "Code Red" Worm. <>.

  7. SANS Institute. Global Incident Analysis Center. December 25, 1999. <>.

  8. Mcafee. W32/SQLSlammer.worm. Updated March, 2003. <>.

  9. Undernet Scans for Insecure Wingates and Proxies. <>.

  10. Oikarinen, J., Reed D. RFC 1459, Internet Relay Chat Protocol. May 1993. <>.

  11. mIRC Homepage. <>.

  12. IRC BotNET. <>.

  13. IANA - Internet Assigned Numbers Authority. <>.