[align=center][size=xx-large][color=#E09F3F][b]MS SQL PRIVILEGE ESCALATION[/b][/color][/size][/align]


[size=x-large][color=#E09F3F][b]SQL Server Account Types[/b][/color][/size]
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Windows Accounts - used to sign into SQL Server.
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] SQL Server Logins (inside SQL Server) - used to sign into SQL Server.
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Database Users (inside SQL Server) - maps to a sql authentication.

[size=large][color=#E09F3F][b]Roles[/b][/color][/size]
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] sysadmin role
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] public role

[url=https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/server-level-roles]Extensive List[/url]

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

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:
[code]>> Get-SQLInstanceLocal[/code]

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. Therefor we can locate SQL server via SPN scanning.
Tools:
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] setspn.exe
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] adfind.exe
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Get-Spn.psm1
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] PowerUpSQL
[code]>> Get-SQLInstanceDomain[/code]

[size=x-large][color=#E09F3F][b]Escalating Privileges Within SQL Server[/b][/color][/size]

[size=large][color=#E09F3F][b]Unauthenticated User[/b][/color][/size]
PowerUpSQL
[code]>> import-module .\PowerUpSQL.psd1
>> Get-SQLInstanceScanUDP | Invoke-SQLAuditWeakLoginPw
or
>> Get-SQLInstanceDomain | Inovke-SQLAuditWeakLoginPw[/code]

Manually test credentials:
[code]>> import-module .\PowerUpSQL.psd1
>> GET-SQLInstanceScanUDP | Get-SQLConnectionTestThreaded -Username [username] -Password [password][/code]

[size=large][color=#E09F3F][b]Domain User[/b][/color][/size]
Attempt to login with current account:
[code]>> import-module .\PowerUpSQL.psd1
>> Get-SQLInstanceDomain | Get-SQLConnectionTest
or
>> Get-SQLInstanceLocal | Get-SQLConnectionTest[/code]

See reference for more information: [url=https://github.com/NetSPI/PowerUpSQL/wiki]PowerUpSQL WIKI[/url]

[size=large][color=#E09F3F][b]Clear Text[/b][/color][/size]
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/edb02df90942dc4df0e41f3cbb78660b by Anitian for injecting SQL queries on the fly.

[size=x-large][color=#E09F3F][b]From Public role to Sysadmin[/b][/color][/size]

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

[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color] Weak Passwords & Blind SQL Server Login Enumeration
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] 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[/code]
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] 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.

[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Attempt to identify weak passwords for the identified SQL Server logins.

[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color] If the above aproach fails we can also perform a blind domain account/objects enumeration.
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Get the domain where the SQL Server is located
[code]SELECT DEFAULT_DOMAIN() as mydomain[/code]
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color]
[code]SELECT SUSER_SID('identified_domain\Domain Admins') [/code]
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] 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.
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Finally use the suser_name function to get the domain object name associated with the supplied RID.
[code]SELECT SUSER_NAME(RID)[/code]
[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color]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.
[code]>> import-module .\PowerUpSQL.psd1
>> Get-SQLFuzzServerLogin -Instance ComputerName\InstanceName[/code]
Blind domain account enumeration against the accessible instance we identified above:
[code]>> import-module .\PowerUpSQL.psd1
>> Get-SQLFuzzDomainAccount -Instance ComputerName\InstanceName[/code]

[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color] 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:
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Impersonate Privilege
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Stored Procedure and Trigger Creation / Injection Issues
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Automatic Execution of Stored Procedures
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Agent Jobs
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] xp_cmdshell proxy account
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Create Database Link to File or Server
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Import /Install Custom Assemblies
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Ad-Hoc Queries
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Shared Service Accounts
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Database Links
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] UNC Path Injection
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Python code execution

[size=x-large][color=#E09F3F][b]Escalate from public role level privileges to sysadmin level privileges[/b][/color][/size]

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

[size=large][color=#E09F3F][b]Impersonate Privilege[/b][/color][/size]
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.

[size=large][color=#E09F3F][b]Stored Procedure and Trigger Creation / Injection Issues[/b][/color][/size]
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:
[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color]No granular control over the database owner's privileges.
[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color]When applications are deployed, the sa account for a sysadmin account usually owns the database. The DB_OWNER role can then use the
[code]EXECUTE AS OWNER[/code]
 to actually execute in the context of either the sa or sysadmin accounts. An example of such a stored procedure is the following.

[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Both the reconnaissance and the exploitation phase can be automated with Metasploit:
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] auxiliary/admin/mssql/mssql_escalate_dbowner
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] auxilairy/admin/mssql/mssql_escalate_dbowner_sqli
[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] For more info: [url=https://blog.netspi.com/hacking-sql-server-stored-procedures-part-3-sqli-and-user-impersonation/]SQL Server Stored Procedures[/url]

[size=large][color=#E09F3F][b]Automatic Execution of Stored Procedures[/b][/color][/size]
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 unauthorized execution with sa level privileges.

[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color] Escalate from sysadmin -> 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:
[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color] Shared Service Accounts
[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color] Crawling Database Links
More info: [url=https://www.rapid7.com/db/modules/exploit/windows/mssql/mssql_linkcrawler]Rapid7 Link Crawler[/url]
  [url=https://blog.netspi.com/sql-server-link-crawling-powerupsql/]sql-server-link-crawling-powerupsql[/url]
[color=#E09F3F][[/color][color=#c7c5c5]+[/color][color=#E09F3F]][/color] UNC Path Injection

[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] There are several ways to inject commands via SQL. The following tables outlines the most common and related privileges.
[img]https://www.slideshare.net/nullbind/2017-secure360-hacking-sql-server-on-scale-with-powershell[/img]

[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] PowerUpSQL provides a variety of OS command execution ways such as:
[code]>> $Targets | Invoke-SQLOSCLR -Verbose -Command "Whoami"
>> $Targets | Invoke-SQLOSOle -Verbose -Command "Whoami"
>> $Targets | Invoke-SQLOSR -Verbose -Command "Whoami"[/code]

[color=#E09F3F][[/color][color=#c7c5c5]-[/color][color=#E09F3F]][/color] Check if RottenPotato exploit applies: https://github.com/foxglovesec/RottenPotato

[size=x-large][color=#E09F3F][b]Conclusion[/b][/color][/size]

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.