Worm attacks

[Carter Bullard]

Hey Peter,
   Thanks, I am primarily interested in methods for detecting
infested servers from the logs.  Yours is really nice because
its not vulnerability signature detection, it's actually a
general behavioral deviation test, so that no matter if the
worm got on through the network, a modem, or a floopy disk,
you'll pick up the behavioral changes that the worm induces.

   One thing I'm very interested in is detection of the first
covert channel that is used to move the worm to the system.
This should be easily detected by a packet/byte count disparity
of a single HTTP session to a candiate server.  This would
really be dramatically different than any other port 80
connection to the infested server, and give you a thread back
to the source of the problem.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

   

> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu 
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of 
> Peter Van Epp
> Sent: Monday, July 23, 2001 11:15 AM
> To: argus
> Subject: Re: Worm attacks
> 
> 
> > 
> > Gentle people,
> >    Did any one catch any worm traffic this past week?
> > I'd love to see the first 64 bytes, if anyone has any
> > logs.  I'm guessing that Argus would have been the only 
> technology to 
> > automatically audited worm traffic from the last wave.
> > 
> > Carter
> > 
> > Carter Bullard
> > QoSient, LLC
> > 300 E. 56th Street, Suite 18K
> > New York, New York  10022
> > 
> > carter at qosient.com
> > Phone +1 212 588-9133
> > Fax   +1 212 588-9134
> > http://qosient.com
> > 
> > 
> 
> 	Yep, I can likely supply argus logs. As well argus 
> finds them just fine. So far its found three that security 
> focus has so far either missed or not gotten to yet. It also 
> sparked this (from my login article):
> 
>         A news break, as I type this (on July 19) the IIS red 
> worm has broken out. This provides a case study in using 
> argus for unconventional things. A CERT notification 
> yesterday gave me my first infected machine. A look at the 
> argus log indicates a signature of many mostly 0 length 
> connection attemtps to off site web servers. So a quick perl 
> script that takes the argus ra tool output as input and 
> selects accesses to port 80 not on any of my nets gets 
> written quickly. The source and destination ip addresses get 
> stored in an assocoative array indexed by source and 
> destination ip address and then sorted. As long as the source 
> address is the same, increment a counter (because this is a 
> new destination access from this same host). Once the source 
> address changes store the source address in a new associative 
> array indexed by the remote host count. When the entire file 
> has been processed, sort the array of counts in reverse 
> numeric order and write it to standard out. This is about a 
> page of perl and an hour or so of work. The output looks like 
> this (with the addresses obscured to protect the guilty):
> 
> 100539
>         1xx.yy.zzc.65
> 
> 271
>         1xx.yy.zze.6
> 
> 269
>         1xx.yy.zzc.161
> ...
> 
>         The first address (and 9 more like it across both our 
> campuses) is a machine affected with the iis red worm 
> scanning other machines. The other two hosts are normal 
> accesses. This is a fine example of having all the data 
> passing through your network being very useful. A firewall 
> would ignore this, they were http accesses on port 80. There 
> are reports the inital snort rule wasn't catching all of 
> these because of a rule mistake. The mark one eyeball (after 
> some thinking and data processing) has no problem picking the 
> difficulty out of the noise and a manual scan of the argus 
> log verifies that this really is the worm (again with 
> addresses obscured) from the ra output itself:
> 
> Thu 07/19 06:56:44 s    tcp   1xx.yy.zzc.65.60806  -> 
> aaa.165.233.142.80    3
>    0       0         0        REQ
> Thu 07/19 06:56:44 s    tcp   1xx.yy.zzc.65.60791  ->   
> bb.147.29.238.80    3
>    0       0         0        REQ
> Thu 07/19 06:56:44 s    tcp   1xx.yy.zzc.65.60813  ->    
> cc.123.5.126.80    3
>    0       0         0        REQ
> Thu 07/19 06:56:44 s    tcp   1xx.yy.zzc.65.60768  ->    
> dd.60.30.131.80    3
>    0       0         0        REQ
>        ... (lots more just like this. 100,535 of them in fact ...)
> 
> So whack this host off the network and proceed with our 
> interrupted story.
> 
> Peter Van Epp / Operations and Technical Support 
> Simon Fraser University, Burnaby, B.C. Canada
> 
> 
> 
>