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).
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:
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:
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.
Summary
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.
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.