Worm attacks

[Carter Bullard]

Gentle people,
   William Seltzer used another strategy, which was to use
a perl script to process ragator() output, looking for
obvious deviations in source/destination packet counts.
This gave him an indication of servers at his site that
were infested.  This was not as specific as Peter's strategy,
but it did go after similar behavioral deviation methodology
that Peter used.

   William did offer to share the script for those that
wanted it.  William_Setzer at ncsu.edu.

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
> 
> 
> 
>