Service Accounts are increasingly popular with cybercriminals, and it’s easy to see why. Service accounts can present a huge hidden risk. What is a Service Account? In the simplest form, a Service Account is used as a replacement for a human account.
Similar to having a human user in HR versus a user in IT, different service accounts have specialized roles and different types of access. Common uses for services accounts include running services, scheduled tasks, applications, processes, automation, and scripts. There are endless service account use cases, but the idea behind them is to provide a means of individual security and control around them to execute a specific purpose.
Service account management alone can be daunting. Best practices for managing service accounts entails constant discovery and knowing where and how the accounts are being used at every moment. Then there’s the challenge of enforcing password security best practices, such as integrating password rotation intervals, but doing so, of course, without causing an outage.
You might be thinking, “Hey, that’s all great, but we know about our service accounts!” I challenge customers daily with - “Do you?”
Service accounts have been used for decades. While you might have a process for the newer service accounts, what about all the legacy ones? If you know about them, are you managing them by enforcing password rotation? Or, are you like every other enterprise out there worried about causing an outage if you did rotate them?
I constantly challenge CISO’s and security professionals to proactively discover service accounts in all 4 corners of their networks. After all, it’s not the accounts you know about that pose the greatest risk, it’s the ones you don’t know about. And, whenever you’re talking about an account with any kind of privileged access, it could present a backdoor into sensitive parts of your environment.
Common Use Cases for Service Accounts Involve Privilege – What are the Implications?
When we think about service accounts and how they are used, several use cases come to mind. From the simplest form of a scheduled task or running a service, to more complex forms such as applications, integrations, databases, and scripts. All of these use cases require some form of privilege in the environment, locally on the server, in the application—or even in the domain to function properly without interruption. Therefore, knowing where and how a service account is used is a highly consequential security consideration.
Often, service accounts live in Active Directory, but even if they do not, it’s still hard to paint a picture in the details of the accounts on how and where they are used. While some of you might be thinking you have a documented process for this, I think we can all agree that we have struggled at some point in our career with current or updated documentation. For large enterprises, multiply this by hundreds or thousands of service accounts and then rationalize the tracking, accountability, management, privileges, and auditability that are needed to complete a lifecycle for them. The odds are stacked against you.
Let’s take this a step further and talk about privilege escalation and the removal of admin rights, and why this is even more important now than ever.
Remote access continues to remain the #1 attack vector for cybercriminals. Of course, the current pandemic and circumstance around the remote workforce and telecommuting have only solidified this trend. Additionally, 80% of breaches involve some form of privileged credential compromise.
If you were to switch shoes with a cybercriminal and think about how you could compromise your organization once you established a beachhead, are service accounts one of the first things that come to mind? Maybe not, but it’s a great argument to have.
Cybercriminals know that companies often struggle with service account management and excessive provisioning of privilege or rights. They know that service accounts often get configured and added to the “Domain Admins” group because there is no defined role-based access control (RBAC) or rights delegation model available from the source of the request. I think we can all agree we have been down this path at some point where we have seen, or even asked, for a service account to be put in the Domain Admins group due to a lack of documentation defining all the delegated rights it needed to function.
What does this mean for cyber threat actors? If a service account is compromised, criminals can leverage the accounts to install malware, ransomware, and spyware. They can then move laterally throughout the environment, probing systems, installing more software, deleting accounts, data, you name it—without any restrictions. If you think about this on a grand scale, couple it with the notion of “it’s not a matter of “IF” we get breached, but “When!” You start to realize how big of a hidden risk service accounts pose.
Make sure you spend the time, energy and effort to focus on service accounts and how they might negatively impact your organization or company if exploited. Discovering and managing service accounts, along with limiting their rights and privileges, is an increasingly important security practice that should not be overlooked.
Find, manage, and secure your service accounts with BeyondTrust. Contact us today.
Christopher Hills, Deputy Chief Technology Officer, BeyondTrust
Deputy CTO focused in Privileged Access Management (PAM) and Identity and Access Management (IAM). Architecture, Engineering, and Implementation of BeyondTrust's Privileged Access Management Solutions enforcing Privileged Password Managment and Privileged Session Management, Privileged Endpoint Management, and Secure Remote Access which utilizes a single pane of glass for all management aspects including Audit, Reporting, and Vulnerability.