How to Exploit SQL Server Using Registry Keys

At the Imperva Research Labs we have the chance to scrutinize various security situations. In this blog, we will take a closer look at database security on SQL Server.

One routine approach that security practitioners employ to protect databases is deploying honeypots and waiting for bad actors to take the bait. This approach is very effective because it allows us to analyze different attack scenarios and gain actionable insights about the methods and techniques that hackers use to attack databases.

Here we’ll provide a glimpse into today’s “Database Attack Landscape”. This is a follow-up on previous Imperva Research Labs research done in 2018 on SQL Server. To see those findings, check out “A Deep Dive into Database Attacks [Part II]”. You’ll notice that the attack landscape has not changed much in the past 3 years.

You’ll learn more about the methods and techniques cyber criminals are using today to deploy malware, gain persistence, take over the system to join the server into massive botnets, and escalate privileges in order to get access to an organization’s network.

While other posts concentrate on the malware itself we’ll focus on the database side of the attack, the dangerous functions, and the power that is stored inside the SQL Server.

In the first post of the series “How to Exploit SQL Server Using OLE Automation”, we describe how SQL Server can interact with other components of the Windows OS called COM objects. In this post, we describe how to manipulate Registry keys to achieve persistence, avoid detection, and weaponize SQL Server.

Cyber criminals deploy attack methods that they believe give them the best chance to succeed. Core features that are defined in multiple versions are the ultimate target. This is one reason why we see bad actors using the same approaches with few changes over the years: exploits recycling is fairly common. The database attack landscape hasn’t changed a lot over the years and exploitation techniques are being reused over the years.

SQL Server Registry manipulation is one example for such a target as it is a built-in feature for many SQL Server versions. We will inspect some of the techniques in depth and discuss ways to prevent similar attacks on your SQL Server in the future.

Registry Manipulation

The Windows Registry stores much of the information and settings for software programs, hardware devices, user preferences, and operating-system configurations.

One of the powerful abilities of SQL Server is to delete, edit and write to the Windows Registry. SQL Server provides multiple undocumented extended procedures to manipulate the Windows Registry. Extended procedure simply means the ability to execute code from external sources. The Registry extended procedure uses ‘xpstar.dll’ to manipulate the Windows Registry.

Registry Procedures

“xp_regdeletekey” – Deletes a registry key.
“xp_regdeletevalue” – Deletes the value of a registry key.
“xp_regenumvalues” – Enumeration of all values in specified registry
“xp_regenumkeys” – Enumeration of all keys in specified registry
“xp_regread” – Read a registry key.
“xp_regwrite” – Write a registry key.
“xp_regremovemultistring” – Remove a string from a multi-string registry entry.
“xp_regaddmultistring” – Create a multi-string registry entry or add a string to an existing multi-string key.

Practical Usage

When an attacker puts his hands on such power, the sky’s the limit.

Here are some usages observed in the wild for Registry modifications.

Example #1: Register the COM object to the CLSID

Before anyone can use a COM object it is necessary to register with the system registry to make them accessible to applications. The registration is done by adding registry entries that represent the instance of the COM object under the CLSID entries. A CLSID is a globally unique identifier that identifies a COM class object. For more information about COM objects check out the blog “How to Exploit SQL Server Using OLE Automation”.

The example below registers the “The File System Object component” with its CLSID “0D43FE01-F093-11CF-8940-00A0C9054228”:

Figure 1: Register the File System Object component.

Example #2: Gain Persistence

CMD AutoRun

When CMD.exe (Command Processor) starts and if the /D flag is not specified, the AutoRun commands will be executed.

In the below example the attacker adds the AutoRun registry key for the CMD.exe with the malware executable path (C:\ProgramData\SQLAGENTVHC.exe) as a method to gain persistence.

Figure 2: Setting the “AutoRun” registry key of the “Command Processor” to gain persistence.

Run and RunOnce

Run and RunOnce registry keys cause programs to run each time that a user logs on.

By adding the Aut3 entry with the executable path (C:\ProgramData\SQLAGENTVHC.exe) to this registry path the attacker makes sure that the malware will be executed every time that a user is logging into the server.

Figure 3: Setting the “Run” registry key to gain persistence.

Example #3: Disable Anti Virus and Competitors

The attacker makes sure to kill anti-virus processes to stay undetected when deploying the crypto miner. Some executables are suspected as viruses, the attacker stops them in order to make sure that his crypto miner will not compete with other malwares on CPU resources.

The method used to disable running processes is using the IFEO (Image File Execution Options), by adding the debugger key with value of taskkill, the specific process will be killed in this case 360rp.exe:

Figure 4: Attacker disables a running process “360rp.exe” by setting the “Debugger” key to taskkill.

Prevention

Disable Configuration

It is recommended to disable the option to use those SQL Server abilities:

Figure 5: Disable the OLE Automation features of SQL Server.

Revoke Execution Permission

It is recommended to deny EXECUTE permission on the extended stored procedure from public and other unauthorized users:

Figure 6: Revoke EXECUTE permission on dangerous features of SQL Server.

Better Safe Than Sorry

Since registry manipulation is a built-in feature, there is no actual way to prevent the activation of the feature. It is recommended to add monitoring for the events of re-enabling the configuration and recreating the extended procedures and granting execution on the procedures.

Summary

Once an attacker gains access to the database they won’t necessarily stop there.

Many known cases are published where after exfiltrating data from one database the attackers decided to become “residents” inside the organization network, make a lateral movement and exfiltrate data from more than just one database. More about attacker types and data breaches in the blog post “Know your enemy! The four types of cyber attackers trying to breach your security today”.

We saw how the attacker was able to change the registry, disable anti-virus to stay undetected, gain persistence and weaponize the SQL Server to use another dangerous feature “OLE Automation” by registering a COM object to the CLSID to finally deploy malware on the victim server. The attacker made everything from inside the SQL Server service without actually having access to the OS, but still had a deep impact on the underlying OS configuration.

It is important to reduce all the security risks to a minimum and make sure that we are not making life easy for the attackers outside.

Imperva offers different products to help our customers to protect against database attacks, for on-premises and cloud services. For more information visit the following link.