The Security Risks of Service Accounts: You Can’t Protect What You Can’t See
Service accounts play an important role in today’s enterprise environment. These non-human or machine-to-machine (M2M) accounts are used by applications, systems, and services to perform important automated tasks in a network. They need access to resources such as databases, file shares, and other resources to perform their routine tasks. Because of their central role, these accounts often have privileged access so that they can carry out their functions without the need for human interaction.
If not properly managed, however, service accounts can pose significant risks, enabling threat actors using the compromised credentials of service accounts to take them over and move laterally throughout a network undetected.
In this post, we’ll explore what service accounts are and how they’re used and explain the security risks organizations can face if they’re not managed correctly. This is the first part of a three-post series discussing service account security.
What Service Accounts Are and Why They’re Important
Service accounts are dedicated non-human accounts that IT admin creates to run on different machines or in some cases are accounts that are created by process, such as software installation. These accounts are usually defined on the Active Directory (AD). Systems, applications, and administrators use service accounts to interact with other systems, for example, a file manager or an SQL server agent. They perform automatic, repetitive, and scheduled actions in the background, usually without human intervention. Some examples of the different types of tasks that service accounts perform include running an application on a Windows operating system, automated backups, performing database maintenance and more.
These machine accounts can be found across an organization’s network. Certain “hybrid” users, such as infrastructure administrators, and application owners may run scripts from their personal user accounts to machines and essentially act as service accounts.
When a service account is created, it is typically given a set of permissions that allow it to perform specific tasks or access specific resources. In most cases, their permissions are defined by the administrator who created the service account. In a situation where the service account was created by a process, their permissions will be configured by the package manager during the installation of the software that the service account will be connecting to.
Different Types of Service Accounts
There are usually several different types of service accounts in an environment, each one with a specific role. In general, service accounts fall under two scenarios:
- Service accounts created by admins to automate specific tasks.
- Service accounts created during processes, for example during software installation.
Service accounts are usually categorized into specific types based on their exact behavior and permissions level. For organizations that have a large number of service accounts, this tends to be the mix:
Machine to Machine (M2M) Accounts – used exclusively by machines to interact with other machines or services; examples include, a web container communicating with a database container or an application communicating to an endpoint.
Hybrid Accounts – used primarily for M2M access but sometimes used by human users to access specific resources; for example, admin users who run scripts to gain access to shared file servers, databases, or management systems.
Scanners – used by a few devices to communicate with a large number of resources inside a network; for example, vulnerability scanners, health management scanners, and code scanners.
Why It’s Important to Understand the Security Risks of Service Accounts
Although service accounts perform important functions in an environment, they can also pose critical security risks if not managed correctly.
When a service account is created, for example, it can be inadvertently assigned a high level of privilege, equivalent to that of an admin. This, in turn, can create a security issue if admins are not fully aware (i.e., have full visibility into) the exact behavior and activity of those accounts. Often, this is simply due to the improper documentation of these accounts which, as mentioned before, can be a challenge due to their high number as well as issues like IT staff turnover. Over time, this problem compounds, with the initial lack of awareness turning into a serious security blind spot.
Here are some of the specific security risks organizations can face when managing service accounts:
Discovering All Service Accounts
One of the challenges of managing service accounts is discovering all the different accounts that are being used. Since organizations can have hundreds or even thousands of service accounts, it can be a challenge to keep track of every single service account and its activity. If an organization is not aware of all its service accounts, it won’t be able to secure them effectively.
Visibility and Monitoring
Because organizations often lack full visibility into service accounts and how they’re being used, it is difficult to detect any unauthorized access or malicious activity stemming from them. Complicating things is the fact that no identity infrastructure can automatically filter which users are service accounts from the overall list of users.
Additionally, if service accounts are not associated with a specific user, it can be difficult to determine their activity and purpose. This can result in organizations being exposed to security risks, such as not detecting unauthorized access by threat actors which can lead to lateral movement attacks.
High Access Privileges
As stated previously, service accounts can often be assigned a level of privileged access similar to that of an admin. While the typical service account does not require domain-level access, these accounts sometimes end up with overprivileged access to ensure operational continuity. Organizations that are using service accounts for the automation of operational tasks will assign high-privilege access to ensure there is no downtime in their operations. This can create a challenge in terms of properly managing these privileged accounts against incoming identity-based attacks.
No PAM Protection: Password Rotation is Not the Answer
To manage risk, most organizations have turned to implementing password rotation as a strategy for keeping highly privileged accounts secure. But password rotation comes with limitations, as service accounts can’t be subject to password rotation for various reasons, such as the fact that they can be embedded in scripts and could break critical processes if their passwords are rotated. This would invalidate the password in the scripts, preventing the service account from accessing its target resource and subsequently breaking any process that relies on the service accounts’ task.
Next Up: Analyzing Attacks Where Service Accounts Were Used
Now that we’ve covered the basics of service accounts, including what they’re used for and the security risks they present, our next post will dive deep into different security breaches where service accounts were used and, in some cases became the entry point for the threat actors.
The post The Security Risks of Service Accounts: You Can’t Protect What You Can’t See appeared first on Silverfort.
*** This is a Security Bloggers Network syndicated blog from Blog - Silverfort authored by Zev Brodsky. Read the original post at: https://www.silverfort.com/blog/the-security-risks-of-service-accounts-you-cant-protect-what-you-cant-see/
