For many organizations, Active Directory (AD) service accounts are quiet afterthoughts, persisting in the background long after their original purpose has been forgotten. To make matters worse, these orphaned service accounts (created for legacy applications, scheduled tasks, automation scripts, or test environments) are often left active with non-expiring or stale passwords.
It’s no surprise that AD service accounts often evade routine security oversight. Security teams, overwhelmed by daily demands and lingering technical debt, often overlook service accounts (unlinked to individual users and rarely scrutinized) allowing them to quietly fade into the background. However, this obscurity makes them prime targets for attackers seeking stealthy ways into the network. And left unchecked, forgotten service accounts can serve as silent gateways for attack paths and lateral movement across enterprise environments. In this article, we’ll examine the risks that forgotten AD service accounts pose and how you can reduce your exposure.
As the old cybersecurity adage goes, you can’t protect what you can’t see. This holds especially true for AD service accounts. Gaining visibility is the first step to securing them, but orphaned or unmonitored service accounts often operate silently in the background, escaping notice and oversight. These forgotten service accounts are especially problematic, as they’ve played a central role in some of the most damaging breaches in recent years. In the case of the 2020 SolarWinds attack, compromised service accounts were instrumental in helping threat actors navigate targeted environments and access sensitive systems.
Once attackers gain a foothold through phishing or social engineering, their next move typically involves hunting for service accounts to exploit and using them to elevate privileges and move laterally through the network. Fortunately, administrators have a variety of techniques available to identify and uncover forgotten or unmonitored AD service accounts:
In early 2024, security researchers discovered a botnet of over 130,000 devices targeting Microsoft 365 service accounts in a massive password-spraying campaign. The attackers bypassed multi-factor authentication (MFA) by abusing basic authentication, an outdated authentication scheme still enabled in many environments. Because these attacks didn’t trigger typical security alerts, many organizations were unaware they were compromised. This example is just one of many that highlight the importance of securing service accounts and eliminating legacy authentication mechanisms.
Even service accounts that were initially created with minimal permissions can become dangerous over time. This scenario, known as privilege creep, occurs when accounts accumulate permissions due to system upgrades, role changes, or nested group memberships. What starts as a low-risk utility account can quietly evolve into a high-impact threat, capable of accessing critical systems without anyone realizing it.
Security teams should therefore review service account roles and permissions on a regular basis; if access isn’t actively managed, even well-intentioned configurations can drift into risky territory.
Effective AD service account management requires a deliberate, disciplined approach, as these logins are high-value targets that require proper handling. Here are some best practices that form the backbone of a strong AD service account security strategy:
Grant only the permissions absolutely necessary for each account to function. Avoid placing service accounts in broad or powerful groups like Domain Admins.
Managed service accounts (MSAs) and group managed service accounts (gMSAs) provide automatic password rotation and cannot be used for interactive logins—this makes them safer than traditional user accounts and easier to maintain securely.
Use built-in AD auditing or third-party tools to track account usage, logins, and permission changes. Watch for signs of misuse or misconfiguration.
Long, complex passphrases should be the standard. Avoid reused or hard-coded credentials. Passwords should be rotated regularly or managed through automated tooling.
Service accounts should not allow interactive logins. Assign a unique account to each service or application to contain any potential compromise.
If an account is no longer in use, it should be disabled immediately. Periodic PowerShell queries can help identify stale or inactive accounts.
Create distinct service accounts for different functions like application services, database access, network tasks. This compartmentalization reduces the impact radius of any one compromise.
Although service accounts should not support interactive logins, some instances may require exceptions. For these edge cases, enable MFA to increase security.
Grouping service accounts in specific organizational units (OUs) simplifies policy enforcement and auditing. It also makes it easier to spot anomalies and maintain consistency.
As environments evolve, revisit what each service account is used for and whether it still needs the same level of access. Adjust or retire accounts accordingly.
Reference: https://thehackernews.com/2025/06/are-forgotten-ad-service-accounts.html