Re: virus poking out to IRC

From: Bill Michaelson (bill@cosi.com)
Date: 12/24/02 

Date: Tue, 24 Dec 2002 13:23:05 -0500
From: Bill Michaelson <bill@cosi.com>

I googled muh before posting, which is why I described it as an IRC
relay pgm in my original post. I know what rhnsd is. The file I found
labeled rhnsd appears to be the muh program, renamed rhnsd, as I
indicated in my original post.

I am the only user of the network in the company, for which I make policy.

There are reports of virus packages extant that use IRC protocol and
typically exploit a system via ssh. However, ssh is blocked on this
system. Hence my inquiry here.

Thanks for your reply, but please read my posts more carefully.

Steve Webster wrote:

> Bill Michaelson wrote:
>
>> I discovered IRC traffic originating from a system on my network which
>> was apparently caused by a virus of some kind. Examination of the
>> system revealed a file - muh.tgz, unpacked into /usr/local/games/m00h
>> directory. One of the files was named rhnsd - apparently a disguised
>> version of the muh IRC relay program (educated guess). I also
>> restored corrupted versions of ls, netstat and ps on the system, but
>> oddly, I was still unable to identify what process was generating the
>> traffic, even as I could see the traffic originating from the system.
>> I tried using lsof, netstat and ps, but was unable to identify
>> anything suspicious with ps, or spot traffic on port 6667 with netstat
>> or lsof. Any suggestions for probing further? I'd like to identify
>> the exploit.
>>
>
> If you search Google for 'muh' you'll find that it's an IRC bouncing
> tool available for download (including the source) from SourceForge.
> It's not supposed to contain anything nasty (and you can check the
> source to confirm).
>
> rhnsd is the Redhat Network querying tool supplied with Redhat Linux.
> It periodically checks the Redhat site for updates (try man rhnsd).
>
> It looks like what you've got is a Redhat user who wants to keep their
> IRC connection alive. You could ask them (preferred approach) or run a
> packet sniffer to get more info (may violate company policy, not
> recommended).
>

Loading