Honeypot Recon: MSSQL Server – Database Threat Overview '22/'23

Introduction

In a constantly connected world, protecting sensitive data in what are often complex database structures requires staying up to date with cyber criminals’ malicious attack techniques, and infection methods.

This research is an extension of another project which involves monitoring attacks carried out on database servers worldwide. Understanding how these bots work can keep your digital world safe and secure.

In this article, we'll reveal botnet behavior before and after a successful attack. These bots have one job: to install malicious software that can mine digital coins or create backdoors into systems. Next, we'll look at methods that bots use to install malicious payloads fetched via a database attack. Finally, we'll share some tips on how to protect databases and servers from this activity.

MSSQL

During the last few months, Trustwave SpiderLabs researchers observed many brute-force attacks targeting MSSQL instances within their honeypot sensors.

Figure 1 - Percentage of attacks on all databases

Based upon this finding, researchers enabled a High Interaction Honeypot (HIH) approach to conduct additional research. This approach allowed examination of the techniques used after the cybercriminals leveraged access to the database instance, allowing the researchers to capture the executed commands, and analyze intercepted malware payloads.

Figure 2 - Brute-force attack histogram

The Research

To conduct the attack analysis, an MSSQL database instance was set up to be vulnerable. An easy-to-guess password, the MSSQL administrator username ‘sa’, was used to make sure the database was easily accessible from the Internet to allow for a break-in.

Figure 3 - Brute-forced usernames

The 'sa' user is a well-known account used in MSSQL attacks, so it is always worth paying special attention to the configuration of security parameters around this account.

Figure 4 - OSQL-32 compared to other Client Application Names

The chart above illustrates how active ‘OSQL-32’ was compared to other recorded Client Application Names (CAN). CAN refers to the name of the application that is making the connection to the server. When the SQL Server receives a connection, it logs several details about it, including the application name, if provided. Thanks to this parameter’s value (‘OSQL-32’), we can track attack activity.
Further analysis focuses on the most active bot sets that were built on the 'osql Utility' and use the standard 'OSQL-32' string as the Client Application Name.

Figure 5 - Most active Client Application Names

The table above presents the number of the most active attacks, which were represented by the same 'Client Application Name' parameter, which is the ‘OSQL-32’. Other CANs have been analyzed and properly described for future security events.

Figure 6 - Top 20 most active IP addresses of ‘OSQL-32’ CAN`s

The addresses from which the most attacks were carried out are presented in the chart above. The disparities are significant. It turns out that most of the heaviest brute-force events are associated with several IP addresses. These events are perfectly presented on both charts above (i.e., the chart “‘OSQL-32’ compared to other Client App Names”). All the characteristic "peaks" of the charts tell us about a massive brute-force attack, which at its peak, reached over 3 million login requests per day.

GeoIP information from the above addresses cannot be linked to only one country - the situation is quite different. They can be linked to other countries such as France, US, Russia, and UK. An interesting fact is that the above addresses are not marked as dangerous in popular security services, such as VirusTotal, MISP, and others.

Attack and Payload Analysis

Here, we’ll explore methods and techniques for executing SQL and OS commands through the Microsoft SQL server that can be used for delivering and executing malicious payloads on the targeted system.

Common Language Runtime (CLR) Assembly

SQL CLR assembly is used by bots to extend the functionality of a SQL Server by allowing executable .NET code directly within the database engine. When the bot is authenticated, it executes a SQL script to change the MSSQL config to be able to install a backdoor CLR assembly.

Figure 7 - SQL trace: configuration changes

Before an assembly can be created, the TRUSTWORTHY database property must be enabled for the database where the assembly is used, and the CLR must be enabled for the assembly to run.

When the reconfiguration is done, a CLR assembly and two stored procedures linked to it are created. This new assembly was created based on the hexadecimal payload visible in the first line of the screenshot below (Figure 8).

Figure 8 - SQL Trace: objects creation

Figure 9 - Decompiled Shaw.dll

Next, the attacker uses the CLR assembly methods to deliver and run four files on the server by executing the procedures linked to it.

Figure 10 – SQL trace: executable files downloading and execution

The final phase of the attack is to erase the traces by deleting the ‘sp_CmdExec’ and ‘sp_DownLoader’ procedures created earlier:

Figure 11 – SQL trace: removing the objects

Object Linking and Embedding (OLE) Automation Procedure

OLE Automation Procedure is a set of SQL Server system stored procedures that allow users to run Automation objects from within Transact-SQL (T-SQL) statements. OLE Automation is a technique that enables software components to communicate and share data with other software components using a standardized interface.

Users can create and manipulate Automation objects in T-SQL code, which enables the integration of the SQL Server with other components of the Windows system, called Component Object Model (COM), which is a binary-interface standard for software components

When the bot is authenticated, it executes a SQL script to set a few SQL server configuration options, including enabling OLE Automation procedures, and modifying multiple registry values in Windows as a step to take control over the system.

Figure 12 - SQL trace: configuration changes

The next step, after the SQL server configuration settings are changed, is to modify registry values using ‘xp_regwrite’ and ‘xp_regdeletekey’, SQL Server extended stored procedures, to allow users to write a value to a specified registry key or remove it.

We can see that these stored procedures removed the Command Processor Autorun, whose registry value is used to automatically execute a specific command or script whenever the Command Prompt is opened. If the Autorun value is deleted, any command or script configured to run automatically will no longer execute when the Command Prompt is opened.

Figure 13 - SQL trace: registry changes

Next, the bot removes the Image File Execution Options registry key for a few objects, such as regini, secedit, ftp, cacls, net1, icacls, cmd, sethc, and wscript. These keys allow administrators to specify a range of options and settings for an executable, such as debugging settings or compatibility settings. This can be used by malware to hijack and modify the behavior of legitimate executables.

Figure 14 - SQL trace: deleting registry keys

The last registry changes are for HKEY_CLASSES_ROOT registry keys, which are top-level keys in the Windows Registry that contain information about file associations and OLE object classes. We can see the creation of a new CLSID (Class Identifier) for a few COM objects: Microsoft Jet 4.0 OLE DB Provider, Microsoft Script Control, JavaScript, Microsoft XML HTTP, and their attributes below.

Figure 15 - SQL trace: registry changes

When the SQL server configuration and system registry values are changed, the attacker starts creating OLE objects. The attacker initially uses OLE objects to change attributes and access the server tools. We can assume that the system register changes and tools changes are part of a privilege escalation process.

Figure 16 - SQL trace: F**kGothin.inf file creation using OLE objects

Exploits utilize the IDataInitialize, referred to by its class identifier (CLSID {00000566-0000-0010-8000-00AA006D2EA4}) provided by Microsoft's OLE DB Service Component, to create and manage connections. Then, the bot creates the file F**kGothin.inf and writes hexadecimal binary content. F**kGothin.inf is a text file. These types of files are used to provide information to the system about how to install, configure, and manage software, drivers, or hardware components. Below, Figure 17 shows the security descriptor information from the F**kGothin.inf file about who and what kind of access it has to the executable objects.

Figure 17 – Descriptor of F**kGothin.inf file

Breaking Down the Security Descriptor Strings

•

The D at the beginning of the string specifies that this is a Discretionary Access Control List (DACL), which is used to determine access rights for users and groups.

• The P specifies that the Access Control Entries (ACE) are protected, meaning they cannot be modified by anyone other than the owner, or an administrator.

• The (A;;GRGX;;;BU) ACE specifies that users in the ‘Built-in Users’ group have Generic Read/Execute access to the object/resource.

• The (A;;GRGX;;;PU) ACE specifies that users in the ‘Power Users’ group have Generic Read/Execute access to the object/resource.

• The (A;;GA;;;BA) ACE specifies that members of the ‘Administrators’ group have Generic All access to the object/resource.

• The (A;;GA;;;SY) ACE specifies that the operating system has Gene

ric All access to the object/resource.

We can also see that the bot is trying to do the same, using the ADO.DB.connection object which is referred to by its class identifier (CLSID) {0D43FE01-F093-11CF-8940-00A0C9054228}.

The set of instructions is large and complex, and we can see that the attacker, to increase their chances of success, uses several different objects to make the same changes.

Figure 18 - SQL trace: Creation of executable files using OLE objects

After completing the privilege escalation process, the bot proceeds to create objects using ‘ADODB.Stream’, which is a COM object provided by Microsoft's ActiveX Data Objects (ADO) library. It is used for reading from and writing binary or text data in memory, and for saving it to disk, or a database.

In Figure 16, we can see it is used to create a few executable files based on hexadecimal binary content and save them to disk. As in the first method, we can analyze the malicious files using NET assembly editors, or we can upload them to one of the online scanners.

Figure 19 - Decompiled malicious executable files

We were able to identify a few of these newly created malicious executable files as privilege escalation tools such as Potato (BadPotato, JuicyPotato, SweetPotato, EFSPotato) and PoC (CVE-2018-8639, CVE-2019-1458). We can see that these tools are used by the attacker to launch other malicious executables to escalate their run privileges.

We observed that in most of the attacks the final goal was to deploy a coin-miner and different types of backdoor Trojans.

Figure 20 - SQL trace: Launching of executable files using OLE methods

Summary

In this article, we looked at attackers’ activity and two common methods of delivering malicious payloads. As we see, Microsoft SQL Server is extremely popular compared to other database solutions. Microsoft solutions are used by individuals, companies, large corporations, and governments. There is no wonder that attackers place great hopes in breaking MSSQL security.
 
The above analysis highlights the areas where the emphasis on security should be as high as possible. The OLE Automation and CLR assembly are immensely powerful features, which makes them extremely dangerous. If you are not using OLE Automation and the CLR assembly, they need to be disabled. Disabling unnecessary features inside the database will reduce the attack surface, but as we illustrated, it will not eliminate it.

To protect your server from this type of attack, a good practice is to use a custom administrator login account and disable or remove the ‘sa’ account. Using strong passwords is an absolute requirement. For more information check out this report. 

To provide comprehensive security coverage, remember to perform database vulnerability scanning, regularly. This will help identify security vulnerabilities in the database system caused by incorrect configurations or weak passwords, as we described.

To detect similar attacks, use Trustwave’s DBProtect Database Activity Monitoring (DAM) solution to monitor, and analyze real-time database activities for detecting, and responding to suspicious or unauthorized behavior.

If you are using DbProtect you can configure the policy to trigger a DAM alert for CLR assembly creation, and use of xp_cmdshell stored procedure.

We are in the process of developing new DAM rules that will be able to identify the methods used during the attacks we described.

Data security is a crucial element for an organization's reputation. In a data breach or compromise, an organization may lose the trust of customers, business partners, and the community. Remember, protecting your data is protecting your organization's reputation.

By implementing both Trustwave’s AppDetectivePro and DbProtect solutions, organizations can achieve holistic security coverage that addresses both potential vulnerabilities and ongoing threats. Organizations can achieve holistic security coverage that addresses both potential vulnerabilities and ongoing threats.

Combining these solutions will provide a layered defense approach that addresses potential weaknesses and ongoing security risks.