The login's roles decide which primitives are reachable, so privilege enumeration follows fingerprinting. The headline check is server-role membership:
' UNION SELECT IS_SRVROLEMEMBER('sysadmin'),IS_SRVROLEMEMBER('serveradmin'),NULL--
sysadmin is the full administrator: it can enable xp_cmdshell, read and write files, dump login hashes, and pivot through linked servers. Note that serveradmin is a lesser role that manages server settings and is not equivalent to sysadmin; the DBA role to aim for is sysadmin. Effective permissions are listed with fn_my_permissions:
' UNION SELECT permission_name,NULL,NULL FROM fn_my_permissions(NULL,'SERVER')--
When the login is not sysadmin, several escalation paths exist. Impersonation grants (EXECUTE AS LOGIN = 'sa') elevate the session when the login holds IMPERSONATE on a privileged login. A database marked TRUSTWORTHY and owned by a high-privilege login lets a module created in it run with that owner's rights, a route to sysadmin from db_owner. Membership that can create logins or assign roles (ALTER ANY LOGIN, CONTROL SERVER) is similarly abusable.
Once sysadmin is held or reached, promote a controlled login to be an administrator with:
'; ALTER SERVER ROLE sysadmin ADD MEMBER [attacker]--
Knowing the role and its escalation options decides whether to go straight for command execution or to chain an impersonation or trustworthy-database step first.
Tools#
- sqlmap: reads the login's roles and privileges with
--privileges. - PowerUpSQL:
Invoke-SQLAuditto enumerate roles and escalation paths.
References#
- Microsoft SQL Server Documentation: IS_SRVROLEMEMBER, fn_my_permissions, EXECUTE AS, TRUSTWORTHY
- OWASP Testing Guide: Testing for SQL Injection