Revision History:
24 May 2003: Initial post with partial details.
22 June 2003: Adding a few post-mortem details.
This program wasn't actually received for many hours after it first showed itself. I first started receiving connections like this, which I had been ignoring (IP addresses obfuscated):
05/22/03 05:38:24 GMT: connection to 66.75.XXX.XXX:445 from 24.25.XXX.XXX:30686 05/22/03 05:38:28 GMT: client disconnected 05/22/03 05:38:28 GMT: SMB session ended 05/22/03 05:38:29 GMT: connection to 66.75.XXX.XXX:445 from 24.25.XXX.XXX:30838 SMB_COM_SESSION_SETUP_ANDX(1): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' SMB_COM_SESSION_SETUP_ANDX(3): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' User: 'SMOOTH', Domain: 'LAMEXP', WKS: 'LAMEXP' SMB_COM_TREE_CONNECT_ANDX: '\\66.75.XXX.XXX\IPC$' SMB_COM_NT_CREATE_ANDX: '\srvsvc' in TID = 0001 SMB_COM_TRANSACTION, \srvsvc, RPC request opnum 15 (NetrShareEnum): not implemented error 05/22/03 05:38:35 GMT: client disconnected 05/22/03 05:38:35 GMT: SMB session ended 05/22/03 05:38:35 GMT: connection to 66.75.XXX.XXX:445 from 24.25.XXX.XXX:31081 SMB_COM_SESSION_SETUP_ANDX(1): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' SMB_COM_SESSION_SETUP_ANDX(3): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' User: 'SMOOTH', Domain: 'LAMEXP', WKS: 'LAMEXP' SMB_COM_TREE_CONNECT_ANDX: '\\66.75.XXX.XXX\IPC$' 05/22/03 05:38:39 GMT: client disconnected 05/22/03 05:38:39 GMT: SMB session ended
What the remote system is doing is connecting, enumerating the local system's shares, and then disconnecting. If this had been just a one-time event or had been repeated from a single system, I would have continued to ignore it -- often, one will see "information gathering" events like this.
What made me curious was that I saw exactly the same pattern from different machines:
05/22/03 09:09:13 GMT: connection to 66.75.XXX.XXX:445 from 68.61.XXX.XXX:2900 05/22/03 11:37:06 GMT: connection to 66.75.XXX.XXX:445 from 68.64.XXX.XXX:2843 05/22/03 14:54:28 GMT: connection to 66.75.XXX.XXX:445 from 62.45.XXX.XXX:1216
Even more interesting to me, the probes were all coming from Windows XP systems -- as identified by the "Windows 2002 2600" string above. A few hours later, I got two more probes with this pattern fairly close together (20 minutes), which gave me the feeling that whatever was doing this was automated and was spreading...
05/22/03 17:11:08 GMT: connection to 66.75.XXX.XXX:445 from 68.86.XXX.XXX:4451 05/22/03 17:34:05 GMT: connection to 66.75.XXX.XXX:445 from 24.94.XXX.XXX:2885
Fortunately, only a slight modification to my program was necessary to support share enumeration. After adding this, here's what I got:
05/22/03 23:35:59 GMT: connection to 66.75.XXX.XXX:445 from 210.54.XXX.XXX:4637 05/22/03 23:36:05 GMT: client disconnected 05/22/03 23:36:05 GMT: SMB session ended 05/22/03 23:36:05 GMT: connection to 66.75.XXX.XXX:445 from 210.54.XXX.XXX:4648 SMB_COM_SESSION_SETUP_ANDX(1): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' SMB_COM_SESSION_SETUP_ANDX(3): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' User: 'BFT582', Domain: 'SUPRA', WKS: 'SUPRA' SMB_COM_TREE_CONNECT_ANDX: '\\66.75.XXX.XXX\IPC$' SMB_COM_NT_CREATE_ANDX: '\srvsvc' in TID = 0001 05/22/03 23:36:19 GMT: client disconnected 05/22/03 23:36:19 GMT: SMB session ended
Hmmm. No real difference. This first attempt was returning the typical administrative shares for a Windows NT or Windows 2000 system, which are C$, ADMIN$, and IPC$.
Given that all of the systems were running XP and there were connections such as the one shown above that were likely a dialup connections, after a while I guessed that many of these systems were probably running XP Home Edition. XP Home doesn't have administrative shares, which suggested that whatever was scanning was looking for a share that was manually made by the computer owner/operator.
So after adding a few of these shares, I finally saw what was supposed to happen. Here's the log for one of those events:
05/23/03 18:22:18 GMT: connection to 66.75.XXX.XXX:445 from 68.48.XXX.XXX:4006 SMB_COM_SESSION_SETUP_ANDX(1): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' SMB_COM_SESSION_SETUP_ANDX(3): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' User: 'Administrator', Domain: 'DAILO', WKS: 'DAILO' SMB_COM_TREE_CONNECT_ANDX: '\\66.75.XXX.XXX\IPC$' SMB_COM_NT_CREATE_ANDX: '\srvsvc' in TID = 0001 SMB_COM_SESSION_SETUP_ANDX(1): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' SMB_COM_SESSION_SETUP_ANDX(3): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' User: '', Domain: '', WKS: 'DAILO' SMB_COM_TREE_CONNECT_ANDX: '\\66.75.XXX.XXX\IPC$' SMB_COM_TREE_CONNECT_ANDX: '\\66.75.XXX.XXX\C' SMB_COM_SESSION_SETUP_ANDX(1): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' SMB_COM_SESSION_SETUP_ANDX(3): OS: 'Windows 2002 2600', LM: 'Windows 2002 5.1', Dom: '' User: 'Administrator', Domain: 'DAILO', WKS: 'DAILO' SMB_COM_TREE_CONNECT_ANDX: '\\66.75.XXX.XXX\C' SMB_COM_NT_CREATE_ANDX: '\Documents and Settings\All Users\Start Menu\Programs\Startup\file.exe' in TID = 0004 CLOSE: 'C\Documents and Settings\All Users\Start Menu\Programs\Startup\file.exe' --> '.\SS2304.tmp', 46624 For file titled 'C\Documents and Settings\All Users\Start Menu\Programs\Startup\file.exe', wrote 46624 bytes to file '.\SS2304.tmp' creation time: 5/23/2003 6:23:12 PM last write time: 5/18/2003 11:29:48 PM last access time: 5/23/2003 6:23:12 PM 05/23/03 18:23:32 GMT: client disconnected 05/23/03 18:23:32 GMT: SMB session ended
As can be seen, after the initial enumeration of shares, the "C" share -- a sadly popular name for computer owners who share their whole hard drive -- is connected to and the file is copied to the "All Users" Startup folder.
Once deposited on the local system, the file will remain dormant until a new user logs in or the system restarts. Several popular anti-virus programs already generically detect this file -- assuming the virus signatures are up-to-date -- and should stop it at this point.
Click here for McAfee's write-up on this family of worms.
This is a single, self-contained program and is not obfuscated in any way. When the program is run for the first time, it copies itself to the Windows system directory with the name "svshost.exe." It also creates a subdirectory in the Windows system directory named "kazaabackupfiles" and makes multiple copies of itself there, renamed mostly as cracks for games. It configures the system to run itself on startup by setting values in two autostart Registry keys:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Runonce
In both cases, the value name is "Winsock2 driver."
Using the strings utility from SysInternals, we can get a good idea about what the program is doing.
Given the reference to Kazaa, it made more sense that the program was spreading through peer to peer (P2P) sharing than through open Windows file shares. Once spread out, the infected systems are scanning for unprotected Windows file shares, but there are likely fewer targets than P2P systems with a folder shared. Looking through the strings in the file, one sees the Kazaa Registry key, "SOFTWARE\KAZAA\LocalContent" and a quick search for this on Google yields the likely method of propagation via Kazaa. This is an older worm, but the technique is likely the same as described here -- look in the section "KaZaa Propagation." And looking at the strings list, we see those strings:
Dir0 SOFTWARE\KAZAA\LocalContent 012345:%s
So, what the program is doing is essentially sharing the kazaabackupfiles folder it created through Kazaa -- assuming that Kazaa exists on the targeted system.
These strings in the program file indicate the presence of a simple HTTP server; this likely facilitates picking up data from the keystroke logger:
HTTP/1.0 200 OK Server: SpyBot1.2 Date: %s %s GMT Content-Type: %s Accept-Ranges: bytes Last-Modified: %s %s GMT Content-Length: %i Connection: close ddd, dd MMM yyyy application/octet-stream text/html GET HTTP server listining on poort: %i root dir: %s\
These strings in the file indicate keystroke logging capabilities:
Keylogger stoped Keylogger logging to %s Keylogger active output to: DCC chat Keylogger active output to: %s error already logging keys to %s use "stopkeylogger" to stop
It has been about four weeks since this particular "strain" was discovered and since then several more variations were released; however, most of the anti-virus and anti-trojan vendors have developed generic detection routines (or already had them) for this and the scanning and replication activity I've seen here has essentially stopped.
In case anyone has found this page in relation to a suspected infection, the intent behind this write up was mostly to complement existing descriptions of this malware. If you have anti-virus and/or anti-trojan software, make sure they are up-to-date.
If you are attempting manually remove malware, then I always suggest the following general rules:
More thorough details on how to do these steps are available elsewhere; one suggestion is cert.org. Here are a couple of relevant papers: