A Deep Dive into Database Attacks [Part II]: Delivery and Execution of Malicious Executables through SQL commands (SQL Server)


An organization’s database servers are frequently the prime target of attackers. We recently started a new research project we named StickyDB to learn more about database hacking, primarily to understand common database attacks, tools and techniques engaged by attackers.

To conduct this research, we set up a honeypot net for popular SQL/NoSQL databases and then monitored access to these databases over a period of six months.

We’ve broken down our research results into a five-part series. In this post we’ll cover different techniques for execution of SQL and OS commands through Microsoft SQL server that can be used for delivering and executing malicious payloads on the target system.

Find and Own a Database Server

In the last few months we investigated multiple attack campaigns launched by a Chinese crime group against MS SQL and MySQL database servers. These attack campaigns included three main phases: scanning, attacking and delivering malicious payloads. In this paper we’ll discuss the last phase of these attacks – malicious payload delivery and execution techniques.

A little bit of background: these attacks usually begin with scanning subnets and creating a list of machines that run different services such as HTTP web servers, and MS SQL and MySQL. Once the scan is finished, attackers will try to achieve initial access to database servers by brute forcing username and passwords. After attackers get in, they use automated tools to run SQL commands to gain full control of the target servers.

A full takeover of these servers is typically completed by a delivery of the malicious payload from a temporary FTP or HTTP server. The payloads we collected from the attacks are crypto miners, DDoS bots and various remote access trojans (RATs).

Figure 1: Database takeover process

Delivery and Execution of Malicous Executables on the Target System

Typically, a malicious payload can arrive at the database server in two main ways: It can be created directly on the target system or be downloaded from a remote server through SQL commands. In the next section we’ll discuss different methods to create and run an executable on a target system.

Creating an Executable Directly on a Target System via SQL Commands

SQL server allows working with COM[1] objects using OLE stored procedures from within T-SQL. OLE procedures allow instantiation of a COM object and uses that instance’s methods and properties.

Attackers abuse this functionality to create and store executables on disk. In the following example, an attacker exploits OLE automation[2] procedures (sp_OA) and ADODB.Stream object[3] which referred by its class identifier ‘00000566-0000-0010-8000-00AA006D2EA4’.

ADODB.Stream object’s methods (Open, Write, SaveToFile and Close) are executed using the sp_OAMethod procedure to save the binary contents (HEX encoded executable) of an open Stream object to a local file.

The following figure summarizes the complete scenario of the attack:

Figure 2: Technique to save a file on disk using OLE Procedures and ADODB.Stream object

Download Executables to a Target Server via SQL Commands

Based on our SQL server attacks analysis, we detected abuse of the following objects and features when downloading malicious executables.

COM Objects and OLE Stored Procedures

Attackers exploit the fact that SQL server can work with COM objects using OLE stored procedures to download malicious executables to target system.  The next attack is based on manipulation with the following COM objects: FileSystemObject, ADODB.Stream, WshShell and XMLHTTP[4].

The attacker uses File System object to create and fill VB script (‘c:\401.vbs’).This script calls methods of XMLHTTP and ADODB.Stream objects to download and save to disk a malicious executable (‘c:\cz.exe’). Then VB script executed by WshShell object.

The following is an example for commands that create and execute the VB downloader script.

The following figure summarizes the complete scenario of the attack:

Figure 3: How to create and execute an HTTP downloader script

Ad Hoc Distributed Queries and Microsoft OLE DB Provider for Microsoft Jet

AD Hoc distributed queries allow data access from multiple heterogeneous data sources, such as multiple instances of SQL Server. These data sources can be stored on either the same or different computers. When ad-hoc access is enabled, any user logged in to that instance can execute SQL statements referencing any data source on the network using OLE DB provider through OPENROWSET[5] or OPENDATASOURCE[6] functions.

Attackers abuse Ad Hoc distributed queries and Microsoft OLE DB Provider for Microsoft Jet[7] to create and execute an FTP script which is intended to download a malicious executable from the remote server.

The following is an example of such an attack:

The following figure summarizes phases of the attack:

Figure 4: How to create and execute an FTP downloader script using Ad Hoc distributed queries and Microsoft OLE DB Provider for Microsoft Jet

SQL Agent Jobs

SQL Server Agent[8] jobs can be exploited by attackers to create malicious automatic tasks. SQL Agent jobs are frequently used by attackers to establish persistence on the compromised system. We’ll discuss this scenario in future posts.

In the following example attackers use SQL Agent job and SQL Server Job system stored procedures to call for a Windows command prompt (cmd.exe) and create an FTP script for downloading a malicious executable. The FTP script is very similar to the scripts we’ve seen in previous examples.

The following figure summarizes phases of the attack:

Figure 5: Method to download and execute an executable using SQL Agent Jobs


XP_CMDSHELL – Extended Stored Procedure

Another way to upload a malicious executable to a target server is by using the xp_cmdshell extended stored procedure[9]. xp_cmdshell provides a way of executing commands on the host Windows system from within the context of a SQL Server instance.

The following example demonstrates the use of an xp_cmdshell command to execute a Windows command prompt (cmd.exe) and create an FTP script, which downloads a malicious executable from a remote server.


In this post we covered various methods for executing SQL and OS commands through MS SQL database, which can be used to deliver and execute malicious payloads on a targeted system. With the next post in this series, we’ll describe the same topic for MySQL database.

[1] COM is a technology that allows objects to interact across process and computer boundaries as easily as within a single process. COM enables this by specifying that the only way to manipulate the data associated with an object is through an interface on the object.

[2] OLE Automation is an inter-process communication mechanism created by Microsoft.

[3] ADODB.Stream object is used to read, write, and manage a stream of binary data.

[4] XMLHTTP object is a part of Microsoft’s suite of XML DOM (Document Object Model). This object was originally designed to provide client-side access to XML documents on remote servers through the HTTP protocol. It exposes a simple API which allows to send requests and get the resultant XML, HTML or binary data.

[5] OPENROWSET function can be used to import data from and OLEDB data source. This method is an alternative to accessing tables in a linked server and is a one-time, ad hoc method of connecting and accessing remote data by using OLE DB.

[6] OPENDATASOURCE provides ad hoc connection information as part of a four-part object name without using a linked server name.

[7] The OLE DB Provider for Microsoft Jet allows ADO to access Microsoft Jet databases. JET presents the developer with the ability to create and manipulate relational databases on the local filesystem or on shared network folders.

[8] SQL Server Agent is a Microsoft Windows service that executes scheduled administrative tasks (jobs). SQL Server Agent uses SQL Server to store job information. Jobs contain one or more job steps. Each step contains its own task, for example, backing up a database.

[9] Extended stored procedures are DLLs that SQL Server can dynamically load and run.