Last week in one of our team huddles we were discussing regarding hardening of some production SQL Servers. One of the tasks involved in hardening an instance is to remove BUILTINAdministrators group from the sysadmin group in SQL Server. The members of this group are all who are part of Windows Administrators group on the local computer. This group also has some of the built-in users on the local computer as its members. Some of them are NT AUTHORITYSYSTEM, NT AUTHORITYNetworkService.
What is NT AUTHORITYSYSTEM user? It is a very powerful account which has unlimited access to the local windows server. All the services which are running under Local System account, are in fact running under this user’s credentials. If SQL Server service is running under Local System account then NT AUTHORITYSYSTEM will be a part of the sysadmin group in the SQL Service account.
Can I login as NT AuthoritySYSTEM? Few years ago, I had this question in my mind and several options for getting this done. To logon using this account, one needs to know the password. Since this account is managed by Windows itself, there is no way of getting the password. What if I change the password somehow? This account is not listed under Local Users and Groups in Computer Management console. If Windows has chosen to hide this account from other users, it has to be for good. It is not recommended to change the password of this account, since many core Windows services are dependent on this.
So, is there a way if some user can access the SQL Service or any other application Running as NT AUTHORITYSYSTEM? Yes, there is an exploit using which one can launch almost any application in Windows using the AT command. AT command is used for creating Scheduled Tasks in Windows using the command line interface. Let me demonstrate this with an example.
I logon to my computer using my credentials and open up command prompt. Then type AT in the command prompt which will display all the existing Scheduled Tasks on the computer.
Now I will create a scheduled task which will open SSMS.exe located in C:Program FilesMicrosoft SQL Server100ToolsBinnVSShellCommon7IDE folder. The most important fact is that I am including /interactive switch which will allow the task to interact with the user’s desktop. Else the scheduled task will open SSMS.exe but it will not be visible to the user.
This task will open SSMS.exe at 23:10, which is after a minute from now. At 23:10 what happened? As expected, SQL Server Management Studio opened up automatically, and in the Scheduled Tasks this task was displayed as Running.
The SSMS connection dialogue confirms that it is indeed running as NT AUTHORITYSYSTEM.
Since on my instance, NT AUTHORITYSYSTEM login has requisite permissions, I am able to connect to the instance. Once I close SSMS, the scheduled task is automatically deleted.
If this user has sysadmin privileges on the instance, how someone can exploit it using the above example is left to your imagination.
So what are you waiting for? If there is no application dependency on this account, go and harden your Production instance.