Cuentas privilegiadas Active Directory: Protected Users, delegación y brechas en cuentas de servicio

Qué es la protección de las cuentas privilegiadas de Active Directory (Protected Users y delegación)

Las cuentas de Domain Admins, Enterprise Admins y otras cuentas Tier 0 son las que un atacante necesita para comprometer completamente un dominio. En el caso de las cuentas privilegiadas de Active Directory, tres controles nativos e independientes hacen la mayor parte del trabajo real de protección: la pertenencia al grupo de seguridad Protected Users, el indicador de delegación "esta cuenta es confidencial y no se puede delegar", y la regla básica de higiene según la cual las cuentas de servicio no deben estar en grupos privilegiados. Además, el atributo SID History — pensado para migraciones de dominio — puede otorgar silenciosamente acceso privilegiado si nunca se audita.

Nada de esto es exótico. Son funciones nativas de AD, listas para usar. La brecha que cubre este artículo no es un parche faltante ni un zero-day: son simplemente estos controles que no están activados para las cuentas que los necesitan, razón por la cual aparece constantemente como uno de los principales hallazgos en las evaluaciones de seguridad de Active Directory. Cada brecha descrita a continuación es explotable de forma independiente, y ninguna requiere herramientas residentes en memoria ni inyección de procesos: son errores de configuración a nivel de atributo, visibles para cualquiera que consulte el directorio de la forma correcta.

Cómo funciona

Protected Users: creado pero sin usar

El grupo de seguridad global Protected Users, introducido en Windows Server 2012 R2, aplica protecciones no configurables a cualquier cuenta añadida a él. Según la documentación de Microsoft sobre Protected Users, los miembros no pueden autenticarse con NTLM, no pueden usar DES ni RC4 para la preautenticación Kerberos, no se les puede delegar mediante delegación restringida o no restringida, y obtienen un tiempo de vida fijo de 4 horas para el TGT de Kerberos, sin renovación. La sola pertenencia al grupo hace el trabajo — no hay ninguna política que se pueda configurar mal una vez que la cuenta está en el grupo.

El problema es que la mayoría de los entornos nunca lo pueblan. Las cuentas de Domain Admins y otras cuentas Tier 0 siguen autenticándose con protocolos heredados y almacenando credenciales en caché en LSASS exactamente igual que si el grupo no existiera, simplemente porque nadie las añadió.

El indicador "confidencial y no se puede delegar"

Aparte de Protected Users, cada cuenta de AD tiene un bit userAccountControl — NOT_DELEGATED (0x100000 / 1048576) — expuesto en la interfaz gráfica como "Esta cuenta es confidencial y no se puede delegar". Cuando está activado, el ticket Kerberos de la cuenta no se puede reenviar a un servicio configurado para delegación, incluso si ese servicio es de confianza para delegación por lo demás. Según la evaluación de seguridad de Microsoft Defender for Identity para este control, dejarlo sin activar en cuentas privilegiadas significa que un servicio comprometido o malicioso de confianza para delegación puede solicitar y reutilizar el ticket de esa cuenta para suplantarla en otro punto de la red — una vía de escalada independiente de si la cuenta está en Protected Users.

Exposición a la delegación en la propia cuenta

Más allá del indicador confidencial, una cuenta puede llevar directamente configuración de delegación: TRUSTED_FOR_DELEGATION (no restringida), msDS-AllowedToDelegateTo (restringida), o delegación restringida basada en recursos mediante msDS-AllowedToActOnBehalfOfOtherIdentity. Cualquiera de estas en una cuenta Tier 0 significa que un servicio comprometido de confianza para delegación puede solicitar tickets como esa cuenta. Cubrimos la explotación de estos mecanismos en profundidad en Ataques de delegación Kerberos: de no restringida a abuso de RBCD — el punto de este artículo es más concreto: una cuenta confidencial nunca debería ser un objetivo de delegación, sin importar la técnica de ataque utilizada contra ella.

Cuentas de servicio dentro de grupos privilegiados

Una cuenta de servicio con un SPN (Service Principal Name) es kerberoasteable por diseño — cualquier usuario de dominio autenticado puede solicitar un ticket de servicio para ella e intentar crackear el ticket sin conexión (véase nuestra guía de Kerberoasting para esa cadena de ataque). Ese riesgo es tolerable cuando la cuenta solo tiene acceso al servicio que ejecuta. Deja de serlo en el momento en que la cuenta también es miembro de Domain Admins o Enterprise Admins.

Las indicaciones de Microsoft sobre reducir la pertenencia en grupos administrativos altamente privilegiados son explícitas: los grupos privilegiados deben mantenerse vacíos o limitados a un pequeño número de administradores responsables, y las cuentas de servicio deben recibir permisos delegados y acotados en lugar de derechos generales de Domain Admin. Una cuenta de servicio en Domain Admins combina una contraseña crackeable con privilegio a nivel de dominio — cualquiera que pueda consultar SPN ya tiene una vía para intentar comprometer el dominio por completo.

SID History: la cuarta vía silenciosa

El atributo sIDHistory existe para preservar el acceso durante migraciones entre dominios — un usuario migrado conserva el SID de su cuenta anterior, añadido a su token, para que los permisos existentes sigan funcionando. Según MITRE ATT&CK T1134.005, un atacante con derechos equivalentes a Domain Admin (o capacidad de DCSync) puede insertar un SID privilegiado obtenido o conocido — como el de Enterprise Admins — en el SID History de una cuenta de bajo privilegio. El token de esa cuenta pasa entonces a llevar derechos de Enterprise Admin sin aparecer nunca como miembro del grupo Enterprise Admins, lo cual es precisamente lo que lo hace peligroso: una revisión de pertenencia a grupos no lo detecta en absoluto.

Por qué los atacantes encadenan estas brechas

Ninguna de estas cuatro brechas necesita estar aislada para ser útil a un atacante, y en la práctica rara vez lo está. Una cuenta privilegiada sin el indicador confidencial es un objetivo de delegación viable; esa misma cuenta fuera de Protected Users todavía puede autenticarse con NTLM, así que un atacante con un hash retransmitido ni siquiera necesita Kerberos. Si ese mismo entorno también tiene una cuenta de servicio dentro de Domain Admins, un atacante que hace Kerberoasting y crackea su contraseña obtiene una segunda vía, independiente, hacia el mismo nivel de privilegio — sin necesidad de abusar de la delegación. Y el SID History ofrece una opción de persistencia que sobrevive por completo a una rotación de credenciales en la cuenta privilegiada original, ya que el SID inyectado viaja sobre una identidad completamente distinta y de bajo privilegio.

Esto también es lo que distingue esta brecha de las cuentas privilegiadas obsoletas (credenciales inactivas que nadie deshabilitó — véase Cuentas privilegiadas obsoletas: riesgo oculto en Active Directory) y de la deriva de acceso privilegiado (derechos que vuelven a aparecer tras una limpieza — véase Deriva del acceso privilegiado en Active Directory). Esos casos tratan de cuentas que ya no deberían tener acceso, o de acceso que ha vuelto a filtrarse. Este trata de cuentas que hoy están correctamente privilegiadas, pero sin las protecciones a nivel de atributo que Active Directory ya incluye para contenerlas.

Detección

Consulte el directorio directamente para cada brecha — no se necesita ninguna herramienta de terceros.

# Cuentas privilegiadas que NO están en Protected Users
$protected = (Get-ADGroupMember "Protected Users" -Recursive).SamAccountName
Get-ADGroupMember "Domain Admins" -Recursive |
    Where-Object { $_.SamAccountName -notin $protected } |
    Select-Object SamAccountName

# Cuentas privilegiadas sin el indicador "confidencial, no se puede delegar" (bit 0x100000)
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties userAccountControl |
    Where-Object { -not ($_.userAccountControl -band 1048576) } |
    Select-Object SamAccountName

# Cuentas todavía de confianza para delegación no restringida/restringida
Get-ADUser -Filter 'TrustedForDelegation -eq $true -or msDS-AllowedToDelegateTo -like "*"' `
    -Properties TrustedForDelegation, msDS-AllowedToDelegateTo

# Cuentas de servicio (con SPN) dentro de grupos privilegiados
Get-ADGroupMember "Domain Admins","Enterprise Admins" -Recursive |
    Get-ADUser -Properties ServicePrincipalNames |
    Where-Object { $_.ServicePrincipalNames.Count -gt 0 }

# Cualquier cuenta que lleve SID History
Get-ADUser -Filter * -Properties SIDHistory |
    Where-Object { $_.SIDHistory.Count -gt 0 } |
    Select-Object SamAccountName, SIDHistory

Para una visión más amplia de qué ID de eventos importan en el resto de su infraestructura AD, véase Monitorización de Active Directory: los ID de eventos de seguridad que importan.

Corrección

1. Pueble Protected Users únicamente con cuentas Tier 0 humanas. Pruébelo primero en un grupo piloto — Protected Users rompe aplicaciones que dependen de NTLM, el inicio de sesión en caché/fuera de línea y cualquier flujo que dependa de renovar el ticket Kerberos más allá de 4 horas. No añada nunca cuentas de servicio o de equipo.
2. Active el indicador confidencial en cada cuenta privilegiada humana:

   Get-ADUser -Identity "jdoe" | Set-ADAccountControl -AccountNotDelegated:$true
   

   Hágalo incluso para cuentas que ya están en Protected Users — el bloqueo de delegación de Protected Users se aplica en el momento de la autenticación, pero un indicador confidencial explícito aporta defensa en profundidad y es relevante de inmediato para cualquier cuenta que aún no esté completamente migrada al grupo.
3. Elimine la confianza de delegación de las cuentas Tier 0. Borre TrustedForDelegation y msDS-AllowedToDelegateTo en cualquier cuenta privilegiada; las cuentas privilegiadas nunca deberían ser objetivos de delegación. Consulte nuestra guía Ataques de delegación Kerberos sobre cómo auditar la configuración de delegación en todo el dominio antes de empezar a eliminarla.
4. Saque las cuentas de servicio de los grupos privilegiados. Sustituya la pertenencia a Domain Admin por una cuenta de servicio administrada de grupo (gMSA) junto con permisos delegados y acotados en la OU o el recurso que el servicio realmente necesita. Si el servicio realmente necesita derechos a nivel de dominio, eso es una señal para rediseñar el servicio, no para dejar una cuenta kerberoasteable con privilegio de dominio completo.
5. Audite y elimine el SID History obsoleto. Ejecute la consulta de detección anterior; cualquier valor de sIDHistory que no esté vinculado a una migración de dominio documentada y todavía relevante debe investigarse y eliminarse con Set-ADUser -Clear sIDHistory tras confirmar que ningún acceso legítimo depende de él. Para las relaciones de confianza entre bosques y externas, active el filtrado de SID (cuarentena) para que los SID inyectados desde el otro lado de la relación de confianza se eliminen antes de llegar a su dominio — véase Ataques a relaciones de confianza de Active Directory: del dominio hijo a la raíz del bosque para saber cómo se explotan las brechas de filtrado de SID en las relaciones de confianza.

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec comprueba estas cuatro brechas en cada escaneo: NOT_IN_PROTECTED_USERS señala las cuentas privilegiadas ausentes del grupo Protected Users, SENSITIVE_DELEGATION detecta las cuentas privilegiadas sin el indicador "no se puede delegar", SERVICE_ACCOUNT_PRIVILEGED encuentra cuentas con SPN dentro de Domain Admins/Enterprise Admins, y SID_HISTORY muestra cualquier cuenta con un sIDHistory no vacío para su revisión.