Snort mailing list archives

RE: Cyberkit signature


From: "Eric Hines" <eric.hines () appliedwatch com>
Date: Sat, 30 Aug 2003 04:27:44 -0500

Erek,

Additionally, here is a page provided from Symantec that gives packet
dumps of several of the variants.

http://securityresponse.symantec.com/avcenter/venc/data/detecting.traffi
c.due.to.rpc.worms.html


Detecting network traffic that may be due to RPC worms
Last Updated on: August 28, 2003 04:51:46 PM PDT 

  
  

This information is designed to help network administrators identify
systems that W32.Blaster.Worm, W32.Welchia.Worm, or possibly other RPC
worms have infected. 

You must have a sniffer, such as tcpdump or windump, which should be
placed in a network location that sees a lot of traffic, so that you
will see as many infection attempts as possible.

W32.Blaster.Worm
Sniff for traffic destined for port 135/tcp, 4444/tcp, and 69/udp. The
correlation of these three types of traffic going from one machine to
another most likely indicates a successful infection. 

In the following example, the interesting ports are displayed in bold
font:

17:15:36.395032 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
17:15:36.395323 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
17:15:36.395436 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
17:16:19.508095 192.168.0.1.1294 > 192.168.0.3.135: tcp 72 (DF)
17:16:19.508310 192.168.0.1.1294 > 192.168.0.3.135: tcp 1460 (DF)
17:16:19.508346 192.168.0.1.1294 > 192.168.0.3.135: tcp 244 (DF)
17:16:19.508362 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
17:16:19.508541 192.168.0.3.135 > 192.168.0.1.1294: tcp 60 (DF)
17:16:19.508681 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
17:16:19.508720 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
17:16:19.512201 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
17:16:19.512346 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
17:16:19.904949 192.168.0.1.1314 > 192.168.0.3.4444: tcp 0 (DF)
17:16:19.905031 192.168.0.3.4444 > 192.168.0.1.1314: tcp 0 (DF)
17:16:19.905160 192.168.0.1.1314 > 192.168.0.3.4444: tcp 0 (DF)
17:16:19.952874 192.168.0.3.4444 > 192.168.0.1.1314: tcp 42 (DF)
17:16:19.984939 192.168.0.1.1314 > 192.168.0.3.4444: tcp 36 (DF)
17:16:19.985029 192.168.0.3.4444 > 192.168.0.1.1314: tcp 63 (DF)
17:16:20.083469 192.168.0.3.1049 > 192.168.0.1.69: udp 20
17:16:20.118800 192.168.0.1.69 > 192.168.0.3.1049: udp 516

In the above case, machine 192.168.0.1 is clearly infecting machine
192.168.0.3.

However some machines are protected, so the Blaster traffic will not
always look like this. For instance: 

If the attacked machines are patched, the 69/udp traffic and most of the
4444/tcp traffic will not be there because the shell code will not run. 
If the attacked machines have port 135 firewalled, the 4444/tcp and
69/udp traffic will not be there and the 135/tcp traffic will only be
failed connection attempts

In such cases, it is still possible to distinguish between the worm and
a legitimate connection to port 135/tcp, by looking for these
characteristics:

Traffic on port 135 with specific packet sizes can tell you quickly
whether an infection was attempted. Specifically, the three packet sizes
(in bold) are associated with the RPC/DCOM exploit, which both Blaster
and Welchia used (and other pieces of malware used them, too):
17:15:36.395032 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
17:15:36.395323 192.168.0.3.135 > 192.168.0.1.1294: tcp 0 (DF)
17:15:36.395436 192.168.0.1.1294 > 192.168.0.3.135: tcp 0 (DF)
17:16:19.508095 192.168.0.1.1294 > 192.168.0.3.135: tcp 72 (DF)
17:16:19.508310 192.168.0.1.1294 > 192.168.0.3.135: tcp 1460 (DF)
17:16:19.508346 192.168.0.1.1294 > 192.168.0.3.135: tcp 244 (DF)


Rapid succession of connections from one host to a series of hosts with
nearby IP addresses. For instance:
17:07:54.032412 15.54.153.107.1038 > 15.54.152.106.135: tcp 0 (DF)
17:07:54.032657 15.54.153.107.1039 > 15.54.152.107.135: tcp 0 (DF)
17:07:54.032901 15.54.153.107.1040 > 15.54.152.108.135: tcp 0 (DF)
17:07:57.032668 15.54.153.107.1039 > 15.54.152.107.135: tcp 0 (DF)
17:08:14.060589 15.54.153.107.1074 > 15.54.152.125.135: tcp 0 (DF)
17:08:14.062041 15.54.153.107.1078 > 15.54.152.129.135: tcp 0 (DF)
17:08:14.064937 15.54.153.107.1086 > 15.54.152.137.135: tcp 0 (DF)
17:08:17.061195 15.54.153.107.1086 > 15.54.152.137.135: tcp 0 (DF)
17:08:23.069724 15.54.153.107.1086 > 15.54.152.137.135: tcp 0 (DF)
17:08:35.489747 15.54.153.107.1104 > 15.54.152.141.135: tcp 0 (DF)
17:08:44.307318 15.54.153.107.1145 > 15.54.152.177.135: tcp 0 (DF)
17:08:44.308202 15.54.153.107.1148 > 15.54.152.180.135: tcp 0 (DF)

Also notice that the ephemeral source ports on the attacking machine
increase monotonically by one per connection attempt, because the
attacker devotes almost all his/her network connections to attacking new
machines in quick succession.

W32.Welchia.Worm
The traffic on port 135 looks the same as that of Blaster. In
particular, the port 135 packet sizes highlighted above are the same.
However, Welchia has a connect-back shellcode, so that network traffic
during an infection looks slightly different. Look for a ping, then
traffic on port 135/tcp, 666-to-765/tcp, then 69/udp, like this:

11:47:47.576542 169.254.56.166 > 169.254.189.84: icmp: echo request
11:47:47.578331 169.254.189.84 > 169.254.56.166: icmp: echo reply
11:47:47.612221 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
11:47:47.624560 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
11:47:47.624664 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
11:47:47.625523 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
11:47:47.625556 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
11:47:47.626258 169.254.56.166.1038 > 169.254.189.84.135: tcp 72 (DF)
11:47:47.636660 169.254.189.84.135 > 169.254.56.166.1038: tcp 60 (DF)
11:47:47.637403 169.254.56.166.1038 > 169.254.189.84.135: tcp 1460 (DF)
11:47:47.637593 169.254.56.166.1038 > 169.254.189.84.135: tcp 244 (DF)
11:47:47.649841 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
11:47:47.649901 169.254.189.84.3008 > 169.254.56.166.707: tcp 0 (DF)
11:47:47.650456 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
11:47:47.656558 169.254.189.84.3008 > 169.254.56.166.707: tcp 0 (DF)
11:47:47.656640 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
11:47:47.656735 169.254.189.84.3008 > 169.254.56.166.707: tcp 39 (DF)
11:47:47.657001 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
11:47:47.657737 169.254.56.166.1038 > 169.254.189.84.135: tcp 0 (DF)
11:47:47.678106 169.254.189.84.135 > 169.254.56.166.1038: tcp 0 (DF)
11:47:47.800623 169.254.189.84.3008 > 169.254.56.166.707: tcp 104 (DF)
11:47:47.801332 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
11:47:47.801817 169.254.56.166.707 > 169.254.189.84.3008: tcp 22 (DF)
11:47:47.809133 169.254.189.84.3008 > 169.254.56.166.707: tcp 21 (DF)
11:47:47.943421 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
11:47:47.945248 169.254.189.84.3008 > 169.254.56.166.707: tcp 152 (DF)
11:47:47.958809 169.254.56.166.707 > 169.254.189.84.3008: tcp 24 (DF)
11:47:47.963702 169.254.189.84.3008 > 169.254.56.166.707: tcp 24 (DF)
11:47:48.147203 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
11:47:48.148097 169.254.189.84.3008 > 169.254.56.166.707: tcp 156 (DF)
11:47:48.148492 169.254.56.166.707 > 169.254.189.84.3008: tcp 57 (DF)
11:47:48.154321 169.254.189.84.3008 > 169.254.56.166.707: tcp 57 (DF)
11:47:48.344809 169.254.56.166.707 > 169.254.189.84.3008: tcp 0 (DF)
11:47:48.397446 169.254.189.84.3009 > 169.254.56.166.69: udp 20

Protected machines will not be infected, so the traffic above will not
always take place. But as long as you can sniff the pings, you can tell,
with good reliability, whether the ping request originates from Welchia,
by looking at the ping payload, which is filled with 0xaa. 

This is a complete dump of a Welchia ping request:

11:47:47.576542 169.254.56.166 > 169.254.189.84: icmp: echo request
0x0000 4500 005c 599d 0000 8001 970c a9fe 38a6 E..\Y.........8.
0x0010 a9fe bd54 0800 fa51 0200 a658 aaaa aaaa ...T...Q...X....
0x0020 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
0x0030 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
0x0040 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
0x0050 aaaa aaaa aaaa aaaa aaaa aaaa ............

To filter only such ping requests with a sniffer like windump, and not
show the legitimate pings, you can use a command such as:

"windump -qn icmp and ip[40] = 0xaa"

This will result in a display of all Welchia pings.

Another thing to look for is a succession of ARP requests for
consecutive addresses from the same host, like this:

11:43:50.435946 arp who-has 169.254.14.115 tell 169.254.56.166
11:43:50.438301 arp who-has 169.254.14.116 tell 169.254.56.166
11:43:50.445362 arp who-has 169.254.14.117 tell 169.254.56.166
11:43:50.460087 arp who-has 169.254.14.118 tell 169.254.56.166
11:43:50.466885 arp who-has 169.254.14.119 tell 169.254.56.166
11:43:50.482358 arp who-has 169.254.14.120 tell 169.254.56.166
11:43:50.484681 arp who-has 169.254.14.121 tell 169.254.56.166
11:43:50.498546 arp who-has 169.254.14.122 tell 169.254.56.166
11:43:50.505680 arp who-has 169.254.14.123 tell 169.254.56.166
11:43:50.514562 arp who-has 169.254.14.124 tell 169.254.56.166
11:43:50.531488 arp who-has 169.254.14.125 tell 169.254.56.166
11:43:50.534873 arp who-has 169.254.14.126 tell 169.254.56.166
11:43:50.546532 arp who-has 169.254.14.127 tell 169.254.56.166
11:43:50.554933 arp who-has 169.254.14.128 tell 169.254.56.166
11:43:50.570009 arp who-has 169.254.14.129 tell 169.254.56.166
11:43:50.577407 arp who-has 169.254.14.130 tell 169.254.56.166
11:43:50.588931 arp who-has 169.254.14.131 tell 169.254.56.166
11:43:50.600770 arp who-has 169.254.14.132 tell 169.254.56.166
11:43:50.606802 arp who-has 169.254.14.133 tell 169.254.56.166

 


Write-up by: Frederic Perriot 

 
 
 
 



Regards,

Eric Hines
CEO, Chairman

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

Eric Hines
CEO, Chairman
Applied Watch Technologies, Inc.
eric.hines () appliedwatch com
-----------------------------------------------
Corporate Headquarters
1650 Carlemont Dr. 
Suite D 
Crystal Lake, IL. 60014 
-----------------------------------------------
Direct Toll Free: (877) 262-7593 (x327)
Fax: (815) 425-2173 
-----------------------------------------------
Main Switchboard: (877) 262-7593 (9am-5pm CST)
Commercial Sales: (877) 262-7593 (opt1)
Government Sales: (877) 262-7593 (opt2)

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


-----Original Message-----
From: Erek Adams [mailto:erek () snort org] 
Sent: Friday, August 22, 2003 12:04 PM
To: djmurd () cox net
Cc: snort-users () lists sourceforge net; intrusions () incidents org
Subject: Re: [Snort-users] Cyberkit signature


On Thu, 21 Aug 2003 djmurd () cox net wrote:

Hey there - can any of you please point me to some reliable 
information that says the "cyberkit 2.2" signature is really the 
Nachia / Welchia worm?

Do you see a ton of them?  Are they coming from Win32 based hosts?  Then
probably yes.  :)  I forget where, but there was a writeup that had a
breakdown of the packets involved.  IIRC, there was a particular set of
bytes in the ping packet that you could trigger on.

I need some more ammo in order to block ICMP for our network...

Blocking ICMP is bad, M'kay?  </Mr.MackeyVoice>

You break MTU-Path discovery and a couple of other things.  You can if
you want, but it can wreak havoc on Solaris boxes if you're not careful.
Consider blocking the ICMP echo request of only the size that the worm
uses.  It's something odd like 91 bytes I think...

Cheers!

-----
Erek Adams

   "When things get weird, the weird turn pro."   H.S. Thompson





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users


Current thread: