Service accounts — the non-human accounts used by applications, scheduled tasks, and services to authenticate and perform operations — represent one of the most overlooked attack surfaces in Active Directory environments. Unlike human accounts, service accounts typically have no MFA, their passwords never expire (or are changed rarely), they often have broad privileges granted out of convenience, and they are frequently shared across multiple services without documentation of who or what depends on them.
For attackers with a foothold in an Active Directory domain, service accounts are a primary escalation path. Understanding how to reduce this attack surface is essential for any organization running Windows infrastructure.
The Service Account Problem in Practice
The typical enterprise has accumulated service accounts over years or decades of application deployments. Each time an application was installed, someone created a service account, granted it the necessary permissions (often "Domain Admins" because it was easier than figuring out the minimum required permissions), set a password that would never expire, and moved on. Nobody documented it. Nobody reviewed it. The application was replaced years later but the service account was never deleted.
Discovery of this sprawl is frequently surprising. Service accounts proliferate quietly and are routinely undercounted — CyberArk's research finds privileged accounts typically run three to four times an organization's headcount, with roughly two of every three either unknown or unmanaged (CyberArk, Privileged Account Security Survey). Tools like BloodHound (the community edition) and Microsoft's ADExplorer can enumerate all accounts with Service Principal Names (SPNs) — the marker that distinguishes service accounts in Kerberos authentication.
Kerberoasting: The Key Attack
Kerberoasting is an offline password cracking attack that specifically targets service accounts. Any authenticated domain user can request a Kerberos service ticket for any SPN-registered account. That service ticket is encrypted with the service account's password hash. The attacker requests the ticket and takes it offline to crack using tools like Hashcat, without generating any alerts on the target system.
Service accounts with weak passwords (dictionary words, company name variations, short passwords) are cracked within minutes. The attack has no lockout protection because the cracking happens offline against the captured hash.
Mitigation has two components: strong, long (25+ character) passwords for all service accounts (or better, migration to managed accounts with automatic rotation), and configuring service accounts to use AES-256 Kerberos encryption rather than RC4-HMAC. RC4 encryption produces a more crackable hash format; AES significantly increases the computational cost of offline cracking.
Managed Service Accounts and Group Managed Service Accounts
Microsoft introduced Managed Service Accounts (MSA) in Windows Server 2008 R2 and Group Managed Service Accounts (gMSA) in Windows Server 2012 specifically to address the service account management problem. Both types use automatically managed passwords that are 240 bytes long, randomly generated, and rotated automatically by Active Directory — eliminating the human management burden and the Kerberoasting vulnerability simultaneously.
MSAs are bound to a single server and automatically manage their own password. gMSAs extend this to scenarios where the service runs on multiple servers (load-balanced applications, clustered services), with the password managed by the Key Distribution Service (KDS) and distributed only to authorized servers.
The migration path from a traditional service account to a gMSA involves: creating a KDS root key if one does not exist, creating the gMSA with New-ADServiceAccount, granting the target servers permission to retrieve the gMSA password, and reconfiguring the service to use the gMSA principal. Not all applications support gMSAs — particularly older third-party applications that require an explicit password to be entered in a configuration UI.
Service Account Naming Conventions and Documentation
A naming convention for service accounts is not just organizational hygiene — it is a security control. When every service account follows the pattern svc-[application]-[environment] (e.g., svc-sqlbackup-prod), anomalous accounts that do not follow the pattern are immediately suspicious. Undocumented accounts, accounts with human-like names, and accounts whose purpose cannot be determined are red flags for either legacy sprawl or attacker-created persistence accounts.
Every service account should have documented: what application or service it supports, what systems it can log onto, what privileges it has and why, the account owner (a human who is responsible for it), and a review date. Store this in your ITSM or CMDB, not in a spreadsheet that nobody updates.
Microsoft LAPS for Local Administrator Accounts
Windows Local Administrator Password Solution (Windows LAPS) is now a native, built-in Windows feature — delivered to existing systems (Windows 11 22H2/21H2 and Windows 10, plus Windows Server 2022/2019) through the April 11, 2023 cumulative update, and built in natively from Windows 11 23H2 and Windows Server 2025 onward (Microsoft Learn, "Windows LAPS overview"). It solves the lateral movement problem created by shared local administrator passwords. When every workstation has the same local Administrator password, a single credential dump exposes the entire fleet. LAPS generates a unique, random password for the local Administrator account on each machine and stores it in Active Directory (or Entra ID for cloud-joined devices), retrievable only by authorized administrators.
Monitoring Service Account Anomalies
Service accounts have predictable behavior: they authenticate at regular intervals, from specific source systems, to specific target systems, using specific protocols. Deviations from this baseline are high-fidelity indicators of compromise. Configure your SIEM to alert on: service account logons from interactive sessions (a service account logging in to a workstation interactively is almost always an attacker), logons from systems not in the account's authorized source list, logons at unusual hours outside the service's operational window, and failed authentication attempts against systems the account does not normally access.
These alerts require the behavioral baseline established during your service account discovery and documentation phase — which is another reason that documentation is a security control, not just an administrative exercise. For assistance with Active Directory security assessment including service account enumeration and gMSA migration planning, contact Fortress MSSP or review our network penetration testing service, which includes Active Directory attack path analysis.