Exposición contraseña GMSA Active Directory: cuando la rotación automática no es una frontera de seguridad

Exposición contraseña GMSA Active Directory

Exposición contraseña GMSA Active Directory: estos hallazgos están entre las brechas más consecuentes que EtcSec observa en la higiene de cuentas de servicio, porque la cuenta expuesta suele ser la que todos daban por segura por diseño. Una cuenta de servicio administrada de grupo (gMSA, Group Managed Service Account) es la solución de Microsoft a uno de los problemas más antiguos de Active Directory: contraseñas de cuentas de servicio estáticas y conocidas por humanos que permanecen sin cambios durante años en scripts, tareas programadas y archivos de configuración. El controlador de dominio genera una contraseña aleatoria de 256 bytes y la rota automáticamente — cada 30 días de forma predeterminada — de modo que ningún administrador tiene que escribirla ni almacenarla en ningún sitio (Microsoft Learn — Manage Group Managed Service Accounts). Esa es la promesa, y en sus propios términos se cumple.

Lo que sigue causando esta exposición no es una contraseña filtrada — es una lista de principales autorizados a leerla que resulta demasiado amplia. «Nadie tiene la contraseña» solo se sostiene mientras la lista de quién puede recuperarla se mantenga acotada, y esa lista está controlada por un único atributo que se deja demasiado permisivo con mucha más frecuencia de la que los defensores esperan.

Para qué sirve un gMSA

Los servicios que se ejecutan de forma idéntica en una granja balanceada — grupos de aplicaciones IIS, tareas programadas, servicios de Windows — necesitan un único principal que se comporte igual en cada host para que la autenticación mutua Kerberos funcione. Un gMSA les da eso sin una contraseña compartida sincronizada manualmente: cualquier host con derechos de recuperación obtiene la contraseña actual directamente desde AD por LDAP cada vez que el servicio la necesita (Microsoft Learn).

Por qué la lista de derechos de lectura sigue creando exposición

La brecha aparece de dos formas en la práctica: un grupo de seguridad creado para el gMSA se reutiliza para algo no relacionado y va sumando silenciosamente nuevos miembros con el tiempo, o el grupo se anida dentro de un grupo de administración más amplio ya existente durante la configuración, porque era la forma más rápida de poner el servicio en marcha. Cualquiera de los dos caminos deja la lista de lectores más amplia que los uno o dos hosts que realmente la necesitan — y, a diferencia de una revisión normal de grupo privilegiado, esta ACL no se revisa con la misma frecuencia que la pertenencia a grupos.

Cómo funciona: PrincipalsAllowedToRetrieveManagedPassword

El atributo msDS-GroupMSAMembership

Al crear un gMSA, se especifica qué cuentas de equipo o grupos de seguridad pueden obtener su contraseña:

New-ADServiceAccount -Name svc-app01 -DNSHostName svc-app01.corp.local `
  -PrincipalsAllowedToRetrieveManagedPassword "SG-App01-Hosts"

Ese parámetro escribe en msDS-GroupMSAMembership, un atributo que contiene un descriptor de seguridad en formato String(NT-Sec-Desc) — una ACL codificada en base64 que no puede leerse directamente. PrincipalsAllowedToRetrieveManagedPassword es el wrapper de PowerShell que AD expone para leerlo y escribirlo de forma sencilla (Microsoft Learn — Set-ADServiceAccount); la mecánica interna del atributo está documentada en detalle por DSInternals y la referencia gMSA de InternalAllTheThings.

Quien figure en esa lista puede consultar el atributo msDS-ManagedPassword, que AD calcula al leerlo y devuelve como un MSDS-MANAGEDPASSWORD_BLOB que contiene la contraseña actual en texto claro. Un punto crítico: esto no es una comprobación de grupo privilegiado — los Domain Admins no obtienen ningún acceso implícito. Solo los principales nombrados explícitamente en msDS-GroupMSAMembership pueden leer la contraseña, sean quienes sean (DSInternals).

Cómo la lista se vuelve demasiado amplia

No existe ninguna advertencia integrada cuando PrincipalsAllowedToRetrieveManagedPassword crece más allá de su alcance original. Un grupo añadido «temporalmente» durante una migración, una pertenencia anidada heredada de la delegación de una OU superior, o un grupo de administración anidado añadido porque ya contenía las cuentas de equipo correctas — cualquiera de estos casos amplía silenciosamente quién puede suplantar la cuenta de servicio, sin ningún cambio correspondiente en el propio objeto gMSA que llame la atención durante una revisión rutinaria. Es la misma clase de problema tratada en Abuso de ACL y DCSync: un permiso que nadie recuerda haber otorgado, todavía válido, todavía explotable.

La cadena de ataque: de un grupo demasiado amplio a la suplantación completa

Un caso real: el gMSA de Citrix en Domain Admins

El análisis de Sean Metcalf en ADSecurity.org documenta un caso concreto de este patrón: un gMSA de Citrix que era, a su vez, miembro de Domain Admins, tenía sus derechos de recuperación de contraseña delegados a un grupo llamado «Citrix04» — que, al revisarlo, contenía una cuenta de usuario normal. Comprometer esa única cuenta de usuario bastó para obtener la contraseña de un gMSA equivalente a Domain Admin (ADSecurity.org — GMSA Security Tip #14).

Leer la contraseña una vez en la lista

Una vez que un principal está en la lista de lectores autorizados, extraer la contraseña no requiere ningún exploit — solo una lectura:

# Usando los módulos AD + DSInternals
$gmsa = Get-ADServiceAccount -Identity "svc-app01" -Properties 'msDS-ManagedPassword'
$blob = ConvertFrom-ADManagedPasswordBlob $gmsa.'msDS-ManagedPassword'
ConvertTo-NTHash -Password $blob.SecureCurrentPassword

Get-ADServiceAccount devuelve el blob, ConvertFrom-ADManagedPasswordBlob (DSInternals) lo decodifica en las contraseñas actual y anterior en texto claro, y ConvertTo-NTHash deriva el hash NT para uso sin conexión (DSInternals). Herramientas como GMSAPasswordReader.exe y gMSADumper.py automatizan la misma lectura LDAP de forma remota, sin tocar nunca el host objetivo.

Esta relación es exactamente lo que mapea la arista ReadGMSAPassword de BloodHound: cualquier usuario, grupo o equipo con derechos de recuperación sobre un gMSA. SpecterOps documenta tres rutas de abuso una vez que se tiene esa arista — robar o inyectar el token del gMSA si ya está conectado en un host autorizado, programar una tarea o servicio para ejecutarse como el gMSA en un host autorizado, o recuperar la contraseña de forma remota y usar el hash NT resultante para un overpass-the-hash (BloodHound — ReadGMSAPassword). Ninguna de estas rutas requiere que falle la rotación automática del gMSA — la rotación solo significa que el atacante vuelve a leer la contraseña después de cada ciclo, igual que lo haría un host autorizado.

Detección

Event IDs de Windows a correlacionar

Estos Event IDs y el enfoque de correlación (haciendo coincidir 4662, 2946 y 4624 por Logon ID en una ventana corta) están documentados en el análisis de TrustedSec sobre la caza de abusos de gMSA (TrustedSec — Splunk SPL Queries for Detecting GMSA Attacks). Sin una SACL en el objeto gMSA, el evento 4662 nunca se dispara — la auditoría debe activarse deliberadamente, objeto por objeto, una carencia que se solapa con las brechas de configuración de la política de auditoría de Active Directory más amplias.

Auditar directamente la lista de lectores

La detección basada en logs solo detecta una lectura después de que ocurre. Audite directamente y a nivel de todo el dominio la lista de autorización, en lugar de esperar a un evento:

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

Ejecute esto contra cada gMSA del dominio y expanda cualquier grupo devuelto — un simple nombre de grupo de seguridad puede ocultar una cuenta de usuario obsoleta, un grupo basado en una OU demasiado amplio, o un grupo privilegiado anidado que nunca debió tener derechos de recuperación.

Remediación

1. Enumere cada gMSA y sus lectores usando la consulta anterior. Expanda la pertenencia a grupos, no solo el nombre del principal de nivel superior — ahí es donde se esconde una sorpresa tipo Citrix04.
2. Reduzca PrincipalsAllowedToRetrieveManagedPassword a los hosts exactos que lo necesitan. Use Set-ADServiceAccount -Identity <NombreGMSA> -PrincipalsAllowedToRetrieveManagedPassword <grupo-acotado> para reemplazar un grupo demasiado amplio por uno limitado a las cuentas de equipo que realmente ejecutan el servicio (Microsoft Learn — Set-ADServiceAccount).
3. Verifique que nada se rompa antes y después del cambio con Test-ADServiceAccount -Identity <NombreGMSA> en cada host que deba conservar el acceso (Microsoft Learn — Manage Group Managed Service Accounts).
4. Nunca anide un grupo lector de gMSA dentro de un grupo de administración más amplio para ahorrar un paso durante la configuración — ese tipo de anidación es lo que hace que un único grupo termine controlando la recuperación de contraseña de cuentas que nunca debía tocar. Vea Anidamiento peligroso de grupos para entender cómo la pertenencia transitiva crea rutas que los defensores no esperan.
5. Si el propio gMSA está dentro de un grupo privilegiado (Domain Admins o equivalente), trátelo como un hallazgo distinto y acumulativo: unos derechos de lectura de contraseña demasiado amplios sobre un miembro de un grupo privilegiado son un camino más rápido hacia Domain Admin que cualquiera de los dos problemas por separado. Esto es distinto de la higiene habitual de pertenencia a grupos privilegiados, tratada en Cuentas privilegiadas de Active Directory: Protected Users, delegación y brechas de cuentas de servicio.
6. Active la auditoría de acceso al servicio de directorio (SACL) en los objetos gMSA para que los eventos 4662 realmente se generen para las cuentas que más importan, en lugar de descubrir la brecha solo durante un incidente.

Cómo lo detecta EtcSec

La comprobación GMSA_PASSWORD_READERS de EtcSec señala los objetos gMSA cuyo PrincipalsAllowedToRetrieveManagedPassword incluye un principal más amplio que el alcance de hosts esperado — cuentas de usuario, grupos de seguridad genéricos, o pertenencias anidadas que no deberían poder recuperar la contraseña. Va emparejada con GMSA_OLD_PASSWORD, que señala los gMSA cuya contraseña administrada no ha rotado según lo previsto, y con DANGEROUS_GROUP_NESTING, que detecta el patrón de pertenencia transitiva que suele causar este exceso de alcance.

Lectura relacionada: Kerberoasting: detección y prevención de ataques a cuentas de servicio cubre el ataque basado en SPN frente al que los gMSA son en gran medida inmunes (no hay ticket crackeable, ya que la contraseña son 256 bytes de datos aleatorios) — un contexto útil para entender por qué adoptar gMSA no elimina el riesgo de las cuentas de servicio, simplemente lo traslada a esta ACL. BadSuccessor: escalada de privilegios mediante dMSA cubre una ruta de escalada distinta pero relacionada, a través de cuentas de servicio administradas delegadas.