RE: Trinoo/TFN type activity... --UPDATE

["Grimes, Shawn (NIA/IRP)" <GrimesSh () grc nia nih gov>]

Here's the latest update.  I put a spare drive into the server, took out the
infected one, installed Red Hat 7.2 on the clean drive.   (everything is
still disconnected from the network).  I add the infected drive as a second
one and mount it up in some folder /mnt/oldroot/, /mnt/oldusr/,
/mnt/oldvar/, /mnt/oldtmp/ .  So I'm booting into a clean system but able to
access the dirty drive.  Then I ran the nice utility find_ddos from
www.nipc.org/warnings/alerts/1999/trinoo.htm and found the pattern "skillz"
and "3.3.3.3" in my /etc/mysql executable.  So there ya go.  Hope that helps
someone else in the future.


-----Original Message-----
From: Grimes, Shawn (NIA/IRP) 
Sent: Wednesday, November 21, 2001 1:35 PM
To: 'incidents () securityfocus org'
Subject: Trinoo/TFN type activity...


Looking for some help...

I just became the Security Analyst for the site I'm at now a few months
ago.  While testing some new firewall rules today, ones that would block
outgoing ICMP Echo Replys (to block pings from the outside), I found
that there were a series of outgoing request from a specific server,
approximately 100+ in a minute or two.  So I started doing a tcpdump on
the box and found that the echo replys were not being prefixed with an
echo request.  Further inspection found that the word "skillz" was in
the data field of the packet.  A little research on the wonder web found
that it was indicative of Trinoo/TFN/stacheldraht.  The problem is that
the ID field is 0 and not 666 which makes me think that whomever
infiltrated this computer did not use the defaults of the program.  I've
used the tools given by David Dittrich to discover a DDOS but they bring
up nothing, I'm assuming again because they didn't use the defaults.  

I've also done an nmap and I see that there is something running on port
1019 that comes up unknown.  I used netcat to connect to that port but
again came up with nothing.  

I ran lsof but didn't see anything out of the ordinary (at least no
mserv or td).  

I can wipe this box because it was a development box (which is probably
why it got nailed and wasn't secure in the first place (will be in the
future though)) but I was hoping as to a direction to go in now in case
I find similar boxes that are production boxes and can't be wiped.  Any
ideas would be great.

Thanks,
Shawn Grimes
grimessh () grc nia nih gov

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com