Skip to content
Home » Picking up the pieces after the DBA has left: taking ownership of a SQL Server instance

Picking up the pieces after the DBA has left: taking ownership of a SQL Server instance

  • by
macro shot of stainless steel padlock

WARNING: This post contains information that can get you fired if you use it without express written permission. In some jurisdictions it might get you jail time as well.

Let’s assume you are a consultant, and a customer has called you in a panic because they have lost access to their production environment. Let’s assume the previous DBA was unhappy and quit in a hurry, taking the SA and service account passwords with them. It’s one thing being able to change the service account password back again, and quite another to get back into the instance with full system administrator privileges.

If the SQL Server instance is still up and running and the server is on a Windows network running Active Directory, you’re in luck. You can use domain or local administrator privileges to get back into SQL Server with a freely-available tool from Sysinternals called psexec— in some cases without any downtime. If you’re prepared to take some downtime, you can restart SQL Server in single-user mode and perform some command-line magic to reset the password.

But what if SQL Server is on a standalone Windows machine with no domain privileges? What if you’re unable to connect to the instance at all because you don’t even have local administrator rights? Well, this is where I introduce you to the Sticky Keys privilege escalation technique. It requires physical access to the machine, so you will need to make sure you get written permission before you shut down the server in order to perform this. If you are working with a virtual machine, you will need administrative access to the hypervisor instead. (Aside: you should enable monitoring and alerting on any physical access to your servers.)

Windows comes with an accessibility feature called Sticky Keys. By default (because it can be disabled), if you press the Shift key on your keyboard five times you enable this feature. Combining this knowledge with recovery mode in Windows, you can replace the Sticky Keys executable with, for example, command prompt (cmd.exe). Windows Defender has built-in protection against this known attack vector (because you are effectively bypassing Windows protection), so there is a way to disable Windows Defender as well.

When Windows boots up regularly, you can enable Sticky Keys from the login screen by pressing Shift five times. Instead of the Ease of Access dialog, you will be presented with an elevated command prompt. You can use a variation of the command net user Administrator <newpassword> to change the Administrator password, close the command prompt, and then log in as that local administrator. Once you’re logged in, you can use psexec or SQL Server’s single-user mode to get back into SQL Server and give yourself sysadmin privileges again.

Note that several protections — aside from the ones already mentioned in this post — may prevent you from starting the server in recovery mode (including secure boot or a BIOS password), so this technique is just one option in your toolbox. Additionally, as a conscientious data professional, you should make sure these protections are enabled on all your servers (including development and test). Don’t be shy about padlocking your server cabinet as well as the server room door. At one company I worked at, we also bolted the server cabinet to the concrete floor.

Share your off-beat disaster recovery techniques in the comments below.

Photo by Jose Fontano on Unsplash.