Friendly World of Cyberspace

Friendly World of Cyberspace

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.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.
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
Page 2 of 8 Know Your Enemy
4/6/2004 http://project.honeynet.org/papers/worm/
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
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\RunServices\Bymer.scann
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 Windows 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-.......
Page 4 of 8 Know Your Enemy
4/6/2004 http://project.honeynet.org/papers/worm/
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 ...>...........
Page 5 of 8 Know Your Enemy
4/6/2004 http://project.honeynet.org/papers/worm/
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.0.1. 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.
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.

hosted by : a lonely israeli mossad agent .