The Not so Friendly World of Cyberspace
   Know Your Enemy: Worms at War
   
   Written by the Honeynet Project
   Last Modified: 9 November, 2000
   
   This paper was born out of pure curiosity. Our Honeynet was being
   pounded with UDP port 137 and TCP port 139 scans.  The network was
   getting scanned 5-10 times a day on these ports, something was up.
   The goal was to learn what these scans were all about.  What was out
   in the Internet causing all of this activity?  Based on the ports, we
   assumed that the scans were looking for Window's based
   vulnerabilities.  The plan was to setup a Win98 honeypot, sit back and
   wait.  We didn't have to wait long.
   
   The Setup
   During a one month period (20 Sep - 20 Oct) we confirmed 524 unique
   NetBIOS scans on our Honeynet network.  These scans consisted of UDP
   port 137 (NetBIOS Naming Service) probes, usually followed by TCP port
   139 (NetBIOS Session Service).  That is large number of scans probing
   for a specific service, something was up, we decided to find out what.
   The Honeynet network does not advertises itself to the Internet.  We
   just put the systems on our network and sit back and wait.  That means
   that the majority of scans we receive are random scans that are most
   likely probing most of the Internet.  These are the same threats your
   systems face.  As these scans are probing Windows based systems, they
   are most likely focusing on the common homeowner with a DSL or Cable
   connection to their house.  We are not talking about corporate
   espionage or web defacing, we are talking about simple homeowners as
   the target here.  We were curious, who was doing these scans, what was
   their purpose, and why the vast number of scans?  Was this a
   coordinated effort, were these worms?  Lots of questions.  So, we
   decided to find out and added a Windows98 honeypot to our collection.
   We did a default installation of Windows98 and enabled sharing of the
   C: drive. A Windows98 honeypot may not sound glamorous, however there
   are several things to be gained from setting up such a system.
    1. Windows98 represent a huge number of systems connected to the
       Internet, and this number is growing fast.  Typically, these are
       the systems with the weakest security, as homeowners are the ones
       using these systems.  What people do not realize is the risk these
       systems are exposed to, as many of them have dedicated connections
       to the Internet.
    2. This was our first crack at a Microsoft based honeypot.  The plan
       was to start off simple and learn from there.
       
   On October 31, the system was installed, sharing was enabled, and
   connected to the Internet.  We then sat back and waited, the wait was
   not long.
   
   The First Worm
   Less then 24 hours later we received our first visitor.  The system
   216.191.92.10 (host-010.hsf.on.ca) scanned the network looking for
   Window systems.  It found ours and began querying it.  If first began
   by getting the system name and determine if sharing was enabled.  Once
   it determined that sharing was enabled, it then probed for specific
   binaries on our system.  Its goal was to determine if a specific worm
   was installed, and if not, then it would install itself.  In this
   case, the specific worm was not installed.  The worm is known as the
   "Win32.Bymer Worm ".  The purpose of this worm is to take advantage of
   your CPU cycles to help an individual win the distributed.net
   contest.  Distributed.net is group that uses the idle process of
   distributed computers for various challenges (such as cracking RC5-64
   challenge).  People are awarded prizes if the crack the challenge.
   The more computers and CPU cycles you have under your control, the
   better of your chances of winning.  In our case, someone "volunteered"
   us for the project by installing the worm on our system.
   
   An individual (in this case, bymer@inec.kiev.ua), created a self
   replicating worm that would find vulnerable Window systems and install
   the distributed.net client on unsuspecting systems.  Once installed
   and executed, the worm utilizes your CPU cycles in attempt to help the
   author win the contest.  Meanwhile the worm begins probing for other
   vulnerable systems it can take over.  The goal is  to have access to
   as many computers and CPU cycles as possible.  This process grows
   exponentially as more systems are compromised.  Lets take a look at
   the attack using packet captures of the network traffic (in this case,
   we used the IDS sniffer snort).  For more advanced analysis of the
   NetBIOS protocol, you may want to use a protcol analyzer, such as the
   free utility Ethereal.  Throughout the sniffer traces below, the
   system 172.16.1.105 is the IP address of the honeypot.
   
   The worm begins by first checking to see if the file dnetc.ini is on
   the system.  This is the standard configuration file for the
   distributed.net client.  This configuration file tells the main server
   who should get credit for all the CPU cycles.  This is also the person
   that most likely created the worm.  Here we see the packet trace where
   the remote system (NetBIOS name GHUNT, account GHUNT, domain HSFOPROV)
   copies the configuration file to our honeypot.
   
   11/01-15:29:18.580895 216.191.92.10:2900 -> 172.16.1.105:139
   TCP TTL:112 TOS:0x0 ID:50235  DF
   *****PA* Seq: 0x12930C6   Ack: 0x66B7068   Win: 0x2185
   00 00 00 5B FF 53 4D 42 2D 00 00 00 00 00 01 00  ...[.SMB-.......
   00 00 00 00 00 00 00 00 00 00 00 00 00 C8 57 1C  ..............W.
   00 00 82 D1 0F FF 00 00 00 07 00 91 00 16 00 20  ...............
   00 DC 1C 00 3A 10 00 00 00 00 00 00 00 00 00 00  ....:...........
   00 00 00 1A 00 5C 57 49 4E 44 4F 57 53 5C 53 59  .....\WINDOWS\SY
   53 54 45 4D 5C 64 6E 65 74 63 2E 69 6E 69 00     STEM\dnetc.ini.
   
   Below we see the actual file transfer of the configuration file
   dnetc.ini.  Notice who is the point of contact for this,
   bymer@inec.kiev.ua.  This is the individual that receives the credit
   for the CPU cycles, and most likely the author of the worm attacking
   us.
   
   11/01-15:29:18.729337 216.191.92.10:2900 -> 172.16.1.105:139
   TCP TTL:112 TOS:0x0 ID:50747  DF
   *****PA* Seq: 0x1293125   Ack: 0x66B70AD   Win: 0x2140
   00 00 01 11 FF 53 4D 42 0B 00 00 00 00 00 01 00  .....SMB........
   00 00 00 00 00 00 00 00 00 00 00 00 00 C8 57 1C  ..............W.
   00 00 02 D2 05 00 00 E1 00 00 00 00 00 E1 00 E4  ................
   00 01 E1 00 5B 6D 69 73 63 5D 20 0D 0A 70 72 6F  ....[misc] ..pro
   6A 65 63 74 2D 70 72 69 6F 72 69 74 79 3D 4F 47  ject-priority=OG
   52 2C 52 43 35 2C 43 53 43 2C 44 45 53 0D 0A 0D  R,RC5,CSC,DES...
   0A 5B 70 61 72 61 6D 65 74 65 72 73 5D 0D 0A 69  .[parameters]..i
   64 3D 62 79 6D 65 72 40 69 6E 65 63 2E 6B 69 65  d=bymer@inec.kie
   76 2E 75 61 0D 0A 0D 0A 5B 72 63 35 5D 0D 0A 66  v.ua....[rc5]..f
   65 74 63 68 2D 77 6F 72 6B 75 6E 69 74 2D 74 68  etch-workunit-th
   72 65 73 68 6F 6C 64 3D 36 34 0D 0A 72 61 6E 64  reshold=64..rand
   6F 6D 70 72 65 66 69 78 3D 32 31 37 0D 0A 0D 0A  omprefix=217....
   5B 6F 67 72 5D 0D 0A 66 65 74 63 68 2D 77 6F 72  [ogr]..fetch-wor
   6B 75 6E 69 74 2D 74 68 72 65 73 68 6F 6C 64 3D  kunit-threshold=
   31 36 0D 0A 0D 0A 5B 74 72 69 67 67 65 72 73 5D  16....[triggers]
   0D 0A 72 65 73 74 61 72 74 2D 6F 6E 2D 63 6F 6E  ..restart-on-con
   66 69 67 2D 66 69 6C 65 2D 63 68 61 6E 67 65 3D  fig-file-change=
   79 65 73 0D 0A                                   yes..
   
   The next file to be transferred is the actual distributed.net client,
   dnetc.exe.  This is a valid executable, it is not malicious in
   nature.  We confirmed this by taking an MD5 signature of the client
   found on the honeypot. We then downloaded the client from
   distributed.net and took an MD5 hash of the dnetc.exe client. The MD5
   hashes were identical (d0fd1f93913af70178bff1a1953f5f7d), indicating
   that this code is not the worm. This is the binary that uses your CPU
   cycles as part of the distributed.net challenge.  However, the worm
   intends on using this binary without your permission nor knowledge,
   all for the author's gain.
   
   11/01-15:34:09.044822 216.191.92.10:2900 -> 172.16.1.105:139
   TCP TTL:112 TOS:0x0 ID:33084  DF
   *****PA* Seq: 0x129341A   Ack: 0x66B71C0   Win: 0x202D
   00 00 00 5B FF 53 4D 42 2D 00 00 00 00 00 01 00  ...[.SMB-.......
   00 00 00 00 00 00 00 00 00 00 00 00 00 C8 57 1C  ..............W.
   00 00 04 26 0F FF 00 00 00 07 00 91 00 16 00 20  ...&...........
   00 FE 1D 00 3A 10 00 00 00 00 00 00 00 00 00 00  ....:...........
   00 00 00 1A 00 5C 57 49 4E 44 4F 57 53 5C 53 59  .....\WINDOWS\SY
   53 54 45 4D 5C 64 6E 65 74 63 2E 65 78 65 00     STEM\dnetc.exe.
   
   Next we see the actual worm being transferred, msi216.exe. This is the
   self-replicating worm that randomly probes for vulnerable systems and
   copies itself.  This is the worm that is most likely causing a great
   number of the scans we are receiving.
   
   11/01-15:37:23.083643 216.191.92.10:2900 -> 172.16.1.105:139
   TCP TTL:112 TOS:0x0 ID:40765  DF
   *****PA* Seq: 0x12C146A   Ack: 0x66C248B   Win: 0x20B2
   00 00 00 5C FF 53 4D 42 2D 00 00 00 00 00 01 00  ...\.SMB-.......
   00 00 00 00 00 00 00 00 00 00 00 00 00 C8 57 1C  ..............W.
   00 00 02 F3 0F FF 00 00 00 07 00 91 00 16 00 20  ...............
   00 C0 1E 00 3A 10 00 00 00 00 00 00 00 00 00 00  ....:...........
   00 00 00 1B 00 5C 57 49 4E 44 4F 57 53 5C 53 59  .....\WINDOWS\SY
   53 54 45 4D 5C 6D 73 69 32 31 36 2E 65 78 65 00  STEM\msi216.exe.
   
   Last, the worm first modifies then uploads a new win.ini file.  The
   worm does this so the system will execute the worm upon reboot.
   Remember, it can be difficult to remotely execute a file on a Win98
   system, so this is the worm's method of getting it executed   It does
   this by adding itself to the boot up configuration file
   c:\windows\win.ini and has itself loaded during the boot process.  The
   new win.ini file is then uploaded to our compromised system.
   
   11/01-15:38:55.352810 216.191.92.10:2900 -> 172.16.1.105:139
   TCP TTL:112 TOS:0x0 ID:1342  DF
   ******A* Seq: 0x12C6F55   Ack: 0x66C95FC   Win: 0x1FBF
   00 00 0B 68 FF 53 4D 42 1D 00 00 00 00 00 01 00  ...h.SMB........
   00 00 00 00 00 00 00 00 00 00 00 00 00 C8 57 1C  ..............W.
   00 00 02 F9 0C 0D 00 61 19 00 00 00 00 00 00 00  .......a........
   00 00 00 00 00 00 00 00 00 2C 0B 3C 00 2D 0B 00  .........,.<.-..
   5B 77 69 6E 64 6F 77 73 5D 0D 0A 6C 6F 61 64 3D  [windows]..load=
   63 3A 5C 77 69 6E 64 6F 77 73 5C 73 79 73 74 65  c:\windows\syste
   6D 5C 6D 73 69 32 31 36 2E 65 78 65 0D 0A 72 75  m\msi216.exe..ru
   6E 3D 0D 0A 4E 75 6C 6C 50 6F 72 74 3D 4E 6F 6E  n=..NullPort=Non
   65 0D 0A 0D 0A 5B 44 65 73 6B 74 6F 70 5D 0D 0A  e....[Desktop]..
   57 61 6C 6C 70 61 70 65 72 3D 28 4E 6F 6E 65 29  Wallpaper=(None)
   0D 0A 54 69 6C 65 57 61 6C 6C 70 61 70 65 72 3D  ..TileWallpaper=
   31 0D 0A 57 61 6C 6C 70 61 70 65 72 53 74 79 6C  1..WallpaperStyl
   65 3D 30 0D 0A 0D 0A 5B 69 6E 74 6C 5D 0D 0A 69  e=0....[intl]..i
   
   That's it.  The Worm is now complete and the honeypot has now been
   infected.  All that needs to happen now is the system to reboot and
   the Worm will take effect.  Once it takes effect, several things
   happen.
    1. The distributed.net client begins, using the CPU cycles in the
       contest.
    2. The Worm begins searching for other vulnerable systems to
       replicate itself to.  This is what is causing all the UDP 137 and
       TCP 139 scans.
    3. The worm may add the following keys to the registry.
       
   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\Bymer
   .scanner
   HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServic
   es\Bymer.scanner
   
   One may think that having to wait for a system to reboot is an
   unreliable way to execute.  Keep in mind, the targets are Windows
   desktop systems.  How often do you reboot your Windows desktop?
   
   The Second Worm
   It is a busy week, and our second worm comes the next day.  This worm
   is a similar variation to the first worm, its purpose is to gain
   control of your CPU cycles to help an individual in the
   distributed.net contest.  The only difference with this worm is that
   all the files are combined in one single executable, wininit.exe.
   Default installations of Windows98 already have a binary
   c:\windows\wininit.exe installed on their system.  This worm calls
   itself the same in an attempt to obscure itself, but installs itself
   in c:\windows\system\wininit.exe.  If anyone should happen to stumble
   across the binary, the author hopes they will assume it is part of the
   operating system and not a worm.  This is a very common tactic amongst
   the blackhat community. Once executed, the worm acts just as the
   previous worm does.   Below we see our honeypot being infected with
   the second worm, wininit.exe.  The remote systems has the NetBIOS name
   WINDOW, account WINDOW, domain LVCW.
   
   11/02-21:41:17.287743 216.234.204.69:2021 -> 172.16.1.105:139
   TCP TTL:113 TOS:0x0 ID:38619  DF
   *****PA* Seq: 0x21CC0AC   Ack: 0xCE6736B   Win: 0x2185
   00 00 00 5D FF 53 4D 42 2D 00 00 00 00 00 01 00  ...].SMB-.......
   00 00 00 00 00 00 00 00 00 00 00 00 00 D0 4F 1F  ..............O.
   00 00 84 EE 0F FF 00 00 00 07 00 91 00 16 00 20  ...............
   00 20 BB 01 3A 10 00 00 00 00 00 00 00 00 00 00  . ..:...........
   00 00 00 1C 00 5C 57 49 4E 44 4F 57 53 5C 53 59  .....\WINDOWS\SY
   53 54 45 4D 5C 77 69 6E 69 6E 69 74 2E 65 78 65  STEM\wininit.exe
   00
   
   Once the worm has installed itself, the remote system then modifies
   the win.ini file to ensure it is executed on reboot.  Notice how this
   executable adds to the already modified c:\windows\win.ini file, which
   has an entry from our previous worm.
   
   11/02-21:41:48.538643 216.234.204.69:2021 -> 172.16.1.105:139
   TCP TTL:113 TOS:0x0 ID:21212  DF
   ******A* Seq: 0x22021C9   Ack: 0xCE68EC7   Win: 0x1FA3
   00 00 0B 68 FF 53 4D 42 1D 00 00 00 00 00 01 00  ...h.SMB........
   00 00 00 00 00 00 00 00 00 00 00 00 00 D0 4F 1F  ..............O.
   00 00 84 F4 0C 0F 00 7F 19 00 00 00 00 00 00 00  ................
   00 00 00 00 00 00 00 00 00 2C 0B 3C 00 2D 0B 00  .........,.<.-..
   5B 77 69 6E 64 6F 77 73 5D 0D 0A 6C 6F 61 64 3D  [windows]..load=
   63 3A 5C 77 69 6E 64 6F 77 73 5C 73 79 73 74 65  c:\windows\syste
   6D 5C 77 69 6E 69 6E 69 74 2E 65 78 65 20 63 3A  m\wininit.exe c:
   5C 77 69 6E 64 6F 77 73 5C 73 79 73 74 65 6D 5C  \windows\system\
   6D 73 69 32 31 36 2E 65 78 65 0D 0A 72 75 6E 3D  msi216.exe..run=
   0D 0A 4E 75 6C 6C 50 6F 72 74 3D 4E 6F 6E 65 0D  ..NullPort=None.
   0A 0D 0A 5B 44 65 73 6B 74 6F 70 5D 0D 0A 57 61  ...[Desktop]..Wa
   
   Upon reboot, this worm, like the previous one, will start up and begin
   the same processes.  The thing to keep in mind is that the remote
   systems attacking us are most likely not evil blackhats out to own the
   world.  More likely the remote systems are innocent bystanders who
   were compromised.  The owners have no idea there is a worm running on
   their system, nor any idea their computers are being used to scan for
   and exploit other vulnerable systems on the Internet.  However, their
   systems have dedicated connections to the Internet, making them
   primary targets.  Even systems that dial-up to the Internet are at
   risk for such attacks.  There is a 'war' going on as automated worms
   seek out and compromise other systems.  They then use these systems as
   launching points to gain control of other systems, such as our
   honeypot.
   
   The Day After
   The next day, other variations of the same worm probed our honeypot.
   They first determine if sharing is enabled, and if so, they check if
   the same version of the worm is  already installed.  In both cases for
   this day, the worm was already installed, so the remote systems left
   us alone.  The first remote system checked to see if the wininit.exe
   worm was installed.  Later on that day, another system  checked to see
   if the worm msi216.exe was installed.
   
   11/03-04:42:11.596636 210.111.145.180:2341 -> 172.16.1.105:139
   TCP TTL:115 TOS:0x0 ID:12574  DF
   *****PA* Seq: 0x2345C04   Ack: 0xE65CC94   Win: 0x2171
   00 00 00 5D FF 53 4D 42 2D 00 00 00 00 00 01 00  ...].SMB-.......
   00 00 00 00 00 00 00 00 00 00 00 00 00 D8 B5 1D  ................
   00 00 81 3E 0F FF 00 00 00 07 00 91 00 16 00 20  ...>...........
   00 3A 26 02 3A 10 00 00 00 00 00 00 00 00 00 00  .:&.:...........
   00 00 00 1C 00 5C 57 49 4E 44 4F 57 53 5C 53 59  .....\WINDOWS\SY
   53 54 45 4D 5C 77 69 6E 69 6E 69 74 2E 65 78 65  STEM\wininit.exe
   00                                               .
   
   Remote system, NetBIOS name MATTHEW, account MPYLE, domain MPYLE
   
   11/03-16:39:38.723572 216.23.6.24:3946 -> 172.16.1.105:139
   TCP TTL:113 TOS:0x0 ID:3309  DF
   *****PA* Seq: 0x1A7105F   Ack: 0x10F8C0F2   Win: 0x2159
   00 00 00 5B FF 53 4D 42 2D 00 00 00 00 00 01 00  ...[.SMB-.......
   00 00 00 00 00 00 00 00 00 00 00 00 00 E0 AD 20  ...............
   00 00 81 D9 0F FF 00 00 00 07 00 91 00 16 00 20  ...............
   00 14 CE 02 3A 10 00 00 00 00 00 00 00 00 00 00  ....:...........
   00 00 00 1A 00 5C 57 49 4E 44 4F 57 53 5C 53 59  .....\WINDOWS\SY
   53 54 45 4D 5C 64 6E 65 74 63 2E 69 6E 69 00     STEM\dnetc.ini.
   
   The fun beings the following day, on November 04th. First, it begins
   with the system 207.224.254.206 (dialupF206.sttl.uswest.net, NetBIOS
   name SOCCERDOG, account SCOTT, domain RONS) checking to see if
   dnetc.ini is installed on our honeynet. It determines that the binary
   is already installed and leaves the honeypot allone. That makes a
   total of 5 system probing our honeypot for this worm in 3 days.  Later
   on that day our honeypot initiates a http connection to the system
   bymer.boom.ru.  This connection was most likely initiated by the worm
   and is attempting to update the master server.  The system
   bymer.boom.ru was most likely at one time the master controller for
   this worm.  However, the system name bymer.boom.ru now resolves to an
   RFC 1918 IP address, 192.168.01.  Most likely an attempt by the domain
   owner to stop the worm.  Also, for the worm to execute like this, the
   system would need to have been rebooted at some time.  That is the one
   thing we have not figured out, if the system was rebooted, and if so,
   how.  One of the drawbacks of a Windows based honeypot is the limited
   availability of information, due to nonexistent logs.   Below we see
   the honeypot initiating a connection to bymer.boom.ru, most likely the
   master server for the worm.
   
   11/04-23:56:38.855453 172.16.1.105:1027 -> 192.168.0.1:80
   TCP TTL:127 TOS:0x0 ID:65300  DF
   **S***** Seq: 0x17AF8D9A   Ack: 0x0   Win: 0x2000
   TCP Options => MSS: 1460 NOP NOP SackOK
   
   Immediately following this the dnetc.exe client connects to the
   distributed.net server and begins a data transfer.  This is part of
   the the distributed.net client and not part of the worm replication
   process.  However, this is the end purpose of the worm, to burn CPU
   cycles and upload the results to distributed.net.
   
   11/04-23:56:40.286898 172.16.1.105:1029 -> 204.152.186.139:2064
   TCP TTL:127 TOS:0x0 ID:1301  DF
   *****PA* Seq: 0x17AF8F47   Ack: 0xBE445ED3   Win: 0x2238
   AE 23 E2 77 F6 42 91 51 3E 61 3F EE 86 7F EE 8B  .#.w.B.Q>a?.....
   CE 9E 9D 28 16 BD 4B C5 5E DB FA 62 A6 FA A8 FF  ...(..K.^..b....
   EF 19 57 9C 37 38 06 39 7F 56 B4 D6 C7 75 63 73  ..W.78.9.V...ucs
   0F 94 12 10 57 B2 C0 AD 9F D1 6F 4A E7 F0 1D E7  ....W.....oJ....
   30 0E CC 84 78 2D 7B 21 C0 4C 29 BE 08 6A D8 5B  0...x-{!.L)..j.[
   50 89 86 F8 98 A8 35 95 E0 C6 E4 32 28 E5 92 CF  P.....5....2(...
   71 04 41 6C B9 22 F0 09 01 41 9E A6 49 60 4D 43  q.Al."...A..I`MC
   91 7E FB E0 D9 9D AA 7D 21 BC 59 1A 69 DB 07 B7  .~.....}!.Y.i...
   B1 F9 B6 54 FA 18 64 F1 42 37 13 8E 8A 55 C2 2B  ...T..d.B7...U.+
   CF 32 45 19 1A 93 1F 65 62 B1 CE 02 AA D0 7C 9E  .2E....eb.....|.
   C5 46 78 29 F0 13 97 04                          .Fx)....
   
   Once the upload is complete, the worm kicks into high gear and begins
   searching the Internet for other vulnerable system to replicate and
   spread itself. It randomly selects IP addresses and begins scanning
   those systems on ports 137 and 139.  The worm identifies vulnerable
   systems (similar to our honeypot) and the replicates itself to the
   remote system. Compromised systems like these are one of the reasons
   for the high number of scans we have seen.    Keep in mind, the
   Honeynet environment is designed to block any malicious traffic
   initiated by a compromised honeypot, so these scans never reach the
   Internet.  The Honeynet is kind of like the 'roach motel'.  It lets
   the bad guys in, but won't let them out.  Below you see the worm
   attempting to find other vulnerable systems.
   
   11/04-23:58:05.946299 172.16.1.105:137 -> 39.202.248.187:137
   UDP TTL:127 TOS:0x0 ID:30485
   Len: 58
   0E 94 00 10 00 01 00 00 00 00 00 00 20 43 4B 41  ............ CKA
   41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
   41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21  AAAAAAAAAAAAA..!
   00 01
   
   One thing I found interesting was that the configuration file
   c:\windows\win.ini had been modified once again, most likely by the
   wininit.exe worm.  The worm removed the entry of the msi216.exe worm
   from the startup configuration file, leaving itself in control.
   Also, the dnetc.ini file had been modified once again, changing the
   email address from bymer@inec.kiev.ua to the new email address
   bymer@ukrpost.net.  This indicates that the second worm attempted to
   take over the first by eliminating it from the configuration files.
   This shows an extremely aggressive nature of worms, where one worm
   competes with another worm for real estate, or in this case CPU
   cycles..
   
   If you would like to review this data yourself, you can download the
   file win98.tar.gz.  This gzipped file contains the four days of snort
   captures in binary format and all of the worms binaries on the
   honeypot, including wininit.exe and msi216.exe.  Keep in mind, these
   are worms found in the wild, so you are working with malicious
   material.  Be extremely careful working with it.  For those of you who
   prefer not to mess with the worm binaries, you can download
   win98-wo.tar.gz.  This gzipped file contains everything win98.tar.gz
   contains, except for the two worm binaries wininit.exe and msi216.exe.
   
   Conclusion
   We have covered how in a 4 day period a Windows98 system was
   compromised by several worms.  These worms are automated probes that
   identify and exploit vulnerable systems, exponentially replicating
   themselves.  Its systems like these that are most likely scanning the
   Internet for NetBIOS vulnerabilities.  This does not imply that every
   NetBIOS scan you receive is an automated worm.  Nor that all worms are
   based for distributed.net.  Consider if this worm was modified to look
   for confidential information on your system.  The worm could easily
   search for documents with the words finance, confidential, secret or
   SSN.  Once it found these documents, the information could easily be
   forwarded to an anonymous email account, IRC channel, or compromised
   webserver.  The attacks are limited only by the imagination of the
   black-hat community.
   
   Acknowledgements
   In addition to the Honeynet project, this paper is the result of hard
   work and great input from two key individuals.  A big thank you goes
   out to H Carvey  and Ryan Russell. They were the main contributers to
   the technical decoding of the events that happened here. For
   additional information about these vulnerabilities, both
   distributed.net and CERT have posted advisories.
   
   
   
                         Whitepapers / Publications