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).

The Local account has effectively full administrative priviledges on the local machine. Hence any code that might escape from say a buffer overrun and get itself executing has significant scope to do damage.

On the other hand, the Network Service account has by default only Guest level access to the local system. Hence even if an attacker managed to find way to send and execute code within the service that code would have limited access.

If your service has a bug, which can allow attacker to execute arbitrary code (like buffer overflow), he can do everything with your computer if service is running under Local System account, which is equivalent to Administrator account. So the lesser priveleged account your service is running, the lesser privilege the attacker can get.

The simplest scenario is when the service allows the user of the service to execute some code on command line. For example MS SQL Server has a stored procedure that allows you to run a command line command (i.e. run a program).