Securing Windows Service Accounts (Part 1)

by [Published on 6 Feb. 2013 / Last Updated on 20 June 2013]

In this first part of our article series we will define what service accounts are and why it is so important to protect them.

If you would like to read the next part in this article series please go to Securing Windows Service Accounts (Part 2).

Introduction

Everyone related to Windows security is fully aware of service accounts. As administrators, service accounts are a pain to set up and ensure they are running for each installed applications that requires one. As auditors, we know that service accounts are not secured correctly, especially with the resetting of the passwords. Both angles are correct with regard to the complexity and security issues related to service accounts. However, that does not discount the fact that these accounts need to be audited and secured correctly. By taking the correct steps to secure these accounts, both sides of the security concerns can be met and the overall attack surface for the service accounts can be reduced dramatically.

Why Service Accounts Need to Be Secured

Most service accounts, when created and configured, are granted elevated privileges. These elevated privileges are granted to these accounts by placing the account in an “administrative” group. This could be a local group, such as Administrators, or a domain group, such as Domain Admins. Due to this high level of privilege, we need to ensure that these accounts are protected in case of an attack against them.

What is a Windows Service Account

When I discuss service accounts it is often confusing to some that are not fully aware of what I am referring to. The accounts that I am referring to are those that run a Windows service. Yes, there are applications that run on Windows computers that also need a service account. These are not the accounts that I am referring to in this article. For example, if you have an application that runs on a Windows server, but you don’t see a service running on that server for that application, this is not a service that I am referring to. If however, you do see a service running for the application/service when you run services.msc on that server, then it is a service I am referring to. Figure 1 illustrates what the list of services for a Windows server would look like.

Image
Figure 1: Services view on a Windows computer using services.msc.

How to Find Each Service Account

Now that we have discussed which services we are referring to, we now need to understand how to find the service accounts. You will see that there will be many different service accounts, but we are only concerned with a few of them which will be associated with Windows user accounts. In order to discover which accounts are controlling each service, you can simply look at the services.msc output, focusing on the Log On As column, which is shown in Figure 2.

Image
Figure 2:
Service accounts for each service using services.msc.

You will notice there are four different entries in the Log On As column: Network Service, Local System, Local Service, BEYONDTRUST\Derek. It is only the last one in the list that we want to be concerned with of those listed. The other three are builtin user accounts and have the following definitions:

Network Service - The NetworkService account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem. It has minimum privileges on the local computer and acts as the computer on the network. The NetworkService account has the following privileges:

  • SE_CHANGE_NOTIFY_NAME
  • SE_CREATE_GLOBAL_NAME
  • SE_IMPERSONATE_NAME
  • Any privileges assigned to users and authenticated users

Local Service - The LocalService account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem. It has minimum privileges on the local computer and presents anonymous credentials on the network. The LocalService account has the following privileges:

  • SE_CHANGE_NOTIFY_NAME
  • SE_CREATE_GLOBAL_NAME
  • SE_IMPERSONATE_NAME
  • Any privileges assigned to users and authenticated users

Local System - The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem. It has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used. The LocalSystem account has the following privileges:

  • SE_AUDIT_NAME
  • SE_CHANGE_NOTIFY_NAME
  • SE_CREATE_GLOBAL_NAME
  • SE_CREATE_PAGEFILE_NAME
  • SE_CREATE_PERMANENT_NAME
  • SE_DEBUG_NAME
  • SE_IMPERSONATE_NAME
  • SE_INC_BASE_PRIORITY_NAME
  • SE_LOCK_MEMORY_NAME
  • SE_PROF_SINGLE_PROCESS_NAME
  • SE_TCB_NAME

Note:
Most services do not need such a high privilege level. If the service does not need these privileges, and it is not an interactive service, consider using the LocalService or NetworkService.

The service accounts that you should be focusing on are those that have the syntax of <computer/domain name>\<user account name>. It is these accounts that can be controlled for the settings that we are discussing in this article. In order to understand the syntax of the naming, follow the guide below:

<computer name>\<user account name> - If the name is of this format, it indicates that it is a local user account on the computer which is being referenced. An example might be Server1\SRV1.

<domain name>\<user account name> - If the name is of this format, it indicates that it is an Active Directory user account. These accounts are stored on domain controllers and have access to all computers in the domain by default. An example might be BEYONDTRUST\SRV1.

Ensure Service Accounts are not Administrator

The first check we will make on our service accounts is to ensure that they are not the builtin Administrator account. This will be somewhat easy, but there might need to be a secondary check to ensure it is not the builtin Administrator.

Of course, the first check is simple. If the name of the account listed is Administrator, this is not a good configuration. We don’t want the local or domain Administrator used as this account is designed for administration and disaster recovery, not to be used as a service account.

If the account name listed is not Administrator, we need to ensure that the Administrator account was not renamed and the renamed account is listed as the service account. To verify this we will need to check the SID (security identifier) of the account. There are many tools that can used to verify this, DumpSec is the easiest one to use for both domain and local user accounts. (DumpSec is a free tool and can be downloaded at www.somarsoft.com). Figure 3 illustrates what the DumpSec results would look like for the domain list of users.

Image
Figure 3:
DumpSec showing the domain users and SIDs.

What we are looking for here is the SID which ends in -500. As you can see from Figure 3, the Administrator account ends in -500, so we can have confidence that this is the builtin Administrator account. If the Administrator name was not listed or the Administrator name did not have a SID ending in -500, we would then need to verify the new name that Administrator account had been renamed to, then verify this account was not configured as a service account on any services.

Summary

At this stage, we have defined what service accounts are and why it is so important to protect them. We have listed our services and the related service accounts associated with them. There can be four different service accounts that we can find on any one service: local system, local service, network service, <computer/domain name>\<user account name>. It is this last one that we want to focus on for securing service accounts. Our first check for service accounts is to ensure that the account is not the builtin Administrator (or renamed Administrator) account. In our next installment, we will be going over the other key settings to secure all service accounts.

If you would like to read the next part in this article series please go to Securing Windows Service Accounts (Part 2).

Featured Links