What is the main risk of allowing services to logon as NT AUTHORITY\SYSTEM?

Question

Many enterprises run service on production servers as SYSTEM without considering the risk that might arise from this configuration, what is the biggest risk associated with it? and how would attackers exploit this kind of configuration?

Answer 1

Worst case scenario

When an attacker exploits an application to run arbitrary code then this code will run under the context (and thus the privileges) of the exploited application. So if the service running as SYSTEM has a listening port and is exploitable from the internet or network then the attacker can do pretty much anything on the computer, including adding new administrator accounts or dumping passwords and certificates using mimikatz

Privilege escalation

If the application isn't listening on a port, or isn't exploitable using that port, then the service might still allow the attacker to elevate privileges. this requires the attacker to have some lower privileged access first, like through exploiting a lower privileged application or user.

To attack the service this way the attacker usually needs to look for misconfigurations in the service itself, rather than the application. He can try to edit the binary (exe file) of the application and then restart the service, try and edit the path of the service (thus editing what exe is executed when the service boots up). Or he can try DLL hijacking just to name a few.

If one of these attacks succeed, he can run code in context of the application and thus as SYSTEM. To minimize this risk, run applications on the least amount of required privileges possible, if the service doesn't need to run a SYSTEM then doing so poses an unnecessary security risk.

Answer 2

Even though the feature was available since Windows 2000 or even before*, XP was the first to have some Windows services run as "NETWORK SERVICE" and "LOCAL SERVICE" by default. It's rare to hear about this kind of local privilege isolation being used to mitigate an exploit though.

Whether it's true or not, local unprivileged process security on Windows never had a very good reputation, and there has been little promotion from the industry for its use as a security mechanism. Companies that make anti-virus software don't want to promote the use of this kind of security since it is actually more effective than their products, and it's free with no negative performance impact on the system. Here's an example of an attack that gains access to the "NETWORK SERVICE" account and then uses an exploit to elevate to SYSTEM privileges: https://carnal0wnage.attackresearch.com/2010/05/playing-with-ms09-012-windows-local.html

To answer your question, the main risk is that you no longer have a second layer of protection in case your service has a security flaw that is exploited by an attacker. An attacker is often unable to permanently install malware on your server if they are restricted to a limited account.

(*) In NT4 the default filesystem permissions were so insecure that unprivileged users could install software system wide, just like Power Users group allows in NT5. This made local unprivileged user security mostly useless in the default configuration.