Data/Locales/checks/es/TierZeroChecks.json
|
{ "_family": "TierZeroChecks.json", "ADTIER-001": { "name": { "value": "Auditoría de la cuenta de sincronización de Azure AD Connect (MSOL_)", "status": "machine-draft" }, "description": { "value": "Cuando Azure AD Connect se instala en modo Express, crea una cuenta de dominio llamada MSOL_<hex-aleatorio> y le concede Replicating Directory Changes y Replicating Directory Changes All sobre el contexto de nombres del dominio, es decir, derechos de DCSync. La cuenta es efectivamente de Tier 0, pero de forma predeterminada reside en el contenedor Users predeterminado, tiene una caducidad de contraseña de 10 años y rara vez aparece en las herramientas de enumeración de grupos privilegiados porque obtiene su poder mediante una ACL directa en lugar de la pertenencia a un grupo. El compromiso de esta cuenta equivale funcionalmente a una toma de control del dominio.", "status": "machine-draft" }, "recommendedValue": { "value": "Todas las cuentas MSOL_ inventariadas, con la contraseña rotada en los últimos 180 días, ubicadas en una OU de Tier 0 con derechos de inicio de sesión restringidos, y el propio servidor de AAD Connect endurecido como sistema de Tier 0.", "status": "machine-draft" }, "remediationSteps": { "value": "Localice la cuenta MSOL_: Get-ADUser -Filter {sAMAccountName -like 'MSOL_*'}. Confirme que tiene derechos de DCSync: dsacls 'DC=domain,DC=com' | findstr MSOL_. Muévala a una OU de administración de Tier 0. Rote la contraseña usando las herramientas de AAD Connect (NO la restablezca con las herramientas estándar, use Add-ADSyncADDSConnectorAccount en el módulo de PowerShell ADSync en el servidor de AAD Connect). Aplique una GPO de restricción de inicio de sesión para que la cuenta solo pueda iniciar sesión localmente en el propio servidor de AAD Connect. Trate el host de AAD Connect como Tier 0, restringiendo quién puede acceder a él por RDP o administrarlo.", "status": "machine-draft" } }, "ADTIER-002": { "name": { "value": "Cuentas de servicio de software de copia de seguridad en grupos privilegiados", "status": "machine-draft" }, "description": { "value": "El software de copia de seguridad (Veeam, Commvault, Rubrik, Cohesity, NAKIVO, Backup Exec, Vembu, Acronis) suele solicitar una cuenta de servicio con permisos muy elevados. La documentación a menudo sugiere Domain Admin para facilitar la configuración, y muchos administradores lo aceptan. Una vez que un atacante compromete el servidor de copia de seguridad (un vector frecuente de acceso inicial de ransomware), hereda Domain Admin a través de la cuenta de servicio. Esta es la ruta de escalada de ransomware número 1 en los datos de respuesta a incidentes de 2023 a 2025.", "status": "machine-draft" }, "recommendedValue": { "value": "Ninguna cuenta de servicio de software de copia de seguridad es miembro de Domain Admins, Enterprise Admins, Schema Admins o Backup Operators. Use cuentas de mínimo privilegio documentadas por el proveedor y credenciales de copia de seguridad aisladas.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifique el producto de copia de seguridad en uso y siga su guía de mínimo privilegio (Veeam: solo administrador local del servidor de copia de seguridad + cuenta de AD con lectura de objetos; Rubrik: entidad de servicio dedicada en un rol solo de nube; etc.). Elimine la cuenta de copia de seguridad de Domain Admins. Migre a una gMSA donde esté soportado. Ubique el servidor de copia de seguridad en una OU de Tier 1 con derechos de inicio de sesión restringidos. Si un flujo de trabajo específico requiere realmente DA completo, documéntelo y aísle esa parte de la copia de seguridad en su propia cuenta, separada de la principal.", "status": "machine-draft" } }, "ADTIER-003": { "name": { "value": "Cuentas de servicio de hipervisor / virtualización en grupos privilegiados", "status": "machine-draft" }, "description": { "value": "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.", "status": "machine-draft" }, "recommendedValue": { "value": "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.", "status": "machine-draft" }, "remediationSteps": { "value": "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.", "status": "machine-draft" } }, "ADTIER-004": { "name": { "value": "Cuentas de servicio de gestión de configuración en grupos privilegiados", "status": "machine-draft" }, "description": { "value": "Las plataformas de gestión de configuración (SCCM/MECM, Intune Connector, Jamf, KACE, Lansweeper, ManageEngine, Ivanti, BigFix) distribuyen software a cada endpoint por definición, por lo que ya son una plataforma privilegiada de movimiento lateral. SCCM en particular tiene primitivas de abuso bien conocidas (exposición de la Network Access Account, coacción NTLM al servidor de sitio, client push). Una cuenta de servicio de gestión de configuración en Domain Admins otorga a un atacante que llegue a cualquier endpoint gestionado las llaves del dominio.", "status": "machine-draft" }, "recommendedValue": { "value": "Las cuentas de servicio de gestión de configuración están acotadas a sus derechos mínimos documentados y nunca están en Domain Admins / Enterprise Admins. La Network Access Account de SCCM es una identidad dedicada no privilegiada.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifique el producto de gestión de configuración y revise los derechos de la cuenta de servicio. Para SCCM: asegúrese de que la Network Access Account no sea privilegiada (NO un Domain Admin); asegúrese de que la cuenta de equipo del servidor de sitio no sea un Domain Admin; revise las cuentas de servicio de la jerarquía en busca de mínimo privilegio. Mueva los servidores de sitio y los puntos de gestión a una OU de Tier 0 con inicios de sesión restringidos.", "status": "machine-draft" } }, "ADTIER-005": { "name": { "value": "Cuentas de servicio de SQL / base de datos en grupos privilegiados", "status": "machine-draft" }, "description": { "value": "Las cuentas de servicio de SQL Server / MySQL / PostgreSQL en Domain Admins son comunes en entornos donde el equipo de DBA instaló SQL con la guía predeterminada 'Usar cuenta de AD existente' y eligió una cuenta de administrador por comodidad. Una vez que el servidor de base de datos es accesible en la red, el compromiso de una credencial de SQL o una vulnerabilidad de SQL Server otorga al atacante Domain Admin directamente.", "status": "machine-draft" }, "recommendedValue": { "value": "Las cuentas de servicio de base de datos se ejecutan como gMSA o identidades de servicio dedicadas sin pertenencia a grupos privilegiados.", "status": "machine-draft" }, "remediationSteps": { "value": "Migre las cuentas de servicio de SQL a gMSA donde esté soportado. Para las cuentas que deban seguir basándose en usuario, elimine la pertenencia a grupos privilegiados y conceda únicamente los derechos locales que requiere el motor de base de datos (Iniciar sesión como servicio, Omitir la comprobación de recorrido, Ajustar las cuotas de memoria para un proceso, consulte la documentación de Microsoft para conocer los derechos específicos).", "status": "machine-draft" } }, "ADTIER-006": { "name": { "value": "Cuentas de administración de Tier 0 fuera de una OU de Tier 0 dedicada", "status": "machine-draft" }, "description": { "value": "Si sus Domain Admins residen en la misma OU que los usuarios normales, cada GPO dirigida a usuarios (scripts de inicio de sesión, directiva de navegador, unidades asignadas, etc.) también se aplica a sus Domain Admins, lo que significa que cualquiera que pueda editar esas GPO puede ejecutar código como Domain Admin en el siguiente inicio de sesión. El modelo por niveles de Microsoft recomienda una OU de administración de Tier 0 dedicada con autoría de GPO restringida y derechos de inicio de sesión restringidos.", "status": "machine-draft" }, "recommendedValue": { "value": "Todos los miembros de Domain Admins, Enterprise Admins y Schema Admins están en una OU de Tier 0 dedicada (por lo general OU=Tier-0,OU=Admin) con autoría de GPO restringida.", "status": "machine-draft" }, "remediationSteps": { "value": "Cree OU=Tier-0,OU=Admin si no existe. Mueva a ella a todos los miembros de Domain/Enterprise/Schema Admins. Restrinja la autoría de GPO en esa OU (solo los propios administradores de Tier 0). Aplique una GPO de restricción de inicio de sesión dedicada para que las cuentas de Tier 0 solo puedan iniciar sesión en hosts de Tier 0. Bloquee la herencia en la OU.", "status": "machine-draft" } }, "ADTIER-007": { "name": { "value": "Cuentas de servicio con derechos de inicio de sesión interactivo a través de un grupo privilegiado", "status": "machine-draft" }, "description": { "value": "Las cuentas de servicio que son miembros de Domain Admins (o de cualquier grupo al que se le conceda 'Permitir el inicio de sesión local' a través de la pertenencia predeterminada a un grupo privilegiado) pueden usarse de forma interactiva. A los atacantes les encanta esto: capturan la contraseña de una cuenta de servicio (Kerberoasting, registro, scripts en SYSVOL), la usan de forma interactiva en una estación de trabajo, vuelcan LSASS y pivotan. Las cuentas de servicio no deberían poder iniciar sesión interactivamente en nada más que en el host al que sirven.", "status": "machine-draft" }, "recommendedValue": { "value": "A las cuentas de servicio (heurística: sAMAccountName empieza por svc/sa/service o tiene un SPN + sin inicio de sesión interactivo reciente) se les deniega explícitamente 'Permitir el inicio de sesión local' y 'Permitir el inicio de sesión a través de Servicios de Escritorio remoto' mediante la Directiva de controladores de dominio predeterminada y una GPO de restricción de inicio de sesión dedicada de Tier 1/Tier 2.", "status": "machine-draft" }, "remediationSteps": { "value": "Identifique las cuentas de servicio (que portan SPN, por convención de nomenclatura o por inventario de negocio). Aplique una GPO de Directiva de dominio predeterminada: Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Asignación de derechos de usuario > 'Denegar el inicio de sesión local' = <grupo-de-cuentas-de-servicio>. Añada las mismas cuentas a 'Denegar el inicio de sesión a través de Servicios de Escritorio remoto'. Añádalas a Protected Users donde esté soportado (Server 2012 R2 y posteriores).", "status": "machine-draft" } } } |