SQLServerCentral Article

SQLsnake Worm Hits SQL Servers and Networks Hard


If you haven't changed the SA password on your SQL Server, you may be soon

paying the price. Beginning last week, an old worm has come back in full force,

infecting about 100 SQL Servers an hour.  Reports of heavy port 1433

scanning began in early may but by the 22nd, the virus really began to take its

hold on systems with no SA password.

The worm code named "SQLsnake" attacks SQL Servers with no SA password. Once

it finds a server with no SA password, it then attacks your system in the

following order using the XP_CMDSHELL extended stored procedure (allows it to

shell to a command prompt):

  • Enables the domain's Guest account if it is not already
  • Grants the Guest account Administrator rights to the local machine
  • Grants the Guest account Domain Admin rights to the domain
  • Copies itself to your system directory
  • Gathers information about the databases, network interfaces and your

    Windows password hash into a file

  • Emails the file to

    ixltd@postone.com, which is an overseas

    e-mail address that we believe was originally owned by the worm's author

  • Begins to look for other

    SQL Servers in your network and outside your network to infect

It is now believed that more

than 10,000 systems have been affected, but what is even more scary is that this

could be only the first attempt at the virus. Back in November of last year, a

similar virus infected a modest amount of SQL Servers but did not propagate as

well as SQLsnake.  Original reports I read stated that this virus only

infected SQL Server 7.0 since it was the only server that shipped with a blank

password. This is incorrect however. SQL Server 2000 machines are less

vulnerable, but still can be poorly configured to have a blank SA password. To

prevent your SQL Server from being infected, take the following action:

  • Change your SA password to a non-blank and hard to crack password
  • If you're not blocking

    TCP port 1433 and UDP port 1434 to untrusted areas, do so now.

  • Make sure your SQL Server

    is not running under an account like LocalSystem or a domain account with lots

    of permissions, like a Domain Admin or an Account Operator

If you think there's a risk of infection in your network, you can run a free

tool by E-Eye to scan you network for infected machines. The SQL Scanner is

available for free on

their website.

If you have been infected, you can remove the virus by performing the

following steps:

First, unhide the virus' files by using the attrib command file at the command


attrib -h %WinDir%\system32\drivers\services.exe

attrib -h %WinDir%\system32\sqlexec.js

attrib -h %WinDir%\system32\clemail.exe

attrib -h %WinDir%\system32\samdump.dll

attrib -h %WinDir%\system32\pwdump2.exe

attrib -h %WinDir%\system32\sqlprocess.js

attrib -h %WinDir%\system32\sqlinstall.bat

attrib -h %WinDir%\system32\sqldir.js

attrib -h %WinDir%\system32\run.js

attrib -h %WinDir%\system32\timer.dll

Then, delete the virus' files:

del %WinDir%\system32\drivers\services.exe

del %WinDir%\system32\sqlexec.js

del %WinDir%\system32\samdump.dll

del %WinDir%\system32\clemail.exe

del %WinDir%\system32\sqlprocess.js

del %WinDir%\system32\sqlinstall.bat

del %WinDir%\system32\sqldir.js

del %WinDir%\system32\run.js

del %WinDir%\system32\timer.dll

del %WinDir%\system32\pwdump2.exe

And unregister the following DLL file

regsvr32 /u TIMER.DLL

Finally, delete the

following registry keys:




An additional word of

warning is that once the virus infects your outer SQL Server, it can begin to

attack and infect other SQL Servers in your network that may be on the other

side of a firewall. What worries me most about this virus is the ratcheting up

in intensity of these worms. This is not a SQL Server flaw, but a user flaw. In

a way, it's like locking the doors of your house, but leaving the window wide

open next to the door. No matter what the environment, including development,

never have an SA password that is blank.