# # # Scan of the Month Challenge 27 # # #


	Author:	B. Ghavalas (security@nscs.uk.com)
Date Created: 	31 March 2003
  Time Taken:	Approx. 8 Hours (Research and Report)


# # # Section 1: Beginning Questions # # #

------------------------------------------------------------------------------
1. What is IRC?
------------------------------------------------------------------------------
    
    irchelp.org has a copy of the IRC Chat FAQ, which has a
    very good explanation:
    
    --- Taken from IRC Chat FAQ---
    What is IRC?

    IRC stands for "Internet Relay Chat". It was originally
    written by Jarkko Oikarinen (jto@tolsun.oulu.fi) in 1988.
    Since starting in Finland it has been used in over 60
    countries around the world. It was designed as a replacement
    for the "talk" program but has become much much more than
    that. IRC is a multi-user chat system, where people
    convene on "channels" (a virtual place, usually with a
    topic of conversation) to talk in groups, or privately.
    [...]
    --- End Excerpt ---
    
    Internet Relay Chat (IRC) is a text-based, realtime 
    communications network that is formed of clients and
    servers. IRC is defined by RFC1459 and which has been
    updated by RFC2810, RFC2811, RFC2812 and RFC2813.

    The site http://www.irchelp.org contains a wealth of
    information about IRC and is worth checking out for
    anyone new to IRC or wanting more detail about IRC. This
    site also contains copies of the relevant RFCs.


------------------------------------------------------------------------------
2. What message is sent by an IRC client when it asks to join an IRC 
   network?
------------------------------------------------------------------------------
    
    As per RFC1459 Section 4.1 Connection Registration,
    the first message to be sent by the client is 
    "PASS <password>" which is then followed by
    "NICK <nickname>". In both cases, the command is sent 
    without the quotes and text in angle brackets <> is 
    replaced with the correct information.

    If a password is not required for access to the server,
    which is the case in this analysis, then the first command
    sent by the IRC client is "NICK <nickname>".

    An example of this communication can be seen in the
    IRC communication between the honeypot, with IP address
    172.16.134.191 and the host 209.196.44.172, which is the
    IRC server. In the example, the honeypot (IRC Client)
    sends "NICK rgdiuggac" to the IRC server (after the
    "NOTICE AUTH" messages).


------------------------------------------------------------------------------
3. What is a botnet?
------------------------------------------------------------------------------

    Before defining a botnet, it is necessary to define a 'bot'.
    A (ro)bot is a script or program that acts on behalf of its
    IRC owner to automate numerous tasks, and can be used for good
    or evil. Often, bots are used to help their IRC owners maintain 
    admin rights or Operator Privileges (Chan Ops) within a channel 
    and assist with other mundane administrative tasks amongst
    other things.
 
    When used maliciously, these bots are often included in trojans 
    that are used to compromise vulnerable machines. These bots tend 
    to be used for more than just maintaining Ops in a channel; they 
    are designed to respond to control commands sent by their owners, 
    making it possible for their owners to gather valuable information
    from the bot's host, such as passwords, logged keystrokes and the 
    like. In addition, these bots can be used to infect other machines
    or to generate traffic for Denial of Service (DoS) attacks.

    Naturally, having a single bot does not yield the same amount of
    power as an army of bots. The commanders of bot armies tend to
    believe the more bots the better. An army of bots that are able
    to work together is often referred to as a botnet. 

    Additional information about IRC bots can be found by a simple
    Google.

    For example, the article provided at
    http://zine.dal.net/previousissues/issue19/botnet.php
    is quite informative and provides one with a good understanding
    of a botnet.

    I have included the entire article here for ease of reference:

    --- Botnet Article from DALnetizen ---
    Just What Is a Botnet?
    By Curve

    If you have kept your ear to the ground on DALnet, and know something
    about the attacks that have gone on, you may have heard of the word 
    'botnet'. If you have kept your eyes peeled, you may even have seen 
    an IRCop or two racing around auto-killing entire channels for being
    'bots'. So, just what is all this 'botnet' malarky?

    Well, let's begin at the beginning (in the words of a singing nun 
    "it's a very good place to start"). Firstly, the bots we are talking 
    about when we refer to botnets are not the cuddly and nice variety who
    some of you use in your channels to manage access lists, run quizzes, 
    serve files or come up with corny lines. They do have something in 
    common with those bots you know and love though, as they are automated 
    and controlled by events (usually commands given in a channel).

    The major difference between a bot in a botnet, and your common eggdrop
    or IRC client script bot in a channel, is that the botnet variety have 
    been created with a trojan and, almost always, without the knowledge of
    the person whose computer they are running from.

    The trojan may have got on to the person's computer by being wrapped up
    in a file that looks innocent - usually a game crack, something sex 
    related, or it can simply be named to make you think it's an anti-virus 
    program! It may have got there because there was some hidden code on a 
    website that person visited, which downloaded it to their machine.

    So, however it got there - the trojan is now on the person's computer 
    and, unless they run a good anti-virus program, they won't know it's 
    there. What happens next then? Well, the next time that computer is 
    connected to the Internet, that trojan will start up an IRC client and 
    connect to a server. Sometimes it is a server on DALnet, but more often 
    these days it is an IRC server which has been set up on a shell account 
    and paid for with a stolen credit card. The trojan will also have been 
    coded to make the bot join a certain channel once it has connected.

    If the trojan has infected many computers, then many bots will join the
    channel. I, and other members of the Exploits Team, have seen such 
    channels with 4-5,000 bots there - each one of those bots is a home 
    computer infected with a trojan. Scary heh? A collection of these bots 
    in a channel is a botnet, and even a couple of hundred of them can cause 
    significant damage when used to attack servers.

    Ok - so somebody has used a trojan script, modified it to his choice of 
    server and channel names and, when he next goes online, there is a big 
    bunch of bots waiting for him. So what happens next? Well generally these
    bots have a few uses. The person who has made them (botmaster or botherder 
    are names often used to described that person), can generally use channel 
    commands to make the bots go out and spam your channels with a website 
    that has the trojan on it...to make even more bots. Often he will also be 
    able to launch raw text or CTCP attacks against channels he doesn't like, 
    or get the bots to /msg or send a memoserv to him telling him the nickname 
    passwords of anyone who is infected and uses IRC networks with services. 
    It gets a lot worse than that though, because the nastiest thing most of 
    these bots can do is to launch Denial of Service attacks against servers - 
    hundreds or thousands of bots all sending data to a server until its 
    connection becomes saturated and/or the server crashes. Because the bots 
    are making many home computers attack, from all over the world, we call 
    this a Distributed Denial of Service attack (DDoS).

    Who exactly gets a kick out of having a botnet? Well, certainly not you 
    the DALnet chatter - all you get out of it is lots and lots of spam in 
    your channel, and huge attacks if the botnet owner happens to feel like 
    it. You also get to have lagged services and lots of netsplits when the 
    bots are used to attack DALnet servers. DALnet doesn't benefit either, 
    because when the bots are used to attack - the IRC servers going down 
    are the least of anyone's worries. The attacks also effect the service 
    providers who host those servers, meaning that people who have never 
    heard of IRC suddenly can't get on the Internet. If it goes on for a 
    long time, those service providers lose money and may have to lay people 
    off work - so may any small businesses who were relying on those ISPs 
    for email, websites etc. In short, that one botnet may cause real and 
    tangible hardship in the lives of people who don't even know or care 
    about IRC. So who is getting a kick out of it? Only the person who made
    that trojan, and his little bunch of friends who think it' s a cool thing 
    to do.

    All is not lost though, because you can help stop the problem, not just 
    by ensuring you don't get a trojan yourself, but by keeping alert for 
    botnets and reporting them to IRCops when you do find one. Firstly 
    you'll need to recognise a bot from an infected computer when you meet 
    one.

    Unfortunately, there is no set way to recognise a bot. Some will have 
    some part of their nickname or ident all in common (eg XY-lucy, XY-jane, 
    XY-laura), and some will have a real name field all in common. Others 
    are recognisable because everything is random (eg nickname = zjral, 
    host = xcdv@isp.com, real name = rxfk). Yet others use real looking 
    nicknames, but are noticeable because there's an entire channel of 
    them and nobody is chatting! Usually bots are silent until given commands 
    in a channel, but some may 'report for duty' with a word, or phrase or 
    even a dot (period). Lockdown Corp has a very good gallery of screenshots 
    of a botnet owner in action.

    When you do find them, what do you do? What you should never do is visit 
    any websites they may be spamming - that's a short cut to getting 
    infected yourself! What you should do is report anything you think may be
    a botnet to an IRCop who can remove them from the network (if on DALnet), 
    or get the server shut down if it is somewhere else.

    Hopefully this article has given some of you a little insight into what 
    is being used to attack DALnet, and how you can help. Of course, the best 
    help you can give DALnet is by protecting your computer!
    ¶¸Emma/Curve 2002 
    --- End of Article --


------------------------------------------------------------------------------
4. What are botnets commonly used for?
------------------------------------------------------------------------------

    As mentioned earlier, bots can be used to assist with general
    IRC administration.  However, botnets tend to be used for more
    malicious purposes. These often include Distributed Denial of
    Service (DDoS) attacks and mass infection of vulnerable hosts.


------------------------------------------------------------------------------
5. What TCP ports does IRC generally use?
------------------------------------------------------------------------------

    IRC is usually found to be listening on TCP 6667, but this can
    be changed to make use of any TCP port. 

    This information can be found in the IRC Chat FAQ on irchelp.org
    (http://www.irchelp.org/irchelp/altircfaq.html)


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

    Using a product like 'tcpdump' (http://www.tcpdump.org), 'Ethereal'
    (http://www.ethereal.com), 'Snort' (http://www.snort.org) or another 
    tool with packet capture facilities, it is possible to create a
    binary log file. These tools are able to capture network traffic
    from the network interface and write this traffic in pcap format
    to a file.

    The binary file makes it possible to review (and replay) captured
    traffic at a later stage, making it a very valuable forensic tool.
    Almost all applications that use the libpcap packet capture library
    should be able to read the binary log file.


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

    The following IRC servers were contacted by the honeypot:

    irc5.aol.com (209.196.44.172) 
      -> The IRC communication captured was predominantly with
         this server. The FQDN has been assumed based on the
         captured communication.

    209.126.161.29
      -> Three connections to this host were attempted, but no
         communication took place. Without the communication,
         no assumptions were made about the FQDN for this host. 

    217.199.175.10
      -> A single connection was attempted to this server, but
         the server responded with "Sorry, server is full - try 
         later" after which there was no further communication.
         No FQDN was provided in the captured session.

    irc4.aol.com (63.241.174.144)
      -> A single connection was also attempted to this server, in
         this case, the NICK was already in use, and then the
         connection timed out. The FQDN has been assumed based on
         the captured communication.

    66.33.65.58
      -> Three connections to this host were attempted, but no
         communication took place. Without the communication,
         no assumptions were made about the FQDN for this host.


    The communication pattern was as follows:
	1. The Honeypot first connects to 209.126.161.29 but SYN packets
           remain unanswered. 
	2. The Honeypot then attempts to connect to 66.33.65.58, but again 
	   there is no answer. 
	3. 63.241.174.144 answers the Honeypots connection attempts, but the
	   NICK requested is already in use and is rejected. The session 
	   times out and the connection is ended.
	4. Host 217.199.175.10 is the next server to be contacted, but this 
	   server is full and the session is closed.
	5. IPs 209.126.161.29, 66.33.65.58 then again 209.126.161.29 are 
	   re-tried, with the same results as before.
	6. Finally, the honeypot moves on to 209.196.44.172 and this time it 
	   hits paydirt - the IRC client logs on to the IRC server with 
	   NICK rgdiuggac.

    Note: The FQDN names determined above are clearly incorrect
          for the IP addresses, but are provided in the spirit
          of the challenge. No doubt this is due to the
          obfuscation of the data prior to releasing it for the
          challenge.

    This information was obtained by a quick check of the directory 
    listing of breakout sessions generated by Snort after running 
    the binary log file through it. Any SESSION file with a port of
    6667 indicated IRC communications. The information could also have 
    been obtained using a perl script or using tools such as grep
    and uniq. Ethereal could also be use by implementing a filter with 
    a tcp destination port of 6667, then sorting the output by 
    destination and manually spotting the different hosts.

    Prior to using this method, quick greps of the binary log file
    and Snort session breakouts were performed using various IRC 
    commands, to ensure that no other ports were used for the IRC 
    communication.

    The communication pattern was determined by analysing the binary log
    file with Ethereal.


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

    The number of distinct hosts that accessed the botnet appears
    to be 6603. 

    This figure was determined using a perl script and
    a regex to find unique bot names within the Snort breakout
    session for the IRC communication between the honeypot and the
    IRC server. A TCP session trace file generated by Ethereal 
    could also have been used.

    The domain portion of the bot client address was not used as part 
    of the calculation as any host that had a dynamic IP address would 
    be likely to get a new address, changing the domain portion of the
    bot client's address. Also, as a NICK has to be unique, it is safe
    to assume that each NICK refers to a unique client. 

    The trojan code has not been analysed, and it is possible that the 
    IRC client could select a new NICK whenever it it connects to the 
    IRC server, which would make this calculation rather inaccurate.
    The Honeypot server was seen to change it's NICK, but it is assumed
    that this was done because the requested NICK was already in use.

    One other point to note is that two clients did not make use of
    the optional prefix of a colon ':' when sending their messages.
    If this is not noticed and a regex is used that includes the
    colon, the bot count will be short by two. The two culprits are:
    "aawnz" and "winnizz".

    The perl regex used in the script was: /^(.*?)(!|~)/
    In addition to the above regex, any line beginning with ':irc5'
    was also stripped out, as these lines matched the above regex,
    but were messages generated by the server. The regex looks for
    any string that starts at the beginning of the line and ends
    with either a '!' or '~'. The non-greedy operator was used to
    prevent the regex from matching a line that ended with the '!'
    or '~' rather than just the nickname. The results from the first
    set of parentheses was then added to a simple perl hash. To get
    the total number of bots, a count of the keys (unique NICKs) in
    the hash was performed.


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

    6603 * 56Kbs = 369768Kbps which is approx. 361Mbps
    (Calculated by dividing 369768 by 1024)

    This is enough bandwidth to do a lot of damage with a DDoS :-<


==============================================================================


# # # Section 2: Intermediate Questions # # #


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

    By definition, any traffic entering a honeynet should be
    considered hostile traffic. As such, all sources recorded
    in the binary log file were theoretically attacking the
    honeypot. The list of source addresses below consist of
    sources that attempted more than just a simple NBTSTAT,
    TCP Connect or HTTP GET, these sources attempted to map a 
    share or exploit a weakness.

    There were several attempts to access '\\PC0191\C'. It is 
    assumed that many of these attempts were the result of the
    Opaserv/Opasoft worm. None of these attacks were successful.
    The following hosts (in order of appearance in the binary 
    log) are responsible for these attempts (all 50 of them!):

    219.118.31.42       62.194.4.114      213.217.55.243
    61.155.126.150	68.115.33.110     66.73.160.240
    66.190.67.122       144.134.109.25    61.177.154.228
    141.149.155.249     210.12.211.121    217.1.35.169
    207.6.77.235        202.63.162.34     61.55.71.169
    162.33.189.252      210.214.49.227    62.251.129.118
    64.17.250.240       195.67.251.197    164.125.76.48
    213.84.75.42        217.222.201.82    219.94.46.57
    68.152.53.138       168.226.98.61     61.140.149.137
    4.64.221.42         217.227.98.82     200.66.98.107
    81.202.125.5        62.201.96.159     61.14.66.92
    218.237.70.119      210.203.189.77    200.60.202.74
    213.107.105.72      213.116.166.126   217.227.245.101
    213.44.104.92       213.7.60.57       203.115.96.146
    68.154.11.82        64.254.203.68     212.110.30.110
    81.50.177.167       216.170.214.226   24.161.196.103
    208.186.61.2        210.58.0.25		
    
    Another worm that is still doing the rounds is the SQL Worm.
    Several attempts to exploit this weakness were recorded in
    binary log file. As SQL was not running on the server,
    (assumed because of the RSTs to all TCP 1433 connection
    attempts) the worm was doomed to fail. 47 different attempts
    were recorded:
    
    68.37.54.69         218.92.13.142     213.122.77.74
    12.252.61.161       61.134.45.19      61.185.242.190
    206.149.148.192     61.132.88.50      218.244.66.32
    218.4.87.137        218.4.99.237      61.150.120.72
    66.81.131.17        216.229.73.11     68.45.123.130
    61.177.56.98        168.243.103.205   61.203.104.148
    61.132.88.90        216.192.145.21    61.177.62.66
    24.167.221.106      61.185.29.9       217.35.65.9
    67.201.75.38        4.33.244.44       219.145.211.3
    61.8.1.64           24.74.199.104     205.180.159.35
    68.84.210.227       81.57.217.208     61.185.215.42
    66.233.4.225        61.185.212.166    67.81.161.166
    200.50.124.2        213.170.56.83     212.122.20.74
    12.253.142.87       218.4.48.74       218.4.65.115
    12.83.147.97        212.162.165.18    219.145.211.132
    61.150.72.7         200.135.228.10	
    
    The following host attempted what appeared to be a CodeRed
    style attack against the IIS server:    

    218.25.147.83

    
    Various attempts were made to connect to the Honeypot using
    tcp port 445, but only two hosts successfully compromised the
    Honeypot. These next 7 hosts were unsuccessful:

    195.36.247.77   
	Host: LIO-UEA8YNL9UE1
	This host connects to the Honeypot, performs the necessary
	enumeration to learn the necessary information for logging
	in, and then logs in as the Administrator. The host connects
	to the ADMIN$ share, but then disconnects and leaves.
    
    66.139.10.15
	Host: GLITTER
	This host also performs enumeration, then attempt to login in
	to the Honeypot, but all attempts fail.

    80.181.116.202
	Host: NOKIA
	This host connects to the IPC$ as Administrator, enumerates
	the shares then disconnects.

    209.45.125.69
	Host: LIMPX001
	This host connect to the Honeypot, performs enumeration and then
	attempts various logins, but they all fail.

    129.116.182.239
	Host: FSEL-GMV218UFJ5
	This host also performs enumeration, then connects to the IPC$
	share as Administrator. The host then disconnects and reconnects
	using a NULL connection and attempts to access C$ which naturally
	fails.

    66.8.163.125
	Host: OCEAN. 
	This host immediately logs in as Administrator, then attempts to 
	connect to C$. However, as the C$ share was deleted by the trojan 
	dropped on to the Honeypot by 61.111.101.78, the share is no
	longer available. The host then requests HTTP OPTIONS, but there
	is no response from the server.

    24.197.194.106
	Host: HPPAV
	This host first conducted a small portscan. It then attempted to
	login to IPC$ (over TCP 139) using 
	'HEWLETTPACKARD\HP AUTHORISED CUSTOM' as the login name - this
	obviously failed. The host then scanned the web server for
	various vulnerabilities using the HTTP 'HEAD' method. No HTTP
	responses to these requests were observed.

    These last two hosts appear to be the only two hosts that were
    successful (which is the answer to question 3 ;>):

    210.22.204.101 
	Host: ST-111
	This host performs the necessary enumeration and then makes a 
	successful connection as Administrator after several failures.
	A connection is made to the C$ share and then several files
	are copied to \WINNT\System32. The files are:
		r_server.exe
		raddrv.dll
		admdll.dll
	These files belong to RADMIN by Famatech. (http://www.radmin.com)
	Information about RADIM can be found in the PDF published on the
	Famatech website: http://www.famatech.com/radmin.pdf
	
	The host then starts r_server.exe as a service.

	A few .IDA buffer overflow attempts followed by attempted
	TCP connections to port 99 are made, none of which appear
	to be successful as the Honeypot always sends RSTs.

	Finally, the attacker connects to TCP 4899 which is the default
	RADMIN port. It is not known what the attacker did once remote
	GUI control of the server had been obtained.

    61.111.101.78
	Host: OIL-6II61N0JWTK
	This host also performs enumeration and then establishes a
	connection as Administrator to the ADMIN$ share. The commands
	executed during the remainder of the session are consistent with
	those of the W32/Deloder-A trojan.

	The host makes use of PSEXEC from Sysinternals
	(http://www.sysinternals.com) to install files and execute
	commands on the Honeypot.

	In summary, the trojan places inst.exe and Devlr32.exe in to
	\WINNT\System32 and executes them. The trojan then proceeds
	to remove the C$, D$, E$ and ADMIN$ shares using the standard
	'net share /delete <share> /y' command.

	The commands are effective as one can immediately see the Honeypot
	attempting to connect to various IRC servers (See question 7 in 
	the Beginning Questions section.)


------------------------------------------------------------------------------
2. What vulnerabilities did attackers attempt to exploit?
------------------------------------------------------------------------------

    The Opaserv/Opasoft worm attempts to take advantage of unrestricted
    sharing of the 'C' drive, which is usually found on Windows 9x hosts,
    where users have often unwittingly shared their entire drive to the
    world.

    The SQL Worm attacks a vulnerability discovered by David Litchfield
    that affects Microsoft SQL server 2000. More information is available
    from http://www.nextgenss.com/advisories/mssql-udp.txt and
    http://www.nextgenss.com/advisories/mssql-ods.txt

    There are a few attempts to exploit the .IDA buffer overflow 
    vulnerability, discovered by eEye Digital Security. More information
    is available at: 
    http://www.eeye.com/html/Research/Advisories/AD20010618.html

    The remaining vulnerability that was attacked was the weak password
    assigned to the Administrator account. (No password was assigned!)


------------------------------------------------------------------------------
3. Which attacks were successful?
------------------------------------------------------------------------------

    Only two attacks against the Honeypot were successful, as indicated
    in question 1 above.

    The first successful attack was conducted by the host with an IP
    address of 210.22.204.101. This host successfully installed the
    RADMIN product and was able to connect to the default TCP port of
    4899, taking remote control of the Honeypot.

    The other successful host had an IP address of 61.111.101.78. This
    host successfully deployed what is believed to be the W32/Deloder-A
    trojan on to the Honeypot.


---EOF---