THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Argenis Fernandez

Leveraging Service SIDs to Logon to SQL Server 2012 and SQL Server 2014 Instances with Sysadmin Privileges

Edit: I have confirmed that this is still valid for the all versions of SQL Server 2012, and SQL Server 2014 - and even on Windows Server 2012 R2.


If you recall one of my previous blog posts, titled Think Your Windows Administrators Don’t Have Access to SQL Server 2008 by Default? Think Again I exploited the fact that NT AUTHORITY\SYSTEM was granted membership to the sysadmin server role by setup in SQL Server 2008 R2 and below to gain access to a SQL instance to which I had no access, since as Administrator on the box I could launch a cmd session as NT AUTHORITY\SYSTEM with Sysinternals’ psexec utility.

My friend and SQL Server MVP Jorge Segarra [blog|twitter] correctly pointed out shortly after that NT AUTHORITY\SYSTEM is not a member of the sysadmin server role in SQL Server 2012, codename Denali. And as of Release Candidate 0 for this version, this holds true.

What also holds true as of RC0 is that the Service SID for a number of services (at least three, the SQL Engine itself, SQL VSS Writer and Winmgmt) are members of the sysadmin role. And so in this post I’d like to demonstrate that it is possible to exploit one of these services' level of access to hop onto a 2012 (or 2014) instance as sysadmin.

The target: a named SQL instance called “DENALI_RC0” on one of my desktop PCs. Having dropped my login on SQL, when I try to logon to the instance I get the usual message:


I picked a service to become “the victim”. The SQL VSS Writer service seemed to be a good candidate: innocuous enough. If I stop it and restart it, no big deal.

I launched regedit and browsed to HKLM\SYSTEM\CurrentControlSet\services\SQLWriter - this is what I saw:


Now being an Administrator of this PC as I am, I went ahead and renamed sqlwriter.exe to sqlwriter.exe.orig, and put a copy of SQLCMD.EXE on C:\Program Files\Microsoft SQL Server\90\Shared.

Then I renamed SQLCMD.EXE to sqlwriter.exe.

Obviously kicking off the SQL VSS Writer service was not going to do anything – just error out:


So I replaced the ImagePath for sqlwriter on the registry with this:

"C:\Program Files\Microsoft SQL Server\90\Shared\sqlwriter.exe" -S CSHQAFERNANDEZD\DENALI_RC0 -E -Q "CREATE LOGIN [CORP\Argenis.Fernandez] FROM WINDOWS; EXECUTE sp_addsrvrolemember @loginame = 'CORP\Argenis.Fernandez', @rolename = 'sysadmin'"

And now I kick off the sqlwriter service again, expecting it to error out…but with a nice side effect.


Sure enough, launched SSMS 2012 and was able to login. And guess what, my login has sysadmin privileges.


And so I’m sure some of you have already yelled “SECURITY HOLE!!!!” by now – yeah, to a degree…but remember kids, if you’re a local Administrator on the box, you already own the box. Very little applications like SQL Server can do to protect themselves from a “rogue” Admin. Maybe a few adjustments to the security model for Windows’ SCM (Service Control Manager) are needed here, but I’ll let you decide on that.




Published Thursday, January 12, 2012 4:34 PM by Argenis
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Robert L Davis said:

Stay away from my servers! ;)

January 12, 2012 6:53 PM

Paul Timmerman said:

What Robert said! Excellent post!

January 12, 2012 7:19 PM

Amit Banerjee said:

Well written especially the advice to the kids! :) And +1 to what Robert said!!

January 12, 2012 10:32 PM

Greg Linwood said:

nice article, good point about sysadmins..

January 12, 2012 11:46 PM

Meher said:

Excellent post Argenis.



January 12, 2012 11:57 PM

Dale Hirt said:

It's interesting that LocalSystem still has privileges as well.  Another excellent post.

January 13, 2012 2:16 AM

spe109 said:

A very good and interesting article. Thanks Paul.

January 13, 2012 3:46 AM

Kenneth M. Nielsen said:

Great post, and as you conclude, there's nothing to do about a rogue admin, well except give him/her a letter of termination ;)

June 28, 2013 4:38 AM

Joseph said:


June 28, 2013 9:28 AM

Justin Dearing said:

Naturally a local admin could just run SQL Server in single user mode to give himself access. However, being able to do with WITHOUT restarting SQL server makes it harder for an attacker to get caught.

June 28, 2013 8:50 PM

Argenis said:

@Justin: indeed - but a smart attacker with sysadmin privileges can definitely get away without being caught. I don't necessarily see this as an attack vector. It just makes it harder for Windows admins to mess with SQL Server - and in a good number of shops out there, that's a good thing.

June 28, 2013 8:56 PM

Nicolas said:


September 4, 2013 3:09 PM

Waleed Khan said:

Brilliant keep it up .

September 16, 2013 3:43 PM

AB said:

This is working for me on sql server 2012.

March 10, 2015 12:44 PM

Satinder Thakur said:

This is NOT working for me on sql server 2012.

March 10, 2015 12:44 PM

Roja said:

side effect is not working.

March 10, 2015 12:45 PM

Leave a Comment

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement