[unisog] Infected windows boxes with IRC controlled trojans
tal1 at its.nyu.edu
Wed Apr 10 20:29:30 GMT 2002
We have had a number of our machines hit with this and I think that
it started when I started the discussion of the coordinated scans we
saw about 2 or 3 weeks back. One of our technicians, Christian, sent
the following message after doing some forensics on an infected
>Here's what i found. On startup a file called RUDL32.EXE is executed, this
>spawns a number of sxeNN.TMP files (all random) and locates them in the
>One thing i found that was different from the email [sent on unisog
>with infor on what files to look for] was that once the mIRC
>client is launched it references a mirc.ini file created by the virus that
>contains the script /run *path temp2.exe. deleting this file along with
>DLL32NOS.exe will stop the client from running. Then by deleting
>RUDL32.exe you stop the sxeNN processes from occuring at startup. The
>FTP-Serv function seemed to be absent from this infection.
Again, this only affected machines that _did not_ have their Admin
passwords set <sigh>...
He also had the following comments on removal after inspecting a
>First of all, NAV [Norton Anti Virus] had already quartined a number
>of files on this machine and identified them as having been infected
>with a number of viruses and files associated with those:
>W32.lxd.mirc = Whvlxd.exe - quarantined. This was an old virus, it
>just places the file WHVLXD.exe in the /System folder and adds a
>value to the registry:
>idea why this file was there. It's not dropping anything though.
>Norton picked it up and moved it, and we still had the same issues.
>In the registry under
>you'll find 2 instances of CMD32.exe being referenced, delete these values.
>Also, do a registry search for Firedeamon.exe. You'll most likely
>find it in a key called 'Filesof TypeMRU' under the 'Explorer Bars'
>key. Delete the entire 'Filesof TypeMRU' key. Note: you'll also find
>references to the current DarkIRC client in the form of sxeNN.tmp
>which leads me to believe that the key is created at startup -
>therefore deleting if may not have any effect.
>Firedaemon can turn any program into a system service, and is
>configurable from a command prompt so perhaps some paramaters were
>tacked on and that was why CMD32.exe was running at startup.Taking
>the CMD32 value out of
>Could this have anything to do with the UNICODE exploit? Probably
>not, the only thing it shares in common with Backdoor.NTHack seems
>to be the use of FirDaemon to bind to Serv-U. I didn't check for
>serv-u.exe or anything like that but there were two LSAS.exe
>processes running on the infected machine and about 4 simultaneous
>FireDaemon.exe processes going on too.
>This is probably another mutation of the DarkIRC worm, only finding
>it on Win2k boxes with blank admin passwords.
It looks like there may be a few versions of this out there...or,
some of the compromises weren't able to fully complete their install?
If anyone can come up with better solutions on how to get rid of
this, input is welcomed. :-)
Network Security Analyst security at nyu.edu
ITS - Network Services http://www.nyu.edu/its/security
New York University (212) 998 - 3433
PGP Fingerprint: 8FFB FE47 6156 7BF0 B19E 462B 9DFE 51F5
At 10:20 AM -0700 4/10/02, Allen Chang wrote:
>We have been looking at this for 2-3 weeks now. The degree of
>infection/compromise varies. The machines compromised on our network were
>all Win2k without Administrator passwords. It appears that a bot is being
>used to compromise the machine and the owner comes around later to run
>sua.bat and do all sorts of juicy stuff. A probable method is using PsExec
>to start telnet.
>Our machines also had a directory created in C:\RECYCLYER that had the
>same name as the recycle bin and was attrib +s +r +h. That apparently was
>set as the upload dir for the XDCC bot.
>Also, \winnt\system32\vmn32\ contains the contents of vmn32.exe. Including
>lsass.exe, which is used to open multiple services.
>The IRC channel passwords are actually in one of the mirc.ini files
>(haven't had time to look). It probably uses strange ASCII characters but
>it's in there somewhere.
>I'm refining removal instructions right now and will forward to the list
More information about the unisog