The Service Account Problem We Never (Completely) Fixed
This article is part of a series unpacking the NSA and CISA’s Top Ten Cybersecurity Misconfigurations through the lens of real-world breaches and assessment findings.
This entry continues Misconfiguration 2: Inadequate Identity and Access Management, with a focus on service account risks that persist despite modern controls. It examines how Kerberoasting, weak or hardcoded credentials, unmanaged SPNs, vendor account practices, and interactive logon rights create attack paths that are easy to miss but highly valuable to adversaries.
TL;DR
Service accounts have been a known risk for decades, yet techniques like Kerberoasting still succeed because accounts with SPNs often have excessive rights, weak encryption, weak passwords, and minimal oversight. Hardcoded credentials, interactive logon exceptions, and privilege creep make them easy targets. Ownership is often disputed between application owners, IT, and security, creating governance gaps.
In one case, a critical business application account with a password of “SQL4Life!” was hardcoded in configuration scripts, used interactively, unmanaged by PIM/PAM or gMSA, and left unchanged for over a decade because the application owner refused to allow a reset. Low-cost controls like gMSAs or vaulting in CyberArk or Delinea can help, but uneven ownership means the problem persists.
The SPN Problem
Service Principal Names (SPNs) are the bridge that allows Kerberos to authenticate a service account to a specific service. They also happen to be the key ingredient for Kerberoasting. If a service account has an SPN, an attacker with a standard domain account can request a Kerberos service ticket for it, extract it, and attempt to crack it offline. There is no exploit. There is no alert unless you are looking for it. And in far too many environments, those SPNs are tied to accounts with far more privileges than they need.
SPNs are not inherently dangerous, but the way they are managed almost always is. Accounts created for temporary installations are left in privileged groups for years. Weak encryption types like RC4 are still enabled on accounts that also have SPNs, and they often have passwords that would fail even the most basic audit. Weak passwords and weak encryption together make cracking service tickets trivial, especially when the account controls something important.
If you want to see what SPNs exist in your environment, you do not need an advanced toolset. You can list them directly from Active Directory using a simple PowerShell command:
PS C:\Audit> setspn -Q */*
This command queries Active Directory for all accounts, both user and computer, that have any Service Principal Name assigned.. For more information, see: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setspn
Alternatively, in Active Directory Users and Computers: View menu → enable Advanced Features → open the properties of a user or computer account → Attribute Editor tab → locate the servicePrincipalName attribute to view or edit assigned SPNs.
In many cases, the riskiest accounts will stand out immediately. They are the ones in privileged groups, with old or non-expiring passwords, and sometimes with the same account reused across multiple services. In practice, this risk is amplified by how hard it is to change these accounts without upsetting production. Application owners, IT, and security will each have a different perspective on who “owns” the service account.
I have seen first-hand how this tug-of-war plays out. In one assessment, I came across a critical business application account with the password SQL4Life!. It had been hardcoded into configuration scripts for over a decade, used for interactive logins, unmanaged by any PIM/PAM or gMSA, and tied to an SPN. The endpoint detection platform eventually flagged the hardcoded password when it scanned a deployment script. Security immediately pushed to rotate it.
That is where the battle began. The application owner, who was not in IT but in the Finance department, flatly refused. The reasoning was simple. Changing the password might “break the system” and there was no vendor support to help recover if it did. The application itself was long past end-of-life but it still processed transactions the business relied on daily. The safer technical path was obvious. The politically safer path was to leave it alone. The account remained exactly as it was, an open door hiding in plain sight.
That is the reality attackers count on. A single SPN with high privileges, weak encryption, and a weak password is a low-noise, high-reward target. It survives because fixing it requires cross-team coordination and a willingness to disrupt the way things have always been done.
Beyond Kerberoasting
Kerberoasting is an attack technique that abuses the way Kerberos handles service accounts with Service Principal Names (SPNs). An attacker with valid domain credentials can request a service ticket for one of these accounts, extract the ticket, and attempt to crack it offline to recover the account’s password. Once the attacker recovers the password, they inherit all the privileges assigned to that service account, which often includes administrative access to critical systems.
But Kerberoasting is only one way attackers abuse service accounts. Many of the most damaging breaches I have investigated did not involve ticket cracking at all. They started with something far more basic, like hardcoded credentials in a configuration file or a scheduled task.
Hardcoded credentials are still a routine find in both assessment and incident response. They appear in PowerShell scripts, batch files, Java property files, and even compiled DLLs. Sometimes they are left there for convenience, sometimes because the application cannot be configured to use anything else without vendor intervention. In either case, the result is the same. The credentials bypass any vaulting or rotation process and give an attacker a reusable key to the environment.
Interactive logon rights are another persistent weakness. Service accounts should never be able to log on to a workstation or server console, but in many environments exceptions have been granted for years because “it is required by the vendor.” Those exceptions rarely get revisited. I have seen service accounts used over RDP for administration, often with full domain rights, simply because the vendor insisted on it, even when more secure alternatives were available. In many cases the vendor’s own security awareness was poor, and their processes relied on convenience rather than security.
Vendors are a persistent high-risk factor. Even in organisations with SecureLink or a PIM/PAM platform available for remote access, vendor accounts are often allowed to bypass those controls entirely. In theory they could log in through a secure gateway with approvals and time restrictions, but in practice there is little monitoring or alerting on their activity. Approval workflows are rare, and vendor accounts are often left with the ability to log in at any hour from any location.
Third parties may also be given service accounts with broad rights to make remote fixes or install updates, and these accounts are sometimes shared between vendors and customers, meaning the same credentials exist in multiple organisations. Once the work is complete, the account often remains active because nobody took responsibility for disabling it or because it was tied to a service that would stop working. A compromised vendor account in this state can quietly move through the environment long before anyone realises something is wrong.
Privilege creep is the final, quiet risk. A service account may start life with a narrow role, but over time it accumulates rights because it is easier to reuse the account than to create a new one for each system. In many cases, the account ends up with more access than the human administrators, but without any of the monitoring or operational discipline that those administrators are subject to.
These issues may not have the same name recognition as Kerberoasting, but they are just as effective for an attacker. The difference is that they require even less technical skill to exploit. All it takes is access to a shared drive, a Git repository, or a scheduled task configuration, and the attacker can have credentials in hand before the first security alert even fires.
Mitigation Without a Budget
The table below lists practical ways to reduce service account risk, ordered from easiest to most difficult. Many of these can be implemented with little more than time and existing tooling, making them viable even on a small budget. Starting with quick wins and progressing to more involved efforts like enforcing stronger encryption or moving to managed accounts. These will make things more difficult for attackers.
| Level 1 | Action | Effort | Notes |
| 1 | Audit and clean up SPNs | Low | Run setspn -Q */* or use Attribute Editor in ADUC to identify and review risky SPNs. |
| 2 | Limit interactive logon rights | Low | Remove logon rights from service accounts and route access through secure jump hosts or PSM. |
| 3 | Bring vendor accounts under control | Low | Enforce PIM/PAM or SecureLink, limit logins to approved hours, and alert on out-of-hours access. |
| 4 | Watch for privilege creep | Low | Regularly review group memberships and remove unnecessary rights from service accounts. |
| Level 2 | Action | Effort | Notes |
| 1 | Hunt for hardcoded credentials | Medium | Search code repositories, scripts, and shared drives for stored passwords or keys, then rotate and secure them. |
| 2 | Document and review exceptions | Medium | Where operational needs force exceptions (e.g., vendor-required logons), review and validate them regularly. |
| 3 | Implement privileged access alerting and analytics | Medium | Deploy and tune alerts for unusual service account behaviour such as logons outside approved hours, use on unexpected systems, or privilege changes. Requires SIEM integration and cross-team tuning. |
| Level 3 | Action | Effort | Notes |
| 1 | Enforce stronger encryption and passwords | High | Disable RC4 where feasible, enforce AES, and use long random passwords for accounts with SPNs. Microsoft documentation: https://learn.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-overview |
| 2 | Move to Group Managed Service Accounts (gMSAs) or Integrate service accounts into PIM/PAM | High | Choose one. gMSAs automate password rotation and reduce lateral movement risk, but require application support and coordination. Integrating into PIM/PAM like CyberArk or Delinea centralises control and auditing. Microsoft documentation for gMSA: https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview |
Service accounts have been a known risk for decades, yet they still slip through reviews and controls. Attackers know it, which is why techniques like Kerberoasting remain effective. By tackling the easy wins first and planning for the harder changes, organisations can close off some of the quietest and most damaging paths to compromise. Plus these can be reported to the risk committees as exploitable misconfigurations being sorted.
Get in touch