Red Flag Alert: Service Accounts Performing Interactive Logins

December 16, 2020

| Identity Protection Team | Identity Protection

This blog was originally published on August 29, 2019. In the world of identity and access security, experts focus on end-user accounts as the weak vector most vulnerable to attackers. On the contrary, we at Preempt (now CrowdStrike) see something that happens just as frequently: failing to limit exposed and vulnerable service accounts. Service accounts differ from end-user accounts in that they usually have higher privileges that are used to control or call applications, APIs and services. As a result, looking for key indicators of compromise (IOCs) among your service accounts should be at the forefront of your network security strategy. Service accounts, when compromised, can become the most dangerous insider threat of all. 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. Applications and calls 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 they are often installed under the intrinsic local system account and essentially have local administrator privileges. These privileges could potentially give account access to domain credentials and allow them to laterally move within your network. To make matters worse, service account passwords are hardly ever changed or rotated for fear of disruption. Why are service accounts so vulnerable to compromise? First, the directory server doesn’t 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 those services tend to be privileged accounts with administrative privileges, if they are compromised attackers have the ability to move around the network and modify sensitive, critical systems. If attackers access a service account, they can indirectly access all the resources to which that service account has access to. Users given the role of a service account user can use those credentials to access all resources tied to the account, and potentially impersonating the service account to perform many tasks using those elevated roles and permissions. Essentially, an attacker can go completely unnoticed within your network and steal or manipulate your Active Directory (AD) domain — the metaphorical keys to the kingdom.

Interactive Logins For Service Accounts Are Bad News

Interactive login is 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 (on a Windows machine). When the user is logged in, Windows will run applications on behalf of the user and the user can interact with those applications. 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.” This page describes Microsoft local and domain interactive login. So if you see a service account performing an interactive login, this often is a clear indicator of a potential security breach. How so, you ask? As we mentioned earlier, service accounts are very privileged accounts, used to start services that run in the background of the machine. Now, when there is an interactive login, it assumes that there is a human user 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. This creates an insider threat from a trusted credential used by many different services and applications. 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 is anonymous and can be used anywhere on the network. Essentially, the credentials used to log into the service account are 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 service account insider threat via interactive logins is through the AD group policy. You can create a special security group (GPO) 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. Attackers can still bypass AD group policies by simply using default passwords or trying out 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 to understand where all of your service accounts are in your network and limiting those accounts from performing an interactive login.