Protecting Service Accounts in Active Directory from Cyberattacks

Service accounts are a common target for cyberattacks, as they often have elevated privileges and access to sensitive information. Many organizations also fail to monitor these accounts, letting the attacker exploit and use these accounts without being seen. Organizations often use service accounts to run background services, enterprise applications, execute automated tasks, or provide access to resources. With all this privilege and access, companies must protect these accounts from unauthorized access.

How Service Accounts Obtain Privileges

Organizations grant privileges to service accounts in many ways. Like other user accounts in Active Directory, the following are the main ways that a service account is granted a privilege:

• Added to a privileged group – Active Directory has numerous built-in groups that have privileges by default. When an organization installs Active Directory, it includes the groups named Domain Admins, Enterprise Admins, Administrators, etc. Additional groups that are granted privileges when a service or application is installed include Exchange Admins, SharePoint Admins, etc.
• Grant user rights – User rights are a per-computer configuration that can be granted to users and groups. There are over 35 user rights which span the spectrum of being able to change the system time, to logging in locally. Many user rights have significant privileges.
• Active Directory delegation – Within Active Directory a user can be given permissions (referred to as delegations). Delegated privileges can be very granular, as you can see in Figure 1, like giving a user the ability to modify the phone number for a single user. They can also be quite inclusive, such as granting rights to create, modify, or delete any user within Active Directory. Common delegations given to users include resetting passwords, modifying group membership, and managing objects to the domain.
• Data permissions – Just as users can be granted permissions within Active Directory, they can also be given permissions over data. Data can be a simple text file, or a complex HR database.

Securing Service Accounts – Reducing Privileges

One way to minimize what could happen in a cyberattack is to reduce the privileges granted to service accounts as much as possible in case accounts are compromised. This is not an easy task, as there is not a chart or list of what service accounts need to perform their duties. Often, software developers just say, “the service account needs to be a Domain Admin,” so that it will have all privileges, regardless of what is actually needed. In some cases, depending on what the service or application does, it might be easier to reduce privileges without much testing.

Modifying privileges by adjusting group membership is a powerful way to reduce what privileges a service account has. However, it might be difficult to know exactly what the service account needs for privileges, so moving a service account out of the group(s) that it was placed into by default might be difficult. For example, if the service account for an Active Directory management tool is placed into the Domain Admins group by default, most likely it would need to remain in this group to perform all the management duties. On the flip side, if the service account supports a basic data management application, the service account might only need permissions to the data and not any privileges through groups or user rights.

Modifying user rights is another powerful way to reduce the privileges of a service account. Many users have rights they obviously do not need, such as rights to change the system time. Some users need rights that might not be so obvious, like they need to be able to create an access token. The good thing is that most service accounts are granted only a few user rights by default. If your organization takes the time to verify and document what each service account has for rights now, that effort is a good start to knowing your exposure.

Active Directory delegation is common when dealing with applications and services related to Active Directory management, backup, recovery, etc. In most cases the service accounts will need to have membership in the Domain Admins group. When dealing with monitoring, auditing, and governance applications, the service account can almost always have reduced privileges and delegations.

Data permissions are usually not as big an issue as when dealing with the enterprise identity solution, such as Active Directory. When a service account for a database is granted full control permissions over a folder, that is typically required. However, if the application only reads or analyzes data, the service account needs fewer permissions.

Securing Service Accounts – Logon Restrictions

Logon restrictions for service accounts are security controls that restrict when and where a service account can log on to a system. These restrictions include:

• Logon time restrictions: These limit the hours during which a service account can log on to a system.
• Logon device restrictions: These limit the devices from which a service account can log on to a system, as shown in Figure 2.

Logon restrictions are important for service accounts because they help to reduce the risk of a successful attack. For example, by limiting the hours during which a service account can log on, an attacker cannot gain access to the system outside of the allowed logon hours. By limiting the locations and devices from which a service account can log on, you can ensure that access to the system is restricted to trusted devices and locations.

Implementing logon restrictions for service accounts is a great way to secure the account, but some attention to detail needs to be done before flipping switches.

First, define the logon restrictions. Define the hours during which the service account can log on, the physical locations from which the service account can log on, and the devices from which the service account can log on.

Next, configure the logon restrictions. Use Group Policy and Active Directory to configure the restrictions on the service account.

Optionally (but maybe the most important) monitor the logon restrictions. Regularly monitor the logon restrictions to ensure that they are being applied correctly. This includes reviewing the logs for any attempts to log on from unauthorized locations, devices, or outside of the allowed logon hours.

Securing Service Accounts – Changing Passwords

This section of this article may be the most important. In my consulting work, I find that many service accounts have never had their password changed since installation. This is a perfect storm for attackers who can easily uncover which accounts have not had their password changed in a long time, or even since the object was created. In situations like this, the attacker knows that the organization has not taken the steps to secure service accounts, and in most cases, they are not monitoring them.

Service accounts, like other user accounts, need to have their passwords changed on a periodic timetable. Best practices suggest changing the passwords every 6-12 months.

Organizations should ideally configure service accounts in a privileged access management (PAM) tool. The PAM tool takes over full responsibility for the service account. Every organization should include a PAM solution, no matter the size of the organization. The PAM solution will give you not only password controls, but many other powerful controls to ensure that you secure, protect and monitor the service accounts.

Summary

Cyberattackers often attack service accounts due to their level of privilege and the fact they are not monitored in many cases. Organizations that make the effort to reduce the attack surface surrounding service accounts perform some of the best security efforts they can. Direct reduction of privileges by altering group membership, removing user rights and delegations, and adjusting permissions on data is an ideal way to reduce the access and power that service accounts possess.

Since all user accounts can logon to any computer in the domain by default, adjusting the logon controls is another powerful way to secure service accounts. Reducing the number of computers and the date/time that a service account can logon is by far one of the most effective ways to reduce what service accounts have access to. If you add monitoring of those logon attempts (and check the logs), that’s the perfect way to catch an attacker that is attempting to logon to a machine that is not approved.