How to Code Powershell as the System Account

Have you ever needed to run and test code as the System Account? I sure have as there are some registry keys I have run into while coding various data collection scripts that can only be collected by one of two accounts. Either the account that enrolled the device or, the System account. If you add into that mix some other keys that can only be read by admins and the user who enrolled the device is not and cannot be an admin, you now have a problem.

You could upload each attempt of the code to Proactive Remediations or another tool that runs as System and wait, but that would be horribly painful. So, how can you run your code manually as System to simulate something like Proactive Remediations quickly?

The Solution:

The answer is actually pretty simple, you need to use the Microsoft Sysinternals tools. I won’t go into the history of these tools but the long story made short is that they are now published by Microsoft directly so you shouldn’t have to worry about them being safe.

Once downloaded, extract the ZIP contents to wherever you see fit. I typically create a C:\PStools folder to store them in.

Then, launch an Admin PowerShell or Command Prompt as any Admin account with at least local admin privileages. Into it enter this command, adjust your path to Psexec.exe accordingly. If you prefer a Command Prompt you can swap out PowerShell.exe with CMD.exe.

C:\pstools\Psexec.exe -I -s PowerShell.exe

-I means interactive, and -s means as System. Thus, we are telling PsExec to run a Powershell window as System that is interactive (has a GUI instead of just an invisible process).

If it’s your first time running Psexec you will need to accept the prompt / license that appears. Once accepted, you should see a PowerShell (or CMD) open up. You can check you are indeed the System account with the WhoAmI command, easily one of my favorites. It should report that you are nt authority\system.

You can now use this PowerShell/CMD to execute scripts OR, you can just pop in the path to something like Visual Studio Code or PowerShell ISE and actually run and test code right as System.

For instance, I might put into my PowerShell…

Start-Process "C:\Program Files\Microsoft VS Code\Code.exe" 

…to launch Visual Studio Code. The nice thing about PowerShell is that it will remember this command next time you re-launch a System PowerShell. Just up arrow and press enter to re-launch VisualStudio Code the next time around.

Note: I have had some issues with apps seemingly not launching the first ever time I run the command on a system. If it doesn’t open and it’s the first time you have ever launched said app as System on a machine, try running the command again after a moment.

Your end result should look like this, once you install the PowerShell extension that is.

Useability Concerns:

There will be some weird things you will run into if you do this though. I have yet to run into anything earth shattering but it’s likely you will find some things unusal at first. The System account is its own profile, but it’s not really meant to be used this way. So, you might launch Visual Studio Code and try and open a file and get some error about how you don’t have a documents folder or something like that. You will also find profile specific things like installed extensions are not present and will have to be re-installed.

Example:

Permission Concerns:

I am no security expert and cannot speak to the security concerns this path may have, as always see the disclaimer. That said, you do have some more power than the average local admin does. Tehcnically, this is no more permission than you might get by running things as System via something like Proactive Remedations but, you should still be careful. You mainly have the power to really brick things, and now it’s much easier to slip up and do so.

That said, the almighty permissions of the system account are limited to the system on which you are running, at least for client devices.

Disclaimer:

The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.

You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time. 

It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.

The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/