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:
- Cyberkit signature djmurd (Aug 22)
- Re: Cyberkit signature Erek Adams (Aug 22)
- Re: Cyberkit signature Frank Knobbe (Aug 22)
- RE: Cyberkit signature Eric Hines (Sep 02)
- RE: Cyberkit signature Eric Hines (Sep 02)
- Re: Cyberkit signature Paul Schmehl (Aug 22)
- RE: Cyberkit signature Eric Greenberg (Aug 22)
- Re: Cyberkit signature Patrick Dolan (Aug 23)
- <Possible follow-ups>
- RE: Cyberkit signature Tony Bunce (Aug 22)
- RE: Cyberkit signature Schmehl, Paul L (Aug 22)
- RE: Cyberkit signature Paul Schmehl (Aug 22)
- RE: Cyberkit signature Tony Bunce (Aug 22)
- Re: Cyberkit signature Andrew . Patrick (Aug 25)
- RE: Cyberkit signature Smith, Donald (Aug 25)
- Re: Cyberkit signature Erek Adams (Aug 22)