SQL Server Local Authorization Bypass

Unlike previous versions, SQL Server 2008 and 2012 don’t provide local system administrators with database administrator rights by default. This was a great idea by Microsoft to reinforce the practices of least privilege and separation of duties. However, in spite of the fact that their heart was in the right place, it was implemented in such a way that any local administrator (or attacker) can bypass the restriction. In most environments SQL Server 2008 and 2012 are installed on domain member servers and access is managed via domain groups. As a penetration tester, that means once I obtain Domain Admin privileges I can simply add myself to the database admin groups in active directory to get access. Once in a while I run across an SQL Server instance that is not managed via domain group or is not on the domain at all. That’s when the escalation method covered in this blog can be useful.

Vulnerability Overview

When SQL Server 2008 is installed the “NT AUTHORITYSYSTEM” account and the SQL Server service account are added to the “sysadmin” fixed server role by default. The “sysadmin” fixed server role is essentially the database administrators group. Any account that has been assigned the role will have complete control over the SQL Server and the associated data. Local administrators can obtain “sysadmin” privileges in two easy steps:

  1. Use psexec to obtain a cmd.exe console running as “NTAUTHORITYSYSTEM”.
  2. Use osql and a trusted connection to connect the local database with “sysadmin” privileges.

In SQL Server 2012,  “NT AUTHORITYSYSTEM” no longer has sysadmin privileges by default, but this restriction can be overcome by migrating to the SQL Server service process.

Attack Walkthrough

For those of you who want to test out the attack at home you can follow the steps below.

  1. Install SQL Server 2008 Express. Click. Click. Click. It can be downloaded from Microsoft at
  2. Log into the Windows server as a local administrator that has not been assigned the “sysadmin” fixed server role.
  3. Run the following SQL query against the local server to check if the current user has been assigned the “sysadmin” fixed server role.osql –E –S “localhostsqlexpress” –Q “select is_srvrolemember(‘sysadmin’)”The -E switch authenticates to the SQL Server as the current user and does not require a password. The –S switch specifies the SQL Server instance. The query “select is_srvrolemember(‘sysadmin’)” will return a 1 if you have been assigned the “sysadmin” fixed server role, and a 0 if you haven’t.

    Note: In some cases, the local administrator or local administrators group is added to the sysadmin group manually during the installation process. I don’t believe that’s what Microsoft intended, but it happens a lot none the less. If that’s the case, this escalation process will not be necessary.

  4. Download psexec. It’s part of the sysinternals tool set and can be downloaded from Microsoft at:
  5. Type the following command to obtain a “NT AUTHORITYSYSTEM” console with psexec:psexec –s cmd.exeNote: The -s switch tells psexec to run cmd.exe as “NT AUTHORITYSYSTEM” .  It does this by creating a new service and configuring it to run as “NT AUTHORITYSYSTEM”.
  6. Type the one of the following command to verify that you are running as “NT AUTHORITYSYSTEM”whoami
    echo %username%
  7. Now run the same osql query as before to verify that you have “sysadmin” privileges. This time you should get a 1 back instead of a 0.osql –E –S “localhostsqlexpress” –Q “select is_srvrolemember(‘sysadmin’)”ss_sql_2008_blog_img2
  8. If you prefer a GUI tool you can also run management studio express as shown in the screenshots below.

Wrap Up

To stream line the process a little bit, I recently created a metasploit post module that will  escalate privileges and add a sysadmin to the target SQL server via an existing meterpreter session.  That module can be downloaded from my git hub account for those who are interested: In spite of how easy it is to use this method to gain unauthorized access to databases it appears to be a requirement in SQL Server 2008. At least one Microsoft article stated “Do not delete this account or remove it from the SYSADMIN fixed server role. The NTAUTHORITYSYSTEM account is used by Microsoft Update and by Microsoft SMS to apply service packs and hotfixes…”.  So in some cases this boils down to missing patching vs. excessive privileges from risk perspective. My guess is that most companies are going to want to keep their servers patched.  🙂  Regardless, hopefully this blog was informative and useful. As always, have fun, but hack responsibility.


Discover why security operations teams choose NetSPI.