In the previous article, we told that one of the ways to defending against mimikatz-like tools is disabling the debug privilege for system administrators using Debug Program policy. However, recently it turned out that without the debug privilege (it is SeDebugPrivilege in Windows), a local server administrator cannot install or update Microsoft SQL Server. The matter is that when started, the SQL Server installer checks if there are the SeSecurity, SeBackup and SeDebug privileges. It needs to run the SQL Server process and get the information about the successful start of SQL Server. Here is what it looks like.

During SQL Server installation, the installer performs preliminary checks and identifies some problems with Setup account privileges.

If you click the Failed link, you can see the following message:

Now open the SystemConfigurationCheck_Report.htm report.

As you can see, when checking the HasSecurityBackupAndDebugPrivilegesCheck rule, the installer has found that the current process hasn’t got one of the following privileges:

• SeSecurity – managing the audit and security logs
• SeBackup – the permissions to backup files and folders
• SeDebug — the privilege to debug programs

There is some detailed information in the log showing that the installation process doesn’t have SeDebug flag.

(09) 2017-12-12 11:15:13 Slp: Initializing rule????? : Setup account privileges
(09) 2017-12-12 11:15:13 Slp: Rule is will be executed? : True
(09) 2017-12-12 11:15:13 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck
(09) 2017-12-12 11:15:13 Slp: Rule ‘HasSecurityBackupAndDebugPrivilegesCheck’ Result: Running process has SeSecurity privilege, has SeBackup privilege and does not have SeDebug privilege.
(09) 2017-12-12 11:15:13 Slp: Evaluating rule??????? : HasSecurityBackupAndDebugPrivilegesCheck
(09) 2017-12-12 11:15:13 Slp: Rule running on machine: rom-sql10
(09) 2017-12-12 11:15:13 Slp: Rule evaluation done?? : Failed

I have decided to look for a workaround solution of getting SeDebugPrivilege without changing or disabling the Debug programs policy. It turned out that there is quite an easy way to bypass this policy if you have local administrator privileges on your server. The secedit tool that allows managing local security policies of the server will help us.

Check the current privileges:

whoami /priv

As you can see, there is no SeDebugPrivilege in the current token of the user.

Export the current user rights set by the group policies to a text file:

secedit /export /cfg secpolicy.inf /areas USER_RIGHTS

Using any text editor, open secpolicy.inf and add a string to the [Privilege Rights] section that enables Debug Programs privileges to the group of local administrators.

SeDebugPrivilege = *S-1-5-32-544

Save the file. Now apply the new user rights:

secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS

Log off and log on again and using secpol.msc make sure that the Debug Program privileges are assigned to the group of local administrators. The same is shown in the results of whoami /priv command:

SeDebugPrivilege??????????????? Debug programs??????????????????????????? Enabled

Now you can run the installation or update your SQL Server. But bear in mind that SeDebugPrivilege is assigned temporarily and it will be reset at the next GPO update cycle (after the user has logged off).

You should understand that if you enable Debug programs policy it will not completely protect you from getting SeDebugPrivilege by malicious software that has already penetrated to your server with the local administrator rights, and it may compromise all user/administrator accounts working on the server.