Securing the Use of Service Accounts Without Changing Passwords!

***** By Mike Carroll, Sr. Sales Engineer, Silverfort *****

Service accounts are a prime target for hackers. However, securing the use of service accounts is a major challenge for enterprises. Silverfort’s Agentless Authentication platform is uniquely positioned to protect Active Directory domain service accounts without the intrusive need for frequent password changes, or even being aware of their existence. This blog post explains how.

What are Domain Service Accounts and Why are they Risky?

I will quickly distinguish between two types of service accounts: domain service accounts and local host service accounts: Local host service accounts are configured and managed on the local system to allow an application to interact with the operating system, network, etc. These are relatively easy to provision and manage since it’s a local user and the passwords aren’t frequently used, so changing passwords has little impact. Domain service accounts are a different story because they are defined at the domain level – this introduces a number of additional challenges you’ll need to overcome in order to manage them securely. As a result, domain level service accounts are especially tricky to manage and secure.

For example, one of the basic, but also important requirement is to create the accounts with the absolute least privilege required for the application to function properly. However, vendor documentation only specifies what settings are required, it never explains how to limit it’s privileges or how to secure the account.

Considerations for least privilege, along with planning and executing good password change and rotation strategies can add additional hours/days/weeks of effort to projects. Therefore, many times, these accounts are created quickly, and they are over-permissioned, to allow the install process to continue without delay. Even with the best intentions to go back and secure it properly after the installation completes, it usually doesn’t happen. Instead, as quickly as these accounts are added to the “Domain Administrators” group, they are forgotten. Over time, with staff turnover and a lack of documentation, the understanding of least privilege assignment, which applications use the different accounts or even the knowledge that the service account exist at all – is lost.

To further complicate things, domain service accounts frequently require password changes to be coordinated to happen at both the domain level and the application level simultaneously. Otherwise you may experience unwanted downtime. However, this isn’t always easy to coordinate. In some cases, the passwords are hardcoded in clear text within the application configuration or source code. Therefore, unless special precautions are taken for protecting the password on the application server, and in developer copies of source code, they can also be used by malicious threat actors.

Visibility is Key!

Without the ability to really understand how service accounts are being used, or what applications rely on them, IT managers wisely fear changing these passwords. If a service account has unknown dependencies, even a simple password rotation could potentially result in an outage to critical business systems – therefore, in many cases, it is not worth the risk.

This means that in order to secure your service accounts you need to understand exactly what each account is doing, audit their usage and identify their dependencies – but this is challenging. Add to that the need to apply least privileges and industry recommended security best practices (like password changes) – and this becomes a significant burden.

What about Privileged Access Management (PAM) solutions that can manage password rotations?

There are some commercial solutions designed to automatically change local and domain user passwords. However, in order to implement them the application needs to be modified to replace any hard-coded passwords, within the source code or configurations, with a new code that dynamically pulls the current password from the vault. Therefore, implementing these solutions still requires a thorough understanding of each service account in the domain as well as the application that depends on it before the implementation.

THE HARD TRUTH: IN MOST ORGANIZATIONS, NEVER CHANGING THESE PASSWORDS IS THE NORM!
Meanwhile penetration testers and real-world threat actors shorten the attack cycle to hours or days, taking advantage of that fact that even an ambitious 30-day password rotation policy for service accounts can leave them vulnerable to account hijacking.

In today’s reality, organizations have thousands of legacy on-premises and cloud-based applications – all required for performing critical business operations – and many of them use domain level service accounts. Most leverage password-based authentication mechanisms leveraging protocols like Kerberos, NTLM, LDAP, LDAPs or SMB, which can be difficult to secure and require passwords to be managed in AD as well as the dependent application resource. This has become a universal pain!

The Silverfort Approach to Securing the Use of Service Accounts

Silverfort is famous for building the first agentless authentication platform capable of providing multifactor authentication (MFA), without requiring agents, proxies or man-in-the-middle style decryption. This allows it to enforce MFA on previously unprotectable resources and interfaces like administrative shares, PowerShell sessions, the Registry Editor, IT infrastructure like routers, appliances, hypervisors, and more –without requiring software agents or inline proxies.

FIGURE 1: SILVERFORT’S MANAGEMENT CONSOLE DASHBOARD: SILVERFORT CONTINUOUSLY MONITORS ALL AUTHENTICATION ACTIVITY

Silverfort’s agentless authentication platform provides a tremendous level of visibility into how authentication traffic flows through your entire enterprise, both on-premises and cloud environments. Every authentication message is analyzed: humans logging into workstations, servers or apps, as well as any service accounts used for machine-to-machine communication. All authentication traffic is analyzed by Silverfort’s AI-Driven Risk Engine in real time to automatically identify behavior patterns, discover anomalies and threats and assign a risk score to every User, Device, Resource and authentication attempt.

Automatic Service Account Detection

This unparalleled level of visibility is exactly what makes the automatic detection of domain service accounts a possibility. Service Accounts have predictable behavior patterns, which allows Silverfort to automatically identify and categorize them. Silverfort’s AI driven risk-engine easily detects repetitive and predictable authentication patterns that may not be obvious to a human observer. For example, an account leveraging NTLMv1 from a single IP address authenticates at precisely 6:16am every other day. Machine like patterns are also be detected within the erratic patterns associated with human user activities, so when a human associates an application to their own personal account, Silverfort will detect its double use as a user and service account. Automatic service account detection is shown in the screenshot of the management console below.

FIGURE 2: SILVERFORT AUTOMATICALLY IDENTIFIES SERVICE ACCOUNTS

Silverfort automatically locates and identifies service accounts, it shows what they are doing, which are running with privileged credentials or being used by humans, and what applications are dependent on them. This visibility allows us to monitor their usage and manage them more efficiently and securely, making frequent password rotations a realistic possibility.

FIGURE 3: SILVERFORT PROVIDES DETAILED INFORMATION ABOUT DETECTED SERVICE ACCOUNTS, INCLUDING RESOURCE DEPENDENCIES

Introducing Silverfort Domain Service Account Virtual Fencing
Now that service accounts are profiled and you understand where they are used, what resources they connect, and exactly which services are being leveraged, we can start to secure their usage. Silverfort has 3 basic types of authentication policies: Allow Access, Deny Access or Require MFA. For obvious reasons, implementing MFA for service accounts doesn’t make much sense – after all, there is no human monitoring these accounts to address the MFA request. However, Allow and Deny access policies can be leveraged to create a virtual fence around service accounts. The policies simply allow the service accounts to continue operating according to the same predictable authentication behavior that has been observed previously, while denying any authentication attempt outside these bounds. Therefore, even if a service account has permissions to access other computers, it’s simply blocked from authenticating outside the boundaries of the virtual fence.

This simple strategy dramatically reduces the risk that hijacked service accounts will be used for malicious lateral movement throughout your network.

FIGURE 4: SECURING THE USE OF SERVICE ACCOUNTS

Conclusion

Dealing with service account security is a major pain! CISO’s and IT managers can lose sleep, and sometimes their jobs over business disruptions related to service account takeover. Until now, the only solutions available require an unrealistic knowledge and understanding of the service accounts that exist in your network. Some solutions require complex changes to applications in order to implement commercial solutions to properly secure these accounts.

Silverfort’s platform is easy to implement and provides great value with agentless monitoring and security policy enforcement. Its advanced AI-driven engine automatically detects the use of service accounts, and can enforce policies to significantly reduce the risk associated with managing service accounts without changing passwords or application code.