Invisible Threats: Insecure Service Accounts

In the wonderful world of Windows, service accounts are basically the man behind the curtain. Almost invisible to the naked eye, they can be used to run almost any application you can dream up. That includes everything from database services to anti-virus agents. Unfortunately, many companies have a “set it and forget it” attitude when it comes to configuring service accounts. As a result, the accounts are often configured with excessive privileges and then left unmonitored. This has helped create an ideal attack vector for worms, viruses, and, of course, penetration testers.

Below I’ve provided an overview of how service accounts are commonly used and abused, along with a few tricks that can help prevent them from being used to cause havoc in your environment.

What are Windows service accounts?

A service account is a basically normal user account that has been configured with the specific task of running an application. However, these accounts are only used when the application starts and generally aren’t used to log into systems interactively. Additionally, service accounts usually don’t run applications in the foreground like MS Word or Firefox. Generally speaking, there are five types of service accounts.

1. LocalSystem
   In short, LocalSystem is a predefined service account that has more power than Zeus, and basically runs the Windows operating system. Not even the almighty local administrator account can compare. If you don’t believe me, open the Windows Task Manager and navigate to the Processes tab to see what account is running the show. Even today it’s common to see the LocalSystem being used to run application services that require a lot of access to the operating system. It should go without saying, but using the LocalSystem account to run application services it is not considered a secure option and should be avoided whenever possible.
2. LocalServiceLocalService is another native service account that you might see running processes in the Windows Task Manager. It was added when Windows XP and Windows Server 2003 were released in an attempt to provide a secure alternative to running services with the LocalSystem account. The LocalService account has the same privileges as the members of the local Users group, but has very limited access to network resources. It connects to network resources as a null session without credentials. As a result, it is typically used by local application services that do not require access to network resources.
3. NetworkServiceThe NetworkService account was also introduced with Windows XP and Windows Server 2003 with the intent of providing a service account with fewer privileges. For the most part the NetworkService account has the same privileges as the LocalService account. The primary difference is that the NetworkService account can authenticate to network resources using the associated domain computer account. The domain computer account’s privileges to network resources can then be managed via Active Directory. As you may have guessed, the NetworkService account is commonly used to run application services that require access to network resources.
   Both the LocalService account and NetworkService account may provide application services with more privileges than they really need. As a result , they are also more susceptible to privilege escalation attacks they may provide attackers with LocalSystem privileges.
4. Local User AccountsLocal user accounts can also be used to run application services that don’t require access to network resources. In fact, it is considered a much safer practice than using LocalService, because the account doesn’t have to be a part of the local Users group. As a result, administrators are able to assign only the privileges necessary to run the service application and nothing more.
5. Domain User AccountsDomain user accounts created by a Domain Admin (or similar role) can be used to run an application services that requires access to network resources. Similar to local user accounts, domain user accounts can be configured with least privilege in mind, and don’t have to inherit the privileges of the local Users group and domain computer account. When configured correctly, using domain user accounts to run application services is considered to be the best practice.

How can service accounts be a threat?

I’d like to say that there is a silver bullet for this one, but I think we all know that in the real world they don’t exist. With that in mind I think that the information below can be used as a good starting point, but I haven’t addressed a lot of the implementation challenges that exist in most environments today.

1. Excessive PrivilegesAdministrators are just as guilty as vendors when it comes to setting excessive privileges on service accounts. Every time an administrator sets up the privileges for a service account they should be putting some serious thought into who might be getting that access indirectly. Let’s take database service accounts for example. For some reason a lot of administrators feel that MS SQL service accounts need to be a part of the Domain Admins group. What they aren’t realizing, is that by doing that they are also giving Domain Admin rights to anyone who can run a local command through the database server. That list could potentially include server administrators, database administrators, web application developers, and anyone on the Internet who can access the company’s website and use an SQL injection tool. I can’t tell you how many times an SQL injection issue on an Internet facing web application has landed me Domain Admin privileges in one step, because the principle of least privilege wasn’t considered. You may not see excessive privileges as a failing ASV finding, but in my opinion this is still one of the biggest threats found in large environments today.
2. Default and Weak PasswordsIn many environments it’s still possible for internal attackers to enumerate valid domain users using SNMP, LDAP, SMB, and a number of other protocols. As a result, attackers can usually find a vendor defined service account with a default password. If you don’t have a good list of vendor passwords, plenty of them can be found online with Google. Google can also help you find vendor manuals for more obscure software that doesn’t make it onto the larger lists. If no vendor accounts can be identified, accounts with weak passwords also make great targets using tools like Enum+, Hydra, and Bruter. It’s important to note that this type of attack requires very little skill to execute, but can potentially have a dramatic business impact if sensitive information is accessible.
3. No Password Rotation or ExpirationEmployees come and go from organizations all the time. Unfortunately, the same can’t be said for service account passwords. Basically, administrators don’t like to change them, and neither do vendors. This stagnation can create unnecessary risk. I know we like to trust the people in our companies, but we should still try to account for unforeseen circumstances that might motivate one of them to use a known service account password to do some damage. Also, if an attacker is able to recover the password (or hash) they may continue to use it to access network resources without alerting the IT group.
4. No Auditing or AlertingWhere there is no auditing there can be no alerting. Unfortunately actions taken by service accounts are not sufficiently audited in most environments. As a result, when an attacker leverages a service account to accesses confidential information not a single alert will be sent to notify administrators. Just so everyone is aware, if a tree falls in the woods and no one is there to hear it, it still makes a sound.

How can service accounts be secured?

There are quite a few ways that service accounts can create risk in an environment, but since this is a blog and not a book I’ve only listed the more common misconfigurations that lead to real business risk.

1. Use Local and Domain AccountsUse local and domain user accounts to run application services. Doing so provides administrators with a way to remove potentially excessive privileges automatically inherited by LocalService and NetworkService accounts.
2. Apply the Principle of Least PrivilegeOnly assign necessary privileges to service accounts. Start with the most restrictive state possible and build out from there. Notorious offenders of excessive privileges include database accounts, backup accounts, and accounts used for clustering (to name but a few).
3. Disable the Ability to Login InteractivelyAdministrators can use group policy to prevent service accounts from being used to login interactively. This may be enough to prevent an unskilled attacker from using the account to escalate their privileges on compromised systems. However, please note that in some cases disabling interactive login may completely break your application.
4. Buy Products that can be Securely ConfiguredDuring product screening ensure vendor service accounts can be configured with least privilege and adhere to strong password policies. Default passwords should never be used. Also, put pressure on existing vendors to provide updates that will allow their product to be configured securely.
5. Enforce Strong Password Policies Enforce password complexity and a length of at least eight characters at the local computer and domain levels to prevent attackers from easily guessing passwords. Also, if service account password expiration can’t be automated ensure that passwords are manually changed on a periodic basis.
6. Enable AuditingAuditing should be enabled on service accounts to track significant actions such as account management changes, policies changes, and logon events. In the event of an incident, administrator should be able to use the logs to help track down the source of the issue. A common approach is to perform auditing at the OU and local levels. However, in order to determine if accounts are performing unauthorized actions you really need to enable auditing on security groups and sensitive files as well.
7. Configure AlertingAuditing is great for forensic activities, but to identify an attack in progress alerting will also need to be configured. Consider centralizing logs and setting up alerts to notify IT staff when significant events occurs. For example, it might be good to know if some is adding users to your Enterprise Admins group. There are a ton of tools available that perform alerting and log management. Some of the ones I see in environments on a regular basis include GFI EventsManager, OSSEC and Splunk.
8. Remove Unused Service AccountsIf an application or device that uses a service account is removed from the environment, the associated service account should also be removed. Perform periodic audits of service accounts to help identify accounts that need to be removed. To facilitate the process, the relative application owner should be made responsible for communicating to IT when accounts are no longer needed. Keep a sharp eye on service accounts associated with test and demo accounts. They have a bad habit of sticking around, because people simply forget they are there. Also, virtual machines are responsible for some of the biggest service account sprawl to date, so make sure to watch out for these systems and services in your environment.

Final Thought

Service accounts basically run the show so we don’t have to, and in most environments they have access to all of the things that we hold near and dear to our hearts as IT professionals. That means sensitive data like credit card numbers (PCI), medical records (HIPAA) and social security numbers (PII). So when configuring service accounts give them the consideration they deserve.

Reference Links

• https://msdn.microsoft.com/en-us/library/ms684190(VS.85).aspx
• https://msdn.microsoft.com/en-us/library/ms684188(VS.85).aspx
• https://msdn.microsoft.com/en-us/library/ms684272(VS.85).aspx
• https://msdn.microsoft.com/en-us/library/ms143504.aspx
• https://netspi.com/blog/2009/10/05/windows-privilege-escalation-part-1-local-administrator-privileges/
• https://netspi.com/blog/2009/10/05/windows-privilege-escalation-part-2-domain-admin-privileges/

Scott Sutherland