ADPRIV-024: Cuentas de servicio en grupos privilegiados
- 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
Las cuentas de servicio en grupos privilegiados presentan un riesgo elevado porque suelen tener contraseñas que no caducan, se comparten entre administradores, pueden almacenarse en scripts o archivos de configuración y se ejecutan en múltiples servidores donde las credenciales pueden recolectarse
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
Ninguna cuenta de servicio en grupos privilegiados. Las cuentas de servicio deben usar permisos delegados restringidos al acceso mínimo requerido
Remediación
Identifique las cuentas de servicio en grupos privilegiados revisando todos los miembros y comprobando las cuentas usadas como identidades de inicio de sesión de servicios. Elimine las cuentas de servicio de los grupos privilegiados y conceda únicamente los permisos específicos necesarios mediante delegación. Migre a cuentas de servicio administradas de grupo (gMSA) siempre que sea posible
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