Running as a Windows Service

There are some things that are just plain difficult on a Windows box. Take, for example, debugging Splunk scripted inputs. It seems simple enough. But Splunk runs as a Windows Service and is usually running with the “NT AUTHORITY\SYSTEM” ID – a privileged account on the local machine, but with no privileges on the network. In the Linux world, you can use su to become the user that Splunk is running as. But Windows? That’s a bit harder. You used to be able to use RUNAS, but that has been closed off as insecure. SCHTASKS was another technique – gone on the latest Windows platforms.

How does one become NT AUTHORITY\SYSTEM? Well, it takes a download and some explaining. First of all, you need Microsoft SysInternals. This is a suite of utilities that Microsoft provides for all sorts of things. I download the whole lot and install them in my PATH somewhere on any development machine. They are just plain useful. For instance, the BgInfo utility produces a great background with all sorts of useful information about the machine you are on. This is a wonderful utility in a virtualized environment, and well recommended.

Another of the utilities is PsExec. This command allows you to run commands on remote systems. This seems reasonable enough, but how is that going to help us? Well, if you run the following command:

psexec -i -s cmd.exe

You get a system prompt. Do a whoami and you will see you are running as NT AUTHORITY\SYSTEM. The -I switch tells the psexec command that this is an interactive session and the -s switch tells it that we want a system account. Yes, it works on any interactive console, including PowerShell.

Now that you have a tool to execute as the NT AUTHORITY\SYSTEM, you can easily debug those pesky permissions issues simply by running your script with the same permissions as Splunk.