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
This archive was generated by hypermail 2b30 : Mon Sep 09 2002 - 12:22:56 PDT