Key Points

• Organizations frequently over-privilege and poorly secure service accounts, making them easy targets for attackers who can use their elevated privileges to compromise entire networks.
• Over-privileged service accounts enable threat actors to exfiltrate and encrypt data, disrupting business operations and leading to extortion through leaked sensitive data.
• Service accounts are often compromised via insecure credential storage, credential dumping, or Kerberoasting.
• Organizations should use group Managed Service Accounts (gMSAs) to secure passwords and limit account privileges.

Service accounts—often configured and then forgotten—are prime targets for attackers during enterprise incidents. These specialized accounts are designed to operate without human intervention, but can be logged in to by users, if needed. Commonly denoted with “svc,” organizations use service accounts to automate tasks and applications to ensure continuous operations. However, service accounts are attractive targets for threat actors due to their elevated privileges, weak password security, and broad access to multiple systems within an organization.

In a representative sample of breaches that ReliaQuest responded to between January 2024 and July 2024, 85% involved compromised service accounts. This marks a notable increase compared to the same period in 2023, where 71% of breaches involved compromised service accounts from the same sample size, highlighting a concerning trend. This uptick could indicate that organizations are increasingly failing to secure service accounts, providing more opportunities for threat actors to exploit these security gaps. Given their critical role in all enterprise environments and their popularity with threat actors, it is crucial for every organization, regardless of sector or region, to secure service accounts.

This report explores the vulnerabilities associated with service accounts, details the growing trends in security breaches involving these accounts, and provides actionable recommendations for security teams and leaders to mitigate these risks effectively.

Attackers’ Method of Choice

Service accounts are highly favorable targets for threat actors seeking to gain access to multiple systems within an environment for many reasons:

• Broad access: Depending on the application involved, service accounts may require access to many systems to function correctly. Because they have extensive access privileges, service accounts can act as a single point of failure, making it easier for threat actors to compromise an entire environment rapidly.
• Consistency: Threat actors have capitalized on the ubiquity of service accounts across enterprise environments by developing numerous tools and techniques specifically designed to exploit this infrastructure. Kerberoasting is threat actors’ method of choice for compromising service accounts, as seen on criminal forums sharing guides and successful attacks (see Figure 1).

Figure 1: Threat actor shares details of successful Kerberoasting attack

• Elevated privileges: Service accounts often have far higher privileges than are required; administrators sometimes grant full domain admin rights to service accounts to expedite the setup process and prevent potential service disruptions. But when attackers successfully breach these accounts, they gain elevated privileges that allow them to access sensitive data for exfiltration and spread malicious software, such as ransomware, across the environment to encrypt data. Both of these actions lead to extortion.
• Lack of monitoring: Service accounts are intended to run in the background, and as such, they are monitored less closely compared to user accounts. Therefore, there is less chance an attacker using a service account will be detected, meaning they can conduct malicious activity for longer.
• Weak security: Service accounts sometimes come with a default password set by the vendor that security teams fail to update. They may also have weak passwords because they are not subject to the same security policies as user accounts. This allows threat actors to access service accounts with easily guessable passwords and makes password cracking easier.
• Registered with Service Principal Names: When a service account uses Kerberos authentication, a service principal name (SPN) is required. This makes the service account susceptible to Kerberoasting attacks, which can be conducted using many freely available tools, such as Impacket. This provides a simple method for gaining access to service accounts using prebuilt tools, lowering the barrier to entry and required expertise for would-be attackers.
• Extended ticket granting ticket sessions: To minimize service disruption, service accounts are commonly configured to have Kerberos ticket-granting tickets (TGT) for extended sessions. This makes the accounts more susceptible to pass-the-ticket attacks , which can facilitate lateral movement for threat actors within the network and provide unauthorized access to sensitive data or allow for the installation of malware.

Achieving Service Account Takeover

After breaching an environment, adversaries often attempt to gain access to service accounts to elevate privileges and move laterally through the rest of the environment. In some instances, ReliaQuest has observed compromised service accounts that provided full domain administrator privileges to an adversary. Domain administrator privileges grant a user the highest level of control over a network domain, allowing them to manage user accounts, configure system settings, and oversee security measures across all computers and resources within the domain. These accounts are highly sought-after by adversaries. Access to these accounts is regularly sold on cybercriminal forums (see Figure 2).

Figure 2: Forum post selling domain admin access

Below, we discuss the most common techniques attackers use to compromise service accounts, including Kerberoasting, password cracking, credential theft, and credential dumping.

Kerberoasting

ReliaQuest frequently observes threat actors conducting Kerberoasting to compromise service accounts, including in a drive-by compromise incident involving “Gootloader” malware. Kerberoasting is a favored technique for compromising service accounts because it is easy to execute with premade tools such as PowerSploit, Rubeus, and Metasploit modules. Additionally, it can be used to compromise entire domains, making it a significant threat to organizational security.

This technique is frequently discussed on cybercriminal forums. For example, in one post recruiting “individual pentesters or ready-made teams” to a malicious “penetration-testing” team, the user stipulated that a “personal interview” would be required before starting work. They also requested prior experience with “VPNs and webshells” and “various frameworks” as well as the ability to “escalate privileges with antivirus [software]” and “use the latest LCE and RCE exploits.” The post concluded by mentioning that ready-made tools would be provided and that the affiliate would work for a percentage of any profits earned from an attack. One forum member replied to the post saying, “Experienced in domain networks, kerberoasting, as-rep roasting, DC sync, persistence with cobalt strike, I’ll write to you.”

Figure 3: Forum post recruiting members for a penetration-testing team with required skills

Kerberoasting is a post-exploitation attack technique used by adversaries to extract service account credentials in a Windows environment. The attack leverages the Kerberos authentication protocol, which is widely used for authenticating users and services in Active Directory (AD) domains. When a user requests access to a service, they request an SPN associated with that service, and the Kerberos protocol issues a ticket-granting service (TGS) ticket, which is encrypted with the service account’s password hash.

Attackers can request TGS tickets for services and save the encrypted tickets to perform offline brute-force attacks to crack the hash and reveal the password. Tickets encrypted with RC4 are particularly vulnerable to cracking due to its weaker encryption strength, making it easier for attackers to decrypt tickets and obtain service account passwords. Furthermore, accounts with weak or easily guessable passwords are even more susceptible to having their hashed passwords cracked.

Default and Insecure Passwords

Disabling interactive and remote interactive sessions for service accounts is considered security best practice. However, some organizations opt to enable interactive and remote sessions for ease of management, which can lead to poor password security practices.Top of Form Because service accounts require high availability, accessibility often surpasses security. These accounts are commonly excluded from password management practices, including password rotation and long, complex passwords. Weak passwords leave service accounts vulnerable to compromise from brute-force attacks or cracking when the password’s respective hash is obtained from a Kerberoasting attack. Additionally, some service accounts are created using a default password, which poses a high risk if left unchanged. Threat attackers can often find default passwords online in vendor documentation or forums and use them to access the account.

Insecure Credential Storage

When passwords are used by several administrators in an organization, insecure password sharing and storage can occur. Examples of insecure storage include plain text files, spreadsheets, emails, shared drives, and backup files. Passwords can also be hardcoded into automated scripts or configuration files, exposing them to adversaries who can easily extract these credentials. Attackers can exploit these credentials to conduct lateral movement using tools such as PsExec or Impacket or perform AD enumeration with elevated privileges to gather more comprehensive data using tools like BloodHound.

Credential Dumping

Like any other user account, service accounts are at risk of compromise from operating system (OS) credential dumping. This technique involves obtaining a database or memory cache from a system that contains either hashed or plaintext credentials. Prevalent examples include memory dumping from the Local Security Authority Subsystem Service (LSASS) and extraction of the Security Account Manager (SAM) database on Windows. Both methods employ a variety of tools to accomplish these actions, ranging from malicious utilities such as “Mimikatz” to tools that appear benign, like Procdump.

Service account credentials are cached in the SAM database and stored in LSASS only when used for interactive authentication, allowing local authentication without a domain controller, while non-interactive logins temporarily store Kerberos tickets in LSASS. Although these Kerberos tickets can be extracted and used in pass-the-ticket attacks, the permissions gained are limited to the services the account is intended to run.

Enabling interactive authentication for service accounts increases security risks by providing adversaries with an additional attack vector for credential dumping, thereby expanding the attack surface. This can make service accounts with credentials stored in LSASS and the SAM database susceptible to compromise when credentials are successfully dumped, providing greater access to other systems and elevation of privileges.

Case Study: Service Account Takeover Leads to BlackSuit Ransomware Deployment

In April 2024, ReliaQuest responded to a detection triggered by Kerberoasting in a customer’s environment. Below, we’ll provide an overview of the kill chain steps to highlight the role of compromised service account in the attack.

• Initial access: An unknown threat actor exploited a non-primary virtual private network (VPN) gateway that lacked multifactor authentication (MFA). The attacker used a valid account, which was likely accessed through brute-force methods or credentials obtained from a data breach or information-stealing malware. The attacker moved laterally across Windows workstations using PsExec, then likely sold access to the BlackSuit ransomware group.
• Credential access: Ten days after the initial breach, the attacker used the compromised account to authenticate to a Windows server that did not have logging. The attacker downloaded Rubeus, a tool used to abuse Kerberos, and then conducted Kerberoasting, compromising over 20 accounts including “admin1.”
• Privilege escalation: The “admin1” account—operating as a service account with domain administrator privileges—allowed the attacker to create a copy of the AD domain database (NTDS.dit), compromising the entire domain.
• Exfiltration and impact: The attacker used the “admin1” account to extract over 100GB of data from an unmonitored Windows server. Six hours later, the attacker installed a Windows virtual machine using VirtualBox to conceal the ransomware deployment. They then used PsExec to distribute the ransomware payload across hundreds of hosts and executed it via Windows Management Instrumentation (WMI).

Lessons Learned

The insights gained from this incident highlight critical vulnerabilities that the threat actor was able to exploit. Notably, the account “admin1” was assigned an SPN, making it susceptible to Kerberoasting. The swift compromise of this account by the threat actor underscores the importance of robust encryption and a strong password to resist cracking. Additionally, the account was excessively privileged with domain admin access, granting the threat actor total control. The organization could have mitigated this attack and slowed the attackers’ progress by implementing adequate logging to increase visibility and enable detection along with following best practices for securing service accounts (see “Recommendations” below).

Threat Forecast

Given the widespread lack of security practices with service accounts, the advantages gained when exploited, and the multiple, low-cost methods of compromising them, ReliaQuest forecasts with very high confidence that this attack technique will continue in the immediate future (in the next few days or weeks). Threat actors targeting enterprise organizations, whether for financial extortion or intellectual property theft, will more frequently employ this technique. This expectation is supported by the representative breach data, showing that 85% of breaches between January 2024 and July 2024 involved compromised service accounts, a notable increase from 71% during the same period in 2023. The abuse of service accounts is not limited to financially motivated threat groups; it also includes adversaries with geopolitical interests or those seeking intellectual property theft. This was indicated by a nation-state-sponsored intrusion we identified last year, carried out by a threat group associated with the People’s Republic of China (PRC), which involved multiple compromised service accounts.

In the long-term future (beyond one year) we anticipate that threat actors will continue to use common penetration testing tools to compromise service accounts (e.g., PowerSploit, Rebeus). Credential dumping and Kerberoasting are among the most common techniques for accessing service account credentials. We anticipate that threat actors will continue to innovate these techniques, primarily to bypass detections of abnormal behaviors or signatures, such as unusual Kerberos service ticket requests. Adversaries will innovate to speed up the process of compromising service accounts to evade detection, maintain access, and achieve their objectives.

What ReliaQuest Is Doing

To identify suspicious service account abuse, ReliaQuest offers detection rules via ReliaQuest GreyMatter that alert defenders of unusual activities involving service account exploitation. To remediate such activities, associated automated response playbooks can be executed by ReliaQuest customers or by the ReliaQuest team on a customer’s behalf. GreyMatter automation offer a range of remediation solutions designed to impede attacker progress and eliminate them from the environment. For even faster remediation, automation can be implemented to rapidly contain or block malicious activity.

Recommendations

Enhancing service account security can significantly impede threat actors’ attempts to escalate privileges and move laterally through an environment. In addition to hindering an adversary’s progress, this added layer of security also extends the timeframe for detection and response, further preventing attackers from achieving their malicious objectives. The following recommendations and best practices for securing service accounts will help build a robust security foundation against the risk of service account compromise.

Proactive Mitigations

• Use secure password managers to store service account credentials, ensuring they are protected, yet easily accessible, only to authorized personnel.
• Verify that service accounts have only the necessary privileges; don’t over-provision rights such as domain admin rights. Our case study shows over-provisioning service accounts can enable compromise of an entire AD domain.
• Enable AES encryption for Kerberos tickets to mitigate cracking. This encryption method offers stronger security and is more resistant to brute-force and cryptographic attacks compared to older algorithms like RC4. Threat actors prefer to compromise service accounts through Kerberoasting, and encrypting tickets with AES will provide more resilience if attackers obtain them using this technique.
• Configure service accounts to prohibit interactive logins and place them in a special security group to limit their access and reduce attack surface. This limits an attacker’s abilities if the account is compromised.

Service Account Management

• Identify and document all service accounts in your environment to maintain an accurate inventory. Additionally, catalog current service account permissions to identify over-privileged accounts and adjust access to only what is required.
• Deregister accounts with SPNs if they are no longer needed to reduce potential attack surface. Having an account with an SPN registered leaves it vulnerable to Kerberoasting attacks.
• Remove dormant service accounts to minimize security risks and maintain a clean AD. Unused service accounts can still provide an avenue for attackers, so removing them eliminates this risk.
• Implement group Managed Service Accounts (gMSAs) to provide automated password management for services running on multiple servers. With gMSAs, strong passwords up to 240 characters are automatically generated and changed every 30 days. The operating system queries Active Directory (AD) when a password is needed, removing the risk of interactive logins and reducing the attack surface. This security measure mitigates the risk of service account password hashes being cracked if obtained through Kerberoasting and enables easier account management.