ADPRIV-024: Service Accounts in Privileged Groups
- Plataforma
- Active Directory
- Categoría
- AD Privileged Account Security
- Severidad
- High
- Pilar de Zero Trust
- Identity (peso 3)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
The check resolves every Microsoft-protected privileged group (Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators, Replicator, plus the operational groups DnsAdmins and Group Policy Creator Owners) by well-known SID, then recursively expands membership including nested groups, foreign security principals, and SID history references. For every resolved user object the check pulls: - servicePrincipalName (any value strongly suggests a service identity and makes the account Kerberoastable) - userAccountControl flags, in particular DONT_EXPIRE_PASSWORD (0x10000), PASSWORD_NOTREQD (0x20), TRUSTED_FOR_DELEGATION (0x80000), TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000), and DONT_REQUIRE_PREAUTH (0x400000) - pwdLastSet (a value older than the documented rotation cadence is a service-account tell) - description, sAMAccountName, and displayName (matched against svc, srv, service, sql, iis, sccm, exchange, backup, app, batch, task naming conventions) - msDS-KeyVersionNumber and msDS-SupportedEncryptionTypes (RC4 only is a Kerberoasting accelerator) - objectClass of msDS-GroupManagedServiceAccount or msDS-ManagedServiceAccount (a gMSA or sMSA in a privileged group is still flagged because the group placement, not the account type, is the misconfiguration) - Membership in Protected Users (service accounts cannot be members of Protected Users without breaking RC4 and unconstrained delegation, so absence is expected but the placement in a privileged group remains a finding) Any principal that matches one or more service-account heuristics and is reachable from a privileged group, directly or through nesting, is emitted as a finding with the full nesting path so the analyst can identify both the account and the group chain that grants it Tier 0 reach.
Por qué importa
Service accounts combine three properties that no human admin account should have. First, their password is usually static, often set when the application was installed and never rotated, because rotating it breaks the service. Second, the password is frequently embedded in plaintext, in a scheduled task XML on SYSVOL, in an unattended install file, in a configuration management database, or in a Group Policy Preference (the original CVE-2014-1812 cpassword problem). Third, the account interactively or batch-logs on to many member servers, so its NT hash and Kerberos TGT are cached in LSASS on every box where the service runs. When such an account is also a member of Domain Admins or any other privileged group, every single one of those properties becomes a direct path to full domain compromise. A Kerberoast against a Domain Admin service account requires only an LDAP read and a KRB_TGS_REQ from any authenticated user, then an offline crack of the returned RC4 (or AES) ticket; if the password is human-readable, the crack completes in seconds on commodity GPUs. A LSASS dump on any member server where the service runs hands the attacker the full plaintext via WDigest or the NT hash for pass-the-hash. A single compromised application server with a Domain Admin service identity is a complete domain breach. Mandiant and Microsoft Incident Response repeatedly document this pattern as the root cause of human-operated ransomware events: Ryuk, Conti, BlackCat, LockBit, and Royal affiliates all rely on finding an over-permissioned service account as their pivot from initial access to domain dominance.
Ruta de ataque
1. Reconnaissance: from any authenticated user context the attacker runs an LDAP query for accounts that have a servicePrincipalName and are members of a privileged group. Tools: Get-ADUser -LDAPFilter "(&(objectClass=user)(servicePrincipalName=*)(adminCount=1))", GetUserSPNs.py, Rubeus kerberoast /stats, or BloodHound (the "Kerberoastable users with most privileges" pre-built query returns exactly this set). 2. Kerberoasting: the attacker requests a TGS for the service account (Rubeus kerberoast /user:svc-sql-prod /nowrap, GetUserSPNs.py -request, or Invoke-Kerberoast). The KDC returns a ticket encrypted with the service account password hash. No exploit, no elevated privilege, no event log entry beyond a routine 4769 with ticket encryption type 0x17 (RC4) or 0x12 (AES). 3. Offline cracking: the attacker feeds the ticket to hashcat (-m 13100 for RC4, -m 19700 for AES256) against a wordlist or mask. A human-chosen service password (Summer2024!, CompanyName2023, P@ssw0rd123) cracks in seconds; a 14-character random password is impractical to crack and is the only defence against this step. 4. Direct logon: with the plaintext recovered, the attacker authenticates as the service account using runas /netonly, PsExec -u, WMI, WinRM, or any Windows RPC that accepts cleartext. Because the account is in Domain Admins, every domain-joined system accepts the logon. 5. Alternative path, LSASS theft: instead of cracking, the attacker compromises any member server where the service runs (an application server, SQL host, web front end, backup server), elevates to local SYSTEM, and dumps LSASS (mimikatz sekurlsa::logonpasswords, comsvcs.dll MiniDump, nanodump, pypykatz). The service account TGT, NT hash, or plaintext (when WDigest is enabled or the service runs interactively) is recovered and reused via pass-the-hash, pass-the-ticket, or overpass-the-hash to authenticate to any DC. 6. DCSync and persistence: authenticated as a Domain Admin service identity the attacker runs mimikatz lsadump::dcsync /user:krbtgt or impacket-secretsdump, extracts the krbtgt hash, forges Golden Tickets, and establishes long-term persistence independent of the original service account. 7. Optional unconstrained-delegation pivot: if the service account is marked TRUSTED_FOR_DELEGATION (common for legacy IIS, SQL Linked Servers, SharePoint) the attacker coerces a DC to authenticate to the host via PetitPotam, Printerbug, or DFSCoerce, captures the DC TGT in LSASS, and immediately DCSyncs without ever cracking a password.
Cómo lo evalúa Guerrilla
Guerrilla binds to a writable DC, enumerates the full list of Microsoft-protected privileged groups by well-known relative ID (512 Domain Admins, 519 Enterprise Admins, 518 Schema Admins, 544 Administrators, 548 Account Operators, 549 Server Operators, 551 Backup Operators, 550 Print Operators, 552 Replicator) plus operational groups looked up by name (DnsAdmins, Group Policy Creator Owners, Cert Publishers, Exchange Trusted Subsystem). Each group is expanded recursively in PowerShell so nested groups, foreign security principals, and tombstoned references are surfaced rather than silently dropped by Get-ADGroupMember -Recursive. For every user-class member the check issues a single LDAP query for sAMAccountName, distinguishedName, servicePrincipalName, userAccountControl, pwdLastSet, lastLogonTimestamp, description, msDS-SupportedEncryptionTypes, msDS-KeyVersionNumber, memberOf, and objectClass. A composite heuristic score is computed: SPN present (+3), name matches service pattern (+2), DONT_EXPIRE_PASSWORD set (+2), pwdLastSet older than 365 days (+2), RC4-only encryption types (+1), TRUSTED_FOR_DELEGATION set (+3). Any account scoring above the threshold and present in a privileged group is emitted as a FAIL, with the full nesting path, the contributing flags, and the matched heuristic so the analyst can both confirm the finding and prioritise remediation. The check is LDAP-only and does not require RSAT, WinRM, or any agent on the DC.
Valor recomendado
No service accounts in privileged groups. Service accounts should use delegated permissions scoped to minimum required access
Remediación
Identify service accounts in privileged groups by reviewing all members and checking for accounts used as service logon identities. Remove service accounts from privileged groups and grant only the specific permissions needed via delegation. Migrate to Group Managed Service Accounts (gMSA) where possible
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
| known-bad | FAIL |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- AC-6(1), AC-6(5)
- ANSSI
- R40
- CIS AD Benchmark
- 4.9.1
- MITRE ATT&CK
- T1078.002, T1078