Cuentas de Servicio standard vs Cuenta de Servicio GMSA.

Las cuentas de servicio en Active Directory (AD) son esenciales para la operación de aplicaciones y servicios dentro de un entorno Windows. Estas cuentas permiten que los servicios se ejecuten con los permisos necesarios para acceder a recursos tanto locales como de red. Existen principalmente dos tipos de cuentas de servicio: las cuentas de usuario estándar y las cuentas de servicio administradas por grupo (gMSA). También existen las cuentas de tipo MSA, pero en este artículo me centraré en la comparación entre cuentas de servicio nominales y cuentas de tipo Group Manage Service Account. Comprender las diferencias entre ellas y sus implicaciones de seguridad es crucial para proteger la infraestructura de TI.

Cuentas de Servicio Estándar

Las cuentas de servicio estándar son cuentas de usuario creadas manualmente en AD para ejecutar servicios específicos. Estas cuentas requieren una gestión manual de contraseñas y permisos. Una práctica común es asignar contraseñas complejas y cambiarlas periódicamente para mantener la seguridad. Sin embargo, esta gestión manual puede ser propensa a errores y omisiones, lo que podría comprometer la seguridad.

Riesgos Asociados:

• Gestión de Contraseñas: La necesidad de cambiar contraseñas manualmente puede llevar a prácticas inseguras, como reutilización de contraseñas o cambios infrecuentes.
• Exposición de Credenciales: Las contraseñas almacenadas o compartidas de manera insegura pueden ser interceptadas por atacantes.
• Ataques de Hash: Los atacantes pueden obtener el hash de la contraseña de una cuenta de servicio y utilizar técnicas como “Pass-the-Hash” para autenticarse sin conocer la contraseña en texto plano.

Cuentas de Servicio Administradas de Grupo (gMSA)

Las gMSA son cuentas de dominio diseñadas para proporcionar una gestión automática de contraseñas y simplificar la administración de nombres de entidad de servicio (SPN). Introducidas en Windows Server 2012, las gMSA permiten que múltiples servidores utilicen la misma cuenta de servicio sin necesidad de sincronizar manualmente las contraseñas.

Ventajas de Seguridad:

• Rotación Automática de Contraseñas: Las contraseñas de las gMSA se actualizan automáticamente, reduciendo el riesgo asociado a contraseñas estáticas o mal gestionadas.
• Almacenamiento Seguro: Las contraseñas de las gMSA no se almacenan en texto plano ni se exponen a administradores, lo que disminuye la posibilidad de compromisos internos.
• Restricciones de Uso: Las gMSA pueden configurarse para ser utilizadas únicamente por servicios o servidores específicos, limitando su exposición.

Comparación de Seguridad desde una Perspectiva Ofensiva

Desde el punto de vista de un atacante, comprometer una cuenta de servicio estándar suele ser más sencillo que una gMSA. Para vulnerar una cuenta de servicio estándar, el atacante puede:

1 – Obtener el Hash de la Contraseña: Utilizando herramientas para volcar hashes de contraseñas almacenadas en sistemas comprometidos. Por ejemplo Mimikatz. Si un usuario ha utilizado la cuenta de servicio para iniciar sesión en un servidor, el hash quedará almacenado en LSASS.
2 – Descifrar el Hash: Aplicando técnicas de fuerza bruta o ataques de diccionario para obtener la contraseña en texto plano.

En contraste, para comprometer una gMSA, el atacante enfrenta desafíos adicionales:

1. Acceso a la cuenta con permisos de recuperación de contraseña: Las gMSA requieren que el atacante comprometa una cuenta de AD que a su vez tenga permisos específicos para recuperar la contraseña de la gMSA, lo que añade una capa de complejidad. Dicha cuenta además debería pertenecer al grupo asignado a la hora de crear la cuenta con la propiedad –PrincipalsAllowedToRetrieveManagedPassword
2. Generación de contraseña: Incluso con acceso a la clave raíz del Servicio de Distribución de Claves (KDS), el atacante necesita herramientas especializadas para generar la contraseña de la gMSA.

Además, dependiendo de si el entorno tiene activado LDAPS, el proceso para extraer credenciales es diferente. Veamos un ejemplo:

LDAPS

En la siguiente captura podemos ver un extracto de enumeración realizado con la herramienta Bloodhound. Se puede apreciar que el grupo GMSA_USERS tiene permisos para leer el password de la cuenta de servicio GMSA_SVC$. Por tanto, los usuarios que pertenezcan a ese grupo heredaran dichos permisos.

Supongamos que dentro del grupo GMSA_USERS hemos encontrado una cuenta llamada sqlsvc de la cual hemos extraído su contraseña.

Lo siguiente que haríamos sería utilizar la herramienta gMSADumper.py para extraer los hashes de la cuenta de tipo GMSA.

Una vez obtenido el hash podríamos usarlo para impersonar por ejemplo al usuario Administrator mediante el comando impacket.

Y que ocurre si el entorno no tiene LDAPS. Bueno en ese caso la herramienta gMSADumper no nos funcionaría y el proceso sería algo más complejo. Veamos un ejemplo:

LDAP:

Partiendo desde el mismo punto en el que hemos obtenido las contraseñas de la cuenta svcsql necesitaríamos lanzar los siguientes comandos:

Primero necesitamos obtener y cargar el módulo DSInternals

Import-Module “C:\temp\DSInternals\4.14\DSInternals.psd1”

Lo siguiente es guardar en una variable la propiedad msDS-ManagedPassword de la GMSA

$gmsa = Get-ADServiceAccount GMSA_SQL -Properties msDS-ManagedPassword

Guardamos la contraseña en otra variable

$pass = ConvertFrom-ADManagedPasswordBlob -Blob $gmsa.’msDS-ManagedPassword’

Guardamos en otra variable el password convertido en una cadena segura.

$secpass = ConvertTo-SecureString -String $pass.’CurrentPassword’ -AsPlainText
-Force

En este punto ya podríamos usar las credenciales como cadena segura y como paso adicional podríamos obtener la contraseña en texto claro.

$cred = New-Object System.Management.Automation.PSCredential GMSA_SQL$,

Por lo tanto como conclusión podríamos afirmar las cuentas gMSA ofrecen una mayor resistencia o un grado más de complejidad para llegar a extraer sus credenciales.

Recomendaciones de Seguridad

Con todo lo expuesto podríamos ofrecer las siguientes recomendaciones de seguridad para proteger las cuentas de servicio.

• Implementar gMSA Siempre que Sea Posible: Aprovechar las ventajas de seguridad que ofrecen las gMSA para servicios y aplicaciones compatibles.
• Limitar Permisos de Recuperación de Contraseña: Asegurarse de que solo cuentas altamente confiables tengan permisos para recuperar contraseñas de gMSA. Es decir, tenemos que tener controladas aquellas cuentas o máquinas que tengan permisos sobre la propiedad PrincipalsAllowedToRetrieveManagedPassword
• Monitorear Actividades de Cuentas de Servicio: Implementar auditorías y alertas para detectar actividades sospechosas asociadas a cuentas de servicio.
• Implementar un modelo de tier robusto y si utilizamos cuentas de servicio standard no realizar logon en servidores de tier-0.