ADTIER-003: Cuentas de servicio de hipervisor / virtualización en grupos privilegiados
- Plataforma
- Active Directory
- Categoría
- Tier-0 Hygiene & Hybrid Identity Surface
- Severidad
- High
- Pilar de Zero Trust
- Identity (peso 2)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
Las integraciones de vCenter / Hyper-V / SCVMM / Citrix / Nutanix con AD suelen usar una cuenta de servicio configurada durante la instalación. Si esa cuenta es un Domain Admin, entonces el compromiso del plano de gestión del hipervisor (o de la base de datos SSO del host) se propaga a AD. El hipervisor ya es conceptualmente de Tier 0; su identidad de AD debería coincidir con ello.
Por qué importa
A hypervisor that runs your domain controllers can read DC virtual disks, snapshot DC memory (which contains the krbtgt key and LSASS secrets), and clone or migrate a DC into an attacker-controlled lab for offline analysis. That makes the hypervisor a peer of the domain controller in the Tier-0 trust model. Adding Domain Admin rights to the AD account that vCenter or SCVMM logs in with collapses the relationship in the wrong direction: now an attacker who compromises any vCenter appliance, any SCVMM management server, the vCenter SSO embedded VMDIR (which stores credentials), or a backup of any of those, can read the service-account credential and authenticate to AD as Domain Admin without ever touching a domain controller directly. Public incidents involving Karakurt, Conti, BlackCat, and APT groups have repeatedly shown vCenter as the path of least resistance into AD: the attacker lands on an ESXi host through CVE-2021-21972 or a stolen vSphere credential, pivots to vCenter, dumps the SSO database, and uses the discovered Domain Admin service account to push ransomware to every joined host. The blast radius is the entire forest plus every workload running on the hypervisor.
Ruta de ataque
1. Initial access on the virtualization plane: the attacker exploits a vCenter vulnerability (for example CVE-2021-21972 unauthenticated RCE in the vSphere Client, CVE-2021-21985 vCenter VAPI default plugin RCE, or CVE-2024-37079 vCenter VPXD RCE), or reaches an SCVMM or Prism management VM through stolen RDP / SSH credentials, or compromises a backup of any of those. 2. Credential extraction: on a vCenter appliance the attacker dumps the vmware-vmdir database (data.mdb) and the dir-cli / vdcadmintool keys, or reads the AD identity-source secrets from /storage/db/vmware-vmdir. On SCVMM, the RunAs accounts live in the SCVMM database encrypted with the SCVMM key (which is also on the same server). On Hyper-V the service account credential is in the cluster registry hive. 3. Credential replay: the recovered credential authenticates to AD. Because the service account is in Domain Admins, the attacker now has krbtgt-equivalent reach: DCSync via secretsdump.py or mimikatz lsadump::dcsync, Golden Ticket forging, GPO modification on the Domain Controllers OU, or direct RDP to any DC. 4. Lateral cascade through the hypervisor: with Domain Admin in hand, the attacker pushes encryption payloads or persistence to every domain-joined host through SCCM, GPO, or PsExec. Because vCenter itself is now controlled, every guest VM can also be powered off, snapshotted, or encrypted at the VMDK layer, defeating in-guest EDR. 5. Persistence: the attacker creates a parallel service account with the same Tier-0 group membership, or adds an ACE to AdminSDHolder so SDProp re-stamps the right onto every protected principal hourly (see ADACL-001). Removing the original vCenter service account does not evict them.
Cómo lo evalúa Guerrilla
Guerrilla queries Active Directory through LDAP using the supplied or implicit DC connection. It runs (objectClass=user) with a filter that matches the hypervisor naming and SPN patterns described above, then for each hit it expands tokenGroups (constructed attribute) to enumerate every group the account holds transitively, including nested membership. The expanded SID set is intersected with the protected-group SID list (well-known RIDs 512, 519, 518, 544, 548, 549, 550, 551, 552, 516, 498, plus key admin and cert publisher SIDs). Findings include the candidate accounts samAccountName, distinguishedName, the matching pattern that identified it, the protected groups it belongs to (direct or nested), and whether the membership is direct or via a nested group. The check also enumerates non-default ACEs on the Domain Root, AdminSDHolder, and OU=Domain Controllers granted to the candidate, since group membership is not the only way to grant Tier-0 reach. Because the check uses tokenGroups it sees nested membership that a flat memberOf read would miss (the classic Account Operators inside Domain Admins anti-pattern).
Valor recomendado
Las cuentas de servicio de hipervisor tienen únicamente los derechos documentados por el proveedor (por lo general, lectura para el inventario + escrituras específicas en OU si se usa la integración VM-AD). No están en Domain Admins.
Remediación
Revise la cuenta de servicio de AD de cada producto de hipervisor. Aplique la guía de mínimo privilegio del proveedor. Para vCenter: use el patrón documentado de origen de identidad SSO en lugar de mapear un Domain Admin. Para Hyper-V/SCVMM: acote los derechos de la cuenta de servicio a las OU que alojan las cuentas de equipo de las VM. Trate el host de gestión del hipervisor como Tier 0 en su modelo administrativo.
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
- CIS AD Benchmark
- 8.2.2
- MITRE ATT&CK
- T1078.002