Demystifying Service Accounts: Authentication Types and Best Practices
Introduction to Service Accounts
As a tech professional, you've likely encountered service accounts in your day-to-day operations. But what exactly are these mysterious entities, and why are they so crucial to our systems?At its core, a service account is a special breed of user account. Unlike your typical user profile associated with a flesh-and-blood human, service accounts are the digital avatars of our automated processes, applications, and services. They're the behind-the-scenes workers that keep our IT ecosystems humming along smoothly.Service accounts wield significant power within our systems. They're granted specific permissions and access rights to perform their designated tasks, often with elevated privileges that would make any security-conscious admin raise an eyebrow. This power allows them to facilitate communication and interaction between various software applications, systems, and services seamlessly.However, with great power comes great responsibility.Service accounts bring a particular set of risks:• Their elevated privileges make them prime targets for attackers looking to gain a foothold in our systems.• They can easily fall through the cracks of our management processes, especially if the original creator moves on to greener pastures.• In the world of cloud computing and DevOps, service accounts can become a tangled web of access and permissions that's challenging to untangle.Service accounts are a major security issue for most organizations, and properly managing them and the credentials used to authenticate those accounts is critical.
Authentication Types
Service accounts, much like regular user accounts, play a crucial role in both local and remote authentication scenarios. If logging is correctly configured, then you will see a log entry each time an authentication is attempted which will contain information about the account used and the way it was used. This could be an application or service starting up and accessing local resources, or perhaps a scheduled task launching. Between devices, the credential might be enabling access to file shares, making API calls or establishing a connection to a database or other service.One crucial part of this is the authentication method that was used. Here are the ones we generally see the most on Windows.
Kerberos
This is pretty much the gold standard for authentication. It is a ticket-based authentication protocol using symmetric key cryptography, designed for strong authentication in client/server applications.High Security: Resistant to many common attacks, uses time-stamped tickets and mutual authentication
NTLM v1
An older challenge-response authentication protocol used in early versions of Windows. With significant known flaws, it should no longer be used.Low Security: Highly insecure by modern standards, vulnerable to various attacks including replay and man-in-the-middle.
NTLM v2
An improved version of the challenge-response authentication protocol used in Windows networks.Moderate Security: More secure than NTLM v1, but can still be vulnerable to certain attacks like pass-the-hash.
Negotiate
This is actually a security package allowing applications to use multiple authentication protocols, typically choosing between Kerberos and NTLM.Moderate to High Security: Depends on the underlying protocol used. Highly secure with Kerberos, less so if falling back to NTLM.You may see other terms mixed in with the authentication method such as User32, Advapi, and Schannel. These generally relate to how the credential was used and by what process. Also note MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 which implies that a version of NTLM was used.
Service Account Permissions and Least Privilege Principle
The principle of least privilege is vital in cybersecurity. It instructs us to limit access rights to only what's necessary for users or systems to perform their tasks. This minimizes the attack surface, reduces the risk of breaches, and prevents accidental or malicious damage.Think about how an attacker moves through an environment once they have gained initial entry – lateral movement and elevation of privilege. By hoping from process to process, device to device that attacker incrementally improves their position in terms of location and permissions. Each of these positions is associated with an account identity. They might move from regular user to local admin, to domain admin, with each jump being achieved using the permissions of the account that they are using in that moment. So, if you remove unnecessary permissions, then you impede the attacker’s ability to progress.
Best/Worst Practices for Credential Management
Password Rotation
Password age is a risk to service accounts. By regularly rotating passwords, you will:• Limit the window of opportunity for an attacker to use a stolen credential. With many passwords ending up in breach dump lists on the dark web, it’s important to keep them fresh• Reduce insider threat risks by removing access from former personnel. Though robust offboarding should achieve this, service accounts are often overlooked.Regularly changing passwords helps prevent unauthorized access, but it requires careful coordination to avoid service disruptions. As an alternative, moving to Managed Service Accounts (MSA) or Group Managed Service Accounts (gMSA) offers automated password management, reducing human error and improving security. They also provide better Kerberos support and simplified administration, making them ideal for organizations looking to enhance their service account security posture.Password ComplexityThough password complexity policies are falling out of favor (see NIST 800-63b draft 4 ), the motivation for removing these policies relates only to humans. So, for service accounts, it is still best practice as you get all of the benefits with none of the downside.With most modern authentication protocols, the password is not used directly by the protocol but rather the cryptographic hash of the password and other data. The idea is that even if you capture the hash (either by observing the conversation or by breaking into an authentication database) it should be hard to work out the password from the hash. This is called hash cracking. However, the key term here is hard – not impossible. It just takes a lot of computing power to do it. The hash from a simple password can be cracked in seconds, but a longer password not based on real words and including symbols and numbers might take weeks. This makes it an expensive operation for the attacker.Password ReuseJust as with regular user accounts, service account passwords should not be reused. As a penetration tester I can tell you that the first thing we do when we find a password for an account is to try it everywhere to see if it works anywhere else.Every account needs to have a unique password regardless if it is a regular user account or a service account.Least PrivilegeWe discussed the perils of granting an account too much permission. However, there is a common pattern that we see in IT. Sometimes, in order to get a service to work, it gets provisioned using an admin account. I have seen local admin, even domain admin. This is almost never required. If the service requires any elevated permissions, then it should be granted them explicitly, not just pumping the whole process up to admin. Once an attacker breaches a process running as admin, then they have control of the whole machine and perhaps the domain.Dormant accountsJust like the risks with old passwords, you should avoid leaving unnecessary accounts lying around. If you created a highly privileged account to support a service that you no longer use, then when you decommission the service, the account should be disabled or deleted too.The more highly privileged accounts an attacker has to work with, the happier they will be as it is easier to jump from process to process and account to account than you might think.Hybrid accountsI am always surprised by how often I see people using service accounts interactively, even using them for RDP. Given that service accounts are often highly privileged, it is ill advised to start an interactive desktop session using such identities. Any vulnerability in a piece of software used in the desktop session puts the whole service accounts and its permissions at risk.WeakauthenticationNTLM v1 has been known to be insecure for years. NTLM v2 has now also been deprecated by Microsoft. But we still see these along with CHAP and others. It is important to retire authentication protocols that are no longer appropriate for your environment, but you should disable them so that they are technically prohibited rather than just not used. This is often done at a system level as part of system hardening.System hardening is complex, and it is easy to miss some of the more esoteric configuration settings required to make your authentication functions safe. So, make sure you use a specialist to get this right.Conclusion and Call to ActionIn summary, effective management of service accounts is essential to minimize security risks. Implement best practices such as enforcing least privilege, rotating passwords, and decommissioning stale accounts. Regular audits and retiring outdated authentication protocols like NTLM ensure a stronger security posture. Start by reviewing your service account activity to tighten access controls and safeguard your environment from potential breaches.
About the Author:
Andy Cottrell is the founder and CEO of Truvantis, a Cybersecurity and Privacy consultancy that helps organizations of all sizes Manage Risk, Build Business Resilience and Win Stakeholder Trust through Penetration Testing, Security Program Building and Compliance Assessments such as PCI DSS, CMMC, HIPAA and GLBA. A security thought leader for more than 25 years, his passion is helping organizations move beyond compliance to realize true business value from their cyber-defense budgets.
