Service accounts play a critical role in enabling machine-to-machine communication in Active Directory (AD) environments. For instance, email platforms, databases, and internal and internet-facing applications rely on these accounts to authenticate to other applications and backend services. They’re also widely used by security tools to integrate with monitored platforms like AD.
Because service accounts are pervasive across nearly all business operations, they offer malicious actors a tantalizingly broad attack surface with myriad potential points of entry. Numerous high-profile cyberattacks have begun with a service account compromise.
One notable example—the NotPetya attack on pharmaceutical giant Merck in 2017—stands as one of the costliest in history, with damages totaling $1.4 billion. Chillingly, the initial point of compromise was a service account used by System Center Configuration Manager (SCCM) for software patching. (We explore this attack in detail in a dedicated episode of our Hybrid Identity Protection podcast.)
Why do we continue to live with such an obvious point of exposure in our identity system? The answer: It’s complicated.
Why are service accounts so difficult to secure?
The widespread use of service accounts makes them notoriously difficult to find, govern, and secure. The challenges stem from multiple factors.
Service accounts are business-critical
If a service account is unable to access AD—say, because of an account lockout or a password change—the associated application often stops functioning, causing business operations to grind to a halt.
Given the criticality of most business applications and services, many security practitioners are hesitant to make any security-related changes that might disrupt a service account and interrupt business, so the accounts stay untouched and vulnerable.
Service accounts have low visibility
Most AD environments have been in place for many years, sometimes decades. During that time, countless AD-integrated services have been onboarded, upgraded, and retired. And each one introduces its own set of service accounts with specific permissions.
Unlike human user accounts, which are typically managed through structured onboarding and offboarding processes, service accounts often lack formal lifecycle management. As a result, when applications are decommissioned, their associated service accounts are frequently left behind.
Over time, these legacy service accounts accumulate. Organizations can have hundreds or even thousands of stale, unmanaged accounts lingering in the environment, each one a potential security risk.
Static service account passwords are everywhere
Service accounts often use static passwords that rarely change and are sometimes hard-coded into scripts or applications. These credentials are difficult to rotate, and once exposed—through source code leaks, config files, or memory dumps—they can be exploited by attackers who then move laterally or escalate privileges in the environment.
Weak static passwords are especially vulnerable to password spraying attacks. Since service accounts can’t use multifactor authentication, they lack an essential layer of protection. In AD environments, they’re also susceptible to Kerberoasting, where attackers extract and crack service tickets to obtain plaintext passwords.
Service accounts often have excessive privileges
Application and developer teams often assign excessive permissions to service accounts because they lack deep knowledge of Active Directory permission and delegation models. Rather than taking a nuanced approach, they may routinely create high-privileged accounts with permissions that far exceed what’s necessary.
This practice provides a huge opportunity for attackers to leverage any of numerous attack techniques to take over a service account and rapidly escalate privileges. In addition, most service account activity is typically unmonitored, and account compromise is often undetected until it is too late.
How to close the service account security gap
Together, these challenges pose a nearly insurmountable problem for security teams, leaving service accounts a critical gap in most identity security programs.
Let’s look at a layered approach to tackle this difficult problem.
Inventory and classify
The first step is discovering all service accounts in your Active Directory environment. Typically, this means using tools like PowerShell scripts or identity governance platforms.
Then, identify the owner, purpose, and associated systems for each account. Categorize them by privilege level, organizational unit, and authentication method. Remove any orphaned or unused accounts, and maintain a centralized, regularly updated inventory.
Enforce Least Privilege
Assign only the permissions necessary for each service account to function. Avoid granting Domain Admin or Enterprise Admin rights unless absolutely required.
Where possible, use Group Managed Service Accounts (gMSAs) to simplify permission management and reduce risk.
Eliminate hard-coded credentials
Scan scripts, scheduled tasks, and applications for embedded credentials. Where possible, replace hard-coded passwords with secure storage solutions such as Windows Credential Manager or gMSAs to prevent credential leakage.
For some accounts, hard-coded passwords can’t be avoided. In such cases, ensure that you use a secure high-entropy password with the maximum allowable character length.
Monitor and alert
Service account activity should follow predictable patterns and login locations. Enable auditing for service account logon events and monitor for unusual behavior, such as logons from unexpected hosts or at odd hours.
Integrate logs with a security information and event management (SIEM) platform to centralize monitoring and generate alerts for suspicious activity.
Restrict logon and access
Use Group Policy to deny interactive logon rights for service accounts. Restrict where accounts can authenticate using the Logon Workstations setting, allowing logons to occur only on the servers needed.
Automating layered service account security
As you have probably realized, the traditional approach to service account management and vulnerability mitigation is prohibitively time- and resource-intensive. Naturally, that’s what cyber attackers are counting on.
And that’s why Semperis has stepped up with an alternative.
Our Service Accounts Protection module enhances the capabilities of Directory Services Protector (DSP), helping simplify the process of securing service accounts and greatly reducing the time and effort required in the steps we’ve outlined.
This module continually discovers unknown and misplaced service accounts, detects service account misconfigurations, and surfaces risky configurations and critical exposures—while alerting you to malicious and anomalous behavior.
Service accounts have long been the Achilles’ heel of identity security—a critical gap that attackers are always trying to hit. DSP helps you defend them.
Learn more about protecting service accounts in Active Directory
