Re: SV: Q328691 ?

[H C <keydet89 () yahoo com>]

First question...are you "jennifer smith" or "Kyle
Lai"?
 
> I haven't dealt with any previous IRC/Flood virus,
> so I can't say much in 
> that area.  You definitely have done your analysis. 
> I certainly like to 
> learn more about what you have learned.

As far as Backdoor.IRC.Flood and it's variants are
concerned, I simply read the alert, and then compared
what I saw to the info available on several A/V
sites...and none of it jived w/ what MS was saying.
 
> IRC was fun, until the hackers started using it as a
> tool.  It's 
> unfortunate, but I think we just have to deal with
> the fact.  I am sure 
> there will be another IRC type of virus because it's
> effective, and there are so many people on IRC...

IMHO, it's not so much that lots of folks are on IRC
(though that does have an effect), but that these bots
are easy to control via IRC.  In looking at the
"russiantopz" bot, I found in my research there are
several versions of the same sort of bot.  It seems
with the scripts that are installed w/ the bot, that
the bot itself logs into the designated channel, and
awaits commands.  All the controller has to do is log
into the channel (from anywhere) and issue a command. 
He could log in one day and find several hundred bots
logged in...and simply issue the command to run
"format c:\".  

Re: your analysis...

1.  Is there any info regarding what Netcat is used
for?  I know that if the attacker issues a command to
netcat, if they've set up a remote shell, there won't
be a command history that you can obtain via 'doskey
/history'...but has anyone had access to a system w/
the netcat listener running?  If so, listdlls.exe will
provide the command line used to launch the process...

2.  Use of psexec.exe...very interesting.  Remember
the Masy worm?  It used the executable from DebPloit
to gain local admin privileges on the system...and the
person who put the package together never bothered to
change the name of the executable.

3.  "I don't think there can be a conclusion on what's
lost if the systems were compromised."  You're right,
there can't be.  Unfortunately, most admins don't turn
on process tracking, or modify the EventLog in any
way.  If they do, they don't review the logs.  Testing
has shown that some of the compromises that take place
via directory transversal exploit to IIS (particularly
dumping files on the system via ftp/tftp, then
launching) result in a process running w/ IUSR_*
rights...which are equivalent to Guest, not
Administrator.  

In order to determine what's been compromised, admins
have to have monitoring systems (Tripwire, File System
Watcher, etc)...and they actually have to *use* them. 
Since this doesn't happen often...we won't know.

4. Regarding your conclusions regarding the intentions
of the attacker...I don't see anything wrong w/ it,
but I also know from experience that there are many
folks out there who are so strongly against making
assumptions of intent that it's almost quasi-religious
in nature.  Actually, what I've opted to do is stick
to the facts, and try to stay away from assumptions. 
If files are copied or deleted, state that fact w/o
trying to come up w/ reasons why.  Just a suggestion.

Your write-up is interesting, but I'd still like to
know more about the files...is there an archive of the
files someplace, or a copy of the OCXDLL.EXE you could
zip up and send me? 


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.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