Securing Service Accounts

Service accounts are accounts used to run a particular service. They will commonly be created as part of an application’s installation procedure and have a few characteristics that can lead to significant security risks:

  • Passwords are hard to change
  • Single account will have access to numerous systems
  • Accounts are often privileged

A service account logs on to a system when a service is started and does not log off until the service is stopped. For password changes to take effect, the service account must be restarted, which will interrupt whatever application is using that particular service. Since service accounts are commonly used on numerous machines, this can be a complicated and disruptive process that, in practice, rarely happens.

Service accounts are commonly defined on a per-application basis. This means that a single account is used to run that service on all systems. This means that the account must have access to all of these systems. Also, service accounts are commonly used in server-client architectures where an application must communicate with many other machines (think antivirus applications, system management software, etc.)

Finally, the types of applications that require service accounts are often applications performing administrative tasks – scanning files for viruses, installing patches, changing system settings. It is not uncommon to find service accounts running with Domain Administrator privileges.



These three characteristics can form a near perfect storm from an attacker’s standpoint. You have passwords that rarely change on accounts with administrator-level privileges running services installed on numerous machines. If an attacker gets SYSTEM-level access to a single machine with one of these accounts configured on it, they can steal the credentials of that account and use it to move laterally through the network. If the account is running with Domain Admin privileges, they will control the domain.

An Example

For a more real-world example, consider the following. A McAfee ePO server has been configured in the DMZ to pull antivirus updates from the internet. The service account for the McAfee Agent requires Local Administrator access to all target machines for software installations. In addition, to minimize the number of servers that need maintaining, clients on both the DMZ and internal networks are managed by the DMZ ePO server.

An attacker compromises the DMZ with stolen credentials. The user is also an administrator in the DMZ domain and the attacker is able to steal the hashes from a server on the DMZ, including the McAfee service account. The McAfee service account is a local administrator on all devices in the DMZ as well as the internal networks. Administrators have not implemented any restrictions on service accounts and the attacker now has administrative access to every single server running antivirus in the DMZ and on the other internal networks, including the Domain Controller and, by extension, the entire domain. With this access there is nothing the attacker can’t do.

Mitigating the Risk

Mitigating the risk posed by service accounts can be accomplished with relatively little fuss by following good practices during the configuration of the application and the domain.

The secure configuration of service accounts is achieved in three parts:

  • Strong Service Account passwords
  • Restrictive Service Account Group Policies
  • Minimizing Service Account privileges

Service account passwords should have strong (at least 20 character) passwords. A “Service Accounts” group should be created to contain all domain service accounts. Next, a Group Policy should be made with the following settings:

  • Allow Log On As A Service: “Service Accounts” group
  • Deny Log on Locally: “Service Accounts” group
  • Deny Log on through Remote Desktop Services: “Service Accounts”

After a careful assessment of application requirements, the following setting may further reduce misconfiguration:

  • Deny Log on as a service: “Domain Admins” group

This configuration is by far the easiest to do during commissioning. If the above settings are being introduced to an existing domain, a full inventory of service accounts must be performed on the machines targeted by this policy. Any local service accounts must be replaced with domain-level service accounts or excluded from the policy as the GPO will overwrite local settings.

Resources

Add a Comment

Your email address will not be published. Required fields are marked *