In the world of account security, we often focus on end user accounts as the weak vector vulnerable to attackers.
On the contrary, we at Preempt see something that happens just as frequently: failing to limit exposed and vulnerable service accounts. Service accounts often differ from end user accounts in that they usually have higher privileges that are used to control or call applications and services. As a result, looking for key indicators of compromise of your service accounts should be at the forefront of your network security strategy.
One clear red flag for any security team should be service accounts performing an interactive login, which would normally be done by a human user, and these instances should be limited in usage as much as possible.
Why Service Accounts Are Left Exposed
A service account is a special account that an application or service uses to interact with the operating system or another application or service. Services use the service accounts to log on and make changes to the operating system or the configuration and perform these activities in the background. Service accounts are especially important because oftentimes they are installed under the built-in local system account and they essentially have local administrator privileges. These privileges could potentially give an account access to domain credentials and allow them to laterally move within your network. To make matters worse: Service account passwords are usually never rotated for fear of disruption.
Why are service accounts so vulnerable to compromise? First of all, the directory server doesn't really have a good way to distinguish service accounts from end user accounts, making it difficult for IT administrators to track all of the service accounts in their environment. Given that that services tend to be privileged accounts and thereby have administrative privileges, attackers have the ability to move around the network and modify sensitive, critical systems.
If attackers were to access a service account, they would indirectly access all the resources to which that service account has access to. Users who are given the role of a service account user can use that account to access all resources tied to the account — thereby possibly impersonating the service account to perform any tasks using the granted roles and permissions. Essentially, an attacker can go completely unnoticed within your network and steal or manipulate your AD domain — the metaphorical keys to the kingdom.
Interactive Logins For Service Accounts Are Bad News
An interactive login is an authentication to a computer through the usage of their local user account or by their domain account - usually by pressing the “CTRL+ALT+DEL” keys. When the user is logged in, Windows will run applications on behalf of the user and the user will be able to interact with those applications. An interactive login is usually performed locally where the user has direct physical access to the machine or through Terminal Services, which the user can perform a remote login, often called “remote interactive login”. The chart below describes a local and domain interactive login:
So when you see that there is a service account performing an interactive login, this oftentimes is a clear indicator of a possible security breach. How so, you ask?
As we mentioned earlier, service accounts are usually very privileged accounts, usually leveraged to start services which run in the background of the machine. Now, when there is an interactive login, it assumes that there is a human user that is on the other side of the machine attempting to gain access to highly privileged roles and permissions. Because service accounts are often left alone to run services without the need of an end user, it becomes highly suspicious when a service account is logged in by a human user.
More dangerous is the additional factor that any login to a service account is not directly tied to an end user account. Thereby, we cannot verify if the person who is logging in is Bob the System Administrator or Brenda the Black Hat. The major concern is that the service account could be anyone and be used anywhere on the network. Essentially, the credentials used to log into the service account is now available to multiple people and they can make any kind of configuration or manipulation to your AD domain without accountability. When investigating a security incident, having that accountability is critical when tracing back to the initial intrusion point of a security breach and removing the areas of weakness in your network.
Ways to Limit Service Account Exposure
One way to protect against interactive logins is through the AD group policy. You can create a special security group in AD to identify users that you want to run services but not allow any interactive login to a machine in your domain. Creating a group that prevents direct access to a system is one way to mitigate the problem but unfortunately does not provide enough restrictions to fully protect against interactive logins.
One way that attackers can bypass AD group policies is simply leveraging default passwords or passwords that never expire. For example, service accounts are used to configure Windows services to run locally on the machine or to be used for service connections to web applications with back-end databases. Many of these domain joined machines and web applications are allowing domain users with default passwords or passwords that never expire to gain access to their services. Despite setting a GPO to add a group of users to the non-interactive login list, you are forgetting that there may be many other users that already have default privileges to the resources you are trying to protect.
The best way to understand if your service accounts are vulnerable to compromise is simply understand where all of your service accounts are in your network and limiting those accounts from performing an interactive login. Preempt gives you some tools to help protect against potentially exposed service accounts by:
- Identifying service accounts: which are vulnerable to compromise
- Analyzing security incidents to look for signs of compromise
- How to enact policies to stop attacks on service accounts
- How to block service accounts from being used to log in interactively
For more information on how to limit interactive logins for service accounts, please contact us at firstname.lastname@example.org.