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, 2014 and (new!) 2016 Instances with Sysadmin Privileges

Edit: I have confirmed that this is still valid for the all versions of SQL Server 2012, 2014 and the newly released SQL Server 2016, and even on Windows Server 2016 Technical Preview 5.


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.

UPDATE FOR SQL EXPRESS USERS: If you need to leverage this trick on a SQL Server Express install, you can use the "Winmgmt" service - Windows Management Instrumentation, aka WMI service. 




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

Davy said:

Super post, works like a charm on SQL 2014 Express x64!

March 30, 2015 2:49 PM

Aravind said:

I could not find the registry file in Windows 2003. Could you please help me out!!!

June 23, 2015 9:18 AM

Argenis said:

@Aravind: What version of SQL Server are you using?

June 23, 2015 9:36 AM

Aravind said:

SQL server 2005 Enterprise for all the instances i could connect in the server.

June 23, 2015 10:20 AM

Argenis said:

June 23, 2015 10:26 AM

Aravind said:

I have done with psexec and the NT AUTHORITY\SYSTEM also doesn't have access. Could you say if any other gaps to connect the server without getting the server down.

June 23, 2015 11:38 AM

Argenis said:

@Aravind = you could try sniffing out the password on TDS packets on the network, or trying to capture it in a memory dump immediately after a login. Not that easy.

June 23, 2015 12:08 PM

Srii said:

Thanks very much!

February 12, 2016 10:23 AM

ermoas said:

great post! very useful information. thanks for sharing

March 7, 2016 2:01 AM

Vincent said:

Thank you so much !!!! TvT

May 11, 2016 11:48 AM

SQLGuyChuck said:

Hey Argenis! I just tried on SQL Express 11.0.6020 and sqlwriter isn't a sysadmin on it, so it doesn't seem to work after some patch level.

-Chuck Lathrope

June 2, 2016 8:44 PM

Argenis said:

Hey Chuck, thanks for the note! I made an update recommending the use of the Winmgmt service for SQL Express users.

June 2, 2016 11:23 PM

Ariel said:

this is a very good post, thank you for it.

I have a NOOB question though -

If I wanted to use the same technique to grant specific privileges, such as ALTER ANY CONNECTION to the system account - how should I do that?

The following does not work (Uhe statement does work as a query inside the studio):

"path-to-sqlwriter" -S <DB name> -E -Q "use master; GRANT ALTER ANY CONNECTION TO 'NT AUTHORITY\SYSTEM'"

September 18, 2016 6:45 AM

Leave a Comment

Privacy Statement