Now the program (e.g., cmd.exe) would run as SYSTEM ( NT AUTHORITY\SYSTEM )

The above method can also be used to launch any program under TrustedInstaller.

Using NirCmd.exe from NirSoft

NirCmd is a multipurpose command-line tool which we’ve covered in this site before. report this ad

NirCmd can start a program elevated as well as launch it under the SYSTEM account.

Use this command-line to start the Registry Editor elevated and under the SYSTEM account:

Context menu implementation

Make a .reg file from the following contents and run the file.

Using RunAsSystem from Uwe Sieber

RunAsSystem (from Uwe Sieber) is a console tool that launches a program under the SYSTEM account or context. It also passes the window style and its process priority to the executed process by default. You can override the window size as well as the child process priority using command-line arguments. Uwe Sieber is the one who developed the famous USB Drive Letter Manager program.

It waits for the started process to end and then passes back its return code (aka errorlevel). However, in a batch file, you have to add start /wait .

Usage:

Examples:

Context menu implementation

Make a .reg file from the following contents and run the file.

The above .reg file adds a Run as SYSTEM command in the right-click menu for .exe files. The .reg file assumes that the file RunAsSystem.exe is placed under the d:\tools folder. If not, alter the path accordingly in the .reg file.

Using “NSudo” from M2Team

NSudo (GitHub) is a similar portable utility like Advanced Run, except that it is not digitally signed. It can launch programs under SYSTEM, Current User, Current Process, or the TrustedInstaller account. We’ve earlier seen how to use NSudo to launch programs as TrustedInstaller.

Select the mode (System) from the dropdown, type in the executable path, and click Run.

Optionally, you can also add a predefined set of programs or commands in the Open: drop-down list box by editing the file named NSudo.json located in the same folder as the executable.

To run a program under the SYSTEM context using NSudo command-line, use this syntax:

See below for the full list of command-line arguments supported by this utility.

NSudo: Command-line support

Context menu addition

• Run NSudo with -Install parameter. It copies NSudo to the Windows directory and adds the context menu.
• To remove the context menu, run NSudo with the -Uninstall parameter. It removes NSudo from the Windows directory and the context menu.

Editor’s Pick: Advanced Run for GUI (and CLI), and PsExec for CLI.

One small request: If you liked this post, please share this?

About the author

Ramesh Srinivasan founded Winhelponline.com back in 2005. He is passionate about Microsoft technologies and he has been a Microsoft Most Valuable Professional (MVP) for 10 consecutive years from 2003 to 2012.

Microsoft → Windows → How to Run a Program as SYSTEM (LocalSystem) Account in Windows

2 thoughts on “How to Run a Program as SYSTEM (LocalSystem) Account in Windows”

This is a really useful article and information. Thank you for that!

I use this feature at the login screen by renaming a few files while Windows is offline. While this is a handy feature for technicians like myself, shouldn’t this be a security issue that Microsoft addresses?

Windows service: Listening on socket while running as LocalSystem

I’m writing a small server-like program in C for Windows (using MinGW/GCC, testing on Windows 7) which is eventually supposed to run as a service with the LocalSystem account. I am creating a socket, and using Windows Sockets bind() , listen() and accept() to listen for incoming connections. If I run the application from the command line (i.e. not as a service, but as a normal user), I have no problems connecting to it from external IPs. However, if I run the program as a service with the LocalSystem account, I can only connect to the service from my own PC, either with 127.0.0.1 or my local address, 192.168.1.80 (I’m behind a router in a small local network). Neither external IPs nor other PCs in the same local network, using my local address, can connect now, even though there were no problems without running as a service.

Now, I’ve heard that networking is handled differently or even not accessible (?) when running as LocalSystem or LocalService or that services cannot access both the desktop and the network (note: my service is not interactive) at the same time due to security considerations. Essentially, I need to find out what’s going wrong/how to listen for connections in a service. Is running as NetworkService the same as running as LocalSystem, but with network access? Surely there must be servers that can run as background services, so how do they do it?

UPDATE: It seems that the suggestions to turn off the firewall were on the right track – I can get a connection after adding an exception in the Windows Firewall. I guess I wasn’t thinking about the firewall because when you run an application using sockets normally, you get a prompt asking to add an exception, which doesn’t happen when a service is run for the first time. Is there a better way to handle this than adding the rule to the firewall manually? Does LocalSystem have the privileges to add a rule to the firewall itself or would I have to do this during installation somehow?

Why running a service as Local System is bad on windows?

I am trying to find out the difference between difference service account types. I tumbled upon this question.

The answer was because it has powerful access to local resources, and Network Service should be used if possible.

But still I am not able to understand that if it has powerful access to local resources, how attacker can access the account? What are the ways to compromise the account? I understood it is all about security, but I don’t know how. It could be dark hacker’s world, however anybody could explain, in simple terms, why network service account is better than local account ?

Thanks in advance.

5 Answers 5

Every program you run increases the attack surface of your server.

You have to assume that a determined, malicious actor can exploit bugs or loopholes in your program to make it do anything. You mitigate that by executing your programs with the least privileges required to do their jobs.

Some of these exploits include:

Luring attacks, in which an attacker tricks your program into executing their code under the program’s elevated privileges.

Buffer Overrun Attacks, in which extra data sent to a method is written into adjacent memory, which may be the target of control flow logic.

Man in the Middle attacks, where an attacker falsifies messages to your program.

Often, a given service isn’t obviously vulnerable to any of these. Running under network service (or another account with reduced permissions) is a ‘better safe than sorry’ strategy that acknowledges two important facts of software development: programmers are fallible and attackers are inventive.

The LocalSystem account is the Windows equivilant of the *nix root account. It’s even more privileged than an administrator account. When you run as LocalSystem, you have full access to every resource on the machine.

As others have written, you should write your code to run with the least possible privileges.

The primary difference between LocalService and NetworkService is that services running as NetworkService have the ability to authenticate to other machines in the domain (as the machine account I believe).

Please note that the LocalService and NetworkService accounts both have the «Impersonate» privilege which is a potentially dangerous privilege — it allows the service to impersonate the user who is calling into the service. If that user is an administrator, then even though your code is running in a low privileged service, it can do anything that the administrator does. If an attacker can exploit a buffer overflow in your least privilege service, they can hook out the APIs you use to impersonate your caller and wait until a high privileged caller calls into your service. This technique is known as «Token Kidnapping» and the MSRC has a great blog post describing the issue (and contains links that describe how to mitigate many of the other risks associated with using LocalService and NetworkService accounts).