Asegurando sus cuentas de servicio gestionadas por grupo

Visión general de Group Managed Service Accounts

La práctica tradicional de usar cuentas de usuario regulares como cuentas de servicio pone la carga de la gestión de contraseñas en los usuarios. Como resultado, las contraseñas de las cuentas a menudo permanecen iguales durante años, lo que las hace altamente susceptibles a ataques de fuerza bruta y mal uso. Las cuentas de servicio administradas por grupo (gMSAs) ofrecen una forma más segura de ejecutar tareas automatizadas, servicios y aplicaciones.

Las gMSA fueron introducidas en Windows Server 2016 y pueden ser utilizadas en Windows Server 2012 y superiores. Las contraseñas de gMSA son completamente manejadas por Windows: Se generan de manera aleatoria y se rotan automáticamente. Además, las contraseñas no tienen que ser conocidas por ningún usuario, ya que las cuentas de servicio se 'instalan' en el servidor que va a consultar la información de la contraseña de Active Directory en tiempo de ejecución. Como resultado, las gMSAs son mucho menos susceptibles a mal uso y compromiso que las cuentas de usuario que se utilizan como cuentas de servicio.

Seguridad de Group Managed Service Account

Las gMSAs son un tipo específico de objeto en Active Directory: msDS-GroupManagedServiceAccount. Estos objetos tienen atributos especiales asociados con ellos relacionados con su contraseña y su rotación. Similar a LAPS, querrás asegurarte de que los atributos de gMSA estén restringidos solo a los objetos de Active Directory que necesiten acceder a ellos.

Atributos y permisos de gMSA

Las gMSAs tienen los siguientes atributos:

• msDS-ManagedPassword— Un BLOB con la contraseña del gMSA
• msDS-ManagedPasswordID— El ID clave utilizado para generar la contraseña actual de gMSA
• msDS-ManagedPasswordPreviousID— El ID clave utilizado para generar la contraseña gMSA anterior
• msDS-GroupMSAMembership— Una lista de los objetos que tienen permiso para consultar la contraseña del gMSA
• msDS-ManagedPasswordInterval— El intervalo (días) en el que se rota la contraseña

Dado que la información de la contraseña se almacena en el atributo msDS-ManagedPassword, definitivamente querrás saber quién en tu entorno puede consultar la contraseña. Esa información se establece en el atributo msDS-GroupMSAMembership.

Sin embargo, es un poco más complicado que solo ese atributo, ya que los permisos de Active Directory entran en juego. Si por alguna razón un usuario u objeto está configurado para tener permisos para consultar la contraseña a través de la cuenta msDS-GroupMSAMembership, aún necesitan tener permisos de 'Lectura' para el atributo msDS-ManagedPassword del gMSA.

Esto significa que hay dos formas de asegurar las contraseñas gMSA:

• Asegúrese de que solo los objetos necesarios tengan el permiso para consultar la contraseña y que existan en el msDS-GroupMSAMembership
• Asegúrese de que solo los usuarios administrativos que necesiten acceso y las cuentas de computadora donde se instalan los gMSAs tengan permiso para leer el atributo. Además, asegúrese de que solo los administradores tengan la capacidad de modificar el gMSA y sus atributos, para que nadie pueda agregarse al atributo msDS-GroupMSAMembership.

Idealmente, deberías asegurar los gMSAs a través de ambos caminos para evitar que un atacante tenga la opción de explotar cualquiera de los escenarios mencionados anteriormente. A continuación, mostraremos cómo los permisos o configuraciones mal gestionados en un gMSA pueden llevar al compromiso de la cuenta y privilege escalation o movimiento lateral.

Abusando de la contraseña gMSA

Abusar de una gMSA es un concepto relativamente simple. Primero, obtén su contraseña utilizando una herramienta como Mimikatz o consultándola directamente debido a configuraciones inseguras en Active Directory. Dado que las gMSAs son cuentas de servicio, generalmente tienen privilegios relativamente altos, por lo que luego normalmente podrás moverte lateralmente o escalar.

Recorramos un escenario de ejemplo.

1. Primero comprometemos la cuenta de usuario ordinaria de Windows ‘notadmin’ a través de una técnica como el phishing. Esta cuenta tiene privilegios mínimos en Active Directory, pero es un administrador local en la máquina en la que hemos aterrizado.

2. A continuación, intentaremos averiguar si existen gMSA. Es muy sencillo de realizar si tienes acceso al cmdlet de Windows PowerShell. Ejecutando un script simple obtenemos todas las cuentas de servicio administradas en Active Directory:

      Get-ADServiceAccount -Filter *
      

3. Con algunas modificaciones menores al script, podemos identificar quién tiene acceso para consultar las contraseñas gMSA:

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

Como podemos ver, solo la cuenta de Kevin Joyce puede consultar las contraseñas de estas cuentas de servicio:

4. Podemos reducir el alcance de los objetivos que queremos comprobando si estas cuentas de servicio son miembros de algún grupo privilegiado, y a partir de ahí podemos profundizar en los permisos establecidos en uno de los objetos:

      Get-ADServiceAccount -Filter * -Properties memberof
      

Observando los resultados aquí, podemos ver que la cuenta de servicio gMSA es miembro de Domain Admins, así que esta será la que intentaremos explotar.

5. Al modificar un script proporcionado en una publicación sobre Microsoft LAPS, pudimos obtener un listado de todos los objetos que tienen permisos sobre una cuenta de servicios administrados que incluía Control total, Escribir todas las propiedades o Escribir propiedad para el atributo gMSA específico. A continuación, se muestra el resultado y el script está vinculado en la parte inferior.

6. Como puede ver, la cuenta notadmin tiene Control Total sobre la cuenta gMSA. Esto nos da la capacidad de modificar el atributo msDS-GroupMSAMembership, lo que nos permitirá recuperar la contraseña para la cuenta de servicio administrado:

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. Ahora que realmente podemos consultar la contraseña, veamos qué podemos hacer con ella:

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. El valor almacenado en el atributo es un BLOB que contiene los datos de la contraseña, no la contraseña en sí, por lo que tendremos que decodificar la contraseña utilizando una herramienta como DSInternals:

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

Esto nos proporciona el SecureCurrentPassword y el CurrentPassword. El CurrentPassword parece no ser útil, pero eso es porque todos los caracteres están en UTF-16. El SecureCurrentPassword puede convertirse en un hash NTLM y utilizarse en un ataque de pass the hash con mimikatz para elevar nuestros privilegios.

9. Para pass the hash solo necesitamos ejecutar mimikatz y usar este comando:

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. Ahora que tenemos una shell que se ejecuta como la cuenta de servicio gMSA que era miembro de Domain Admins, podemos hacer lo que queramos para comprometer Active Directory. Una de las maneras más rápidas, pero probablemente la más ruidosa de hacerlo, es ejecutar un DCSync attack y robar el hash de la cuenta krbtgt:

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

Protección y monitoreo de gMSA

Existen estrategias que puedes utilizar para prevenir y detectar el abuso de gMSA.

Permisos

La protección más obvia y posiblemente la más importante que puedes implementar es asegurarte de que se establezcan los permisos adecuados en tus cuentas de servicio administradas por grupo. Comprender quién tiene acceso de escritura a estos objetos es pertinente para protegerlos; alguien que pueda agregarse al atributo que controla quién puede consultar la contraseña en teoría ya tiene acceso para tomar control de esta cuenta y abusar de sus privilegios.

Lo siguiente sería entender quién tiene la capacidad de consultar las contraseñas de estas cuentas y quién necesita exactamente tal acceso. En realidad, la única cuenta que debería poder obtener la contraseña de una gMSA es la cuenta de computadora en la que está instalada la gMSA.

Registros de eventos

Existe un evento que puedes buscar en los registros de eventos nativos que te ayudará a identificar quién está consultando las contraseñas de las cuentas gMSA. Si habilitas la política ‘Audit directory service access’ para tu dominio y configuras una SACL en las gMSAs que deseas monitorear, puedes generar registros de eventos cuando las personas consulten el atributo msDS-ManagedPassword:

Activar esta configuración y crear un nuevo SACL generará un registro de eventos con el ID de evento 4662; se ve así:

Como puede ver, se ha registrado que la cuenta ‘notadmin’ leyó una propiedad en la cuenta gMSA. Las propiedades leídas son los GUID almacenados en el esquema para Active Directory, pero utilizando ADSI edit podemos ver que el GUID resaltado se resuelve en el atributo msDS-ManagedPassword.

Suponiendo que pueda tener algún tipo de reenvío de registros de eventos o una solución SIEM, estos registros serían invaluables para determinar quién está accediendo a estos atributos.

Netwrix StealthDEFEND

Otra opción es una herramienta como Netwrix StealthDEFEND. Netwrix StealthDEFEND no depende de los registros de eventos nativos y puede detectar el acceso a contraseñas gMSA y la asignación de permisos de alto riesgo directamente. Por ejemplo, el escenario mostrado arriba generaría la siguiente amenaza cuando la cuenta 'notadmin' consultara la contraseña:

Además, con Netwrix StealthDEFEND, puede construir fácilmente un playbook para ejecutar cuando se detecte abuso de gMSA. El playbook puede involucrar múltiples pasos, como requerir que la cuenta de usuario perpetrador responda a una solicitud de MFA, deshabilitar la cuenta o crear un incidente en ServiceNow.

Apéndice

Código de permisos gMSA:

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

ver en brutogMSA_Permissions_Collection.ps1 alojado con por GitHub

FAQ

¿Qué es una gMSA?

Similar a las cuentas de servicio administradas (MSA), las cuentas de servicio administradas en grupo (gMSAs) son cuentas de dominio administradas que se utilizan para ayudar a asegurar los servicios y la gestión de acceso. La funcionalidad de gMSA proporciona una gestión automática de contraseñas por parte del controlador de dominio (DC), una gestión simplificada del nombre de entidad de servicio (SPN) y la capacidad de delegar la gestión a otros administradores, lo que mejora la seguridad de Active Directory y minimiza las cuentas con acceso privilegiado.

¿Cuál es la diferencia entre MSAs y gMSAs?

A diferencia de una MSA, una gMSA puede asociarse con varios ordenadores.

Cómo encontrar una cuenta de servicio administrada por grupo?

Para obtener una lista de gMSAs en su controlador de dominio, abra Administrador del Servidor > Herramientas > Active Directory Users and Computers > Cuentas de Servicio Administradas.

¿Puede una gMSA ser un Administrador de Dominio?

Sí, una cuenta gMSA puede ser miembro de Domain Admins, aunque esta práctica puede ser peligrosa para la seguridad de la información.

¿Cómo puedo crear una gMSA?

Las cuentas de servicio administradas por grupo se crean con el cmdlet New-ADServiceAccount.

Los permisos de objeto de un gMSA determinan si esa automatización permanece segura. Cuando una cuenta ordinaria tiene acceso de escritura al atributo que controla la recuperación de la contraseña, puede otorgarse permiso para leer la credencial y luego actuar con los derechos existentes de la identidad del servicio, incluida cualquier membresía en grupos privilegiados que tenga la cuenta.

Ese único permiso suele ser lo único que separa una implementación segura de una comprometedora a nivel de dominio.

Las cuentas de servicio son identidades no humanas, y el 76 % de las organizaciones no las gestionan ni supervisan completamente, según el Netwrix 2026 Data and Identity Security Report. Una cuenta de servicio administrada por grupo elimina la contraseña de manos humanas, pero cualquiera que pueda reescribir qué principales pueden recuperarla aún puede hacerse con la identidad.

¿Qué es una cuenta de servicio administrada por grupo (gMSA)?

Cómo funciona un gMSA

La contraseña de un gMSA sigue la misma secuencia en cada host que la utiliza.

1. El Servicio de Distribución de Claves (KDS) en cada controlador de dominio guarda el secreto usado para calcular las contraseñas de cada gMSA en el dominio.

Una cuenta de servicio administrada de grupo es una cuenta administrada de Active Directory domain utilizada para ejecutar servicios, aplicaciones y tareas programadas. Windows genera una contraseña aleatoria y la rota automáticamente, y los hosts autorizados recuperan las credenciales de Active Directory en tiempo de ejecución, por lo que los administradores nunca necesitan conocer la contraseña ni almacenarla en archivos.

1. El host también recupera la contraseña anterior, manteniendo la autenticación activa durante la breve ventana mientras se propaga la rotación.

Los gMSA no son aplicables a los sistemas operativos Windows anteriores a Windows Server 2012, por lo que cada host que los utilice necesita Windows Server 2012 o posterior. Un gMSA admite una identidad de servicio en varios equipos, mientras que una cuenta de servicio administrada independiente admite un solo equipo, y una cuenta de usuario normal deja la gestión de contraseñas a los administradores.

1. Porque cada host autorizado se autentica como el mismo principal de dominio, un gMSA también simplifica la gestión del Service Principal Name (SPN) para servicios que comparten una identidad entre hosts.
2. Windows cambia la contraseña automáticamente, cada 30 días por defecto, sin que ningún host necesite aviso previo o intervención manual.
3. Un host autorizado contacta a un controlador de dominio y recupera la contraseña actual en tiempo de ejecución, calculada a partir de ese secreto, en lugar de almacenarla localmente.

gMSA frente a otros tipos de cuentas de servicio

Juntos, estos atributos indican a un host cómo recuperar la contraseña, y msDS-GroupMSAMembershipExpand es lo que un atacante necesita reescribir, la mala configuración que explota el tutorial más adelante.

Active Directory representa un gMSA con la clase de objeto msDS-GroupManagedServiceAccountExpand, y estos atributos del esquema almacenan la contraseña y los controles de recuperación.

Windows ofrece varios principales para ejecutar servicios, y cada uno soporta diferentes servicios y gestiona su contraseña de manera distinta. Elija el tipo de cuenta según los requisitos de autenticación y el modelo de implementación de la aplicación.

A diferencia de un sMSA, un gMSA puede compartirse entre varios ordenadores, lo que lo hace adecuado para granjas de servidores y servicios con balanceo de carga. Ambos son cuentas de servicio gestionadas que permiten a Windows y Active Directory manejar la gestión de contraseñas.

Por qué importan las gMSA

Microsoft señala que las contraseñas gMSA son generadas por máquina y rotadas automáticamente, pero no están vinculadas a la máquina, por lo que aún pueden ser leídas desde un host comprometido, y una gMSA no puede migrarse directamente a una dMSA.

Windows Server 2025 añade la delegated managed service account (dMSA), que migra una cuenta de servicio tradicional a una cuenta de máquina con claves gestionadas y aleatorias, y vincula la autenticación a la identidad del dispositivo.

Contraseñas fuertes que nadie tiene que gestionar

Usar una cuenta de usuario normal como cuenta de servicio pone la generación, distribución y rotación de contraseñas en manos de los administradores, y la contraseña permanece sin cambios hasta que alguien la rota. Un gMSA reemplaza ese ciclo manual por una generación y recuperación gestionadas por el dominio.

La contraseña aún debe llegar a cada host, por lo que la autorización y la seguridad del host forman parte de la protección de las credenciales.

Una identidad en toda una granja de servidores

Los protocolos de autenticación que admiten autenticación mutua, como Kerberos, requieren que cada instancia de un servicio alojado en una granja use el mismo principal. Un gMSA proporciona a todos los hosts miembros un único principal de dominio, y los administradores gestionan sus permisos de forma centralizada sin sincronizar una contraseña entre hosts.

Menor exposición a ataques de fuerza bruta y uso indebido

Un gMSA utiliza una contraseña de 240 bytes generada aleatoriamente que Windows cambia cada 30 días, minimizando el riesgo de compromiso mediante ataques de fuerza bruta o de diccionario. Los administradores configuran la cuenta y sus hosts autorizados y nunca manejan la contraseña, por lo que los servicios obtienen credenciales fuertes sin que nadie las copie en scripts, notas de implementación o archivos de configuración.

Los servicios de Windows, los grupos de aplicaciones IIS y las tareas programadas pueden ejecutarse como un gMSA, y la guía de Kerberoasting de Microsoft también menciona SQL Server. El soporte de la aplicación sigue siendo un requisito de implementación, por lo que debe probar cada servicio bajo el gMSA antes de pasarlo a producción.

Una configuración predeterminada más segura contra Kerberoasting

La generación automática elimina la selección de contraseñas por parte de las personas, y la rotación automática elimina la tarea recurrente de actualizar una credencial estática en cada host de servicio. Microsoft recomienda gMSAs para servicios locales a menos que un servicio no pueda usarlos.

La responsabilidad restante es la gobernanza de acceso, porque alguien que pueda cambiar la autorización para recuperar la contraseña puede obtener la credencial sin haber participado nunca en la generación de la contraseña.

Kerberoasting permite a un atacante con cualquier cuenta de dominio solicitar tickets de servicio y descifrar la contraseña de una cuenta de servicio sin conexión, por lo que la fortaleza de la contraseña determina si el ataque funciona.

La guía de Kerberoasting de Microsoft identifica las cuentas con contraseñas débiles como las más vulnerables y recomienda usar gMSAs o dMSAs siempre que sea posible, porque una contraseña generada elimina la debilidad elegida por humanos de la que depende la técnica.

Cómo configurar un gMSA de forma segura

Netwrix Threat Manager detecta el robo de credenciales, movimiento lateral y escalada de privilegios en entornos híbridos. Solicite una demostración.

1. Verifique los requisitos

Confirme los requisitos de dominio, host, administración y aplicación antes de implementar el gMSA.

Cree la cuenta con una lista explícita de hosts autorizados, luego instálela y valídela en cada host.

• Niveles funcionales de dominio y bosque configurados en Windows Server 2012 o posterior, que Microsoft indica que soporta funciones gMSA para todos los dispositivos.
• Hosts que ejecutan Windows Server 2012 o posterior.
• El módulo de PowerShell de Active Directory en el sistema de administración, que requiere una arquitectura de 64 bits para ejecutar los cmdlets gMSA.
• Una clave raíz KDS disponible para los controladores de dominio.
• Pertenencia a Domain Admins o Enterprise Admins, o permiso delegado para crear msDS-GroupManagedServiceAccountExpand objetos.
• Un servicio que admite gMSAs, como un servicio de Windows, un grupo de aplicaciones IIS o una tarea programada.

Delegue la creación de gMSA a un grupo administrativo dedicado y mantenga la identidad del servicio fuera de los grupos administrativos.

2. Cree la clave raíz KDS

3. Cree el gMSA con New-ADServiceAccount

Los clústeres de conmutación por error no admiten gMSAs, pero los servicios que se ejecutan en el servicio Cluster pueden usar uno si son un servicio de Windows, un grupo de aplicaciones o una tarea programada, o si admiten gMSAs de forma nativa. Kerberos también debe funcionar de extremo a extremo, así que registre los SPN para cada servicio, mantenga los registros DNS y los relojes precisos, y permita el tráfico Kerberos entre los sistemas involucrados.

A pesar del nombre del parámetro, -EffectiveImmediatelyExpand no omite la replicación. Otros controladores de dominio no pueden usar la clave hasta que se replique, y el procedimiento de creación de claves de Microsoft hace que los controladores de dominio esperen hasta 10 horas antes de permitir la creación de un gMSA, así que permita esa ventana en producción.

4. Instale y pruebe el gMSA en cada host

Cree un grupo de seguridad dedicado para las cuentas de los equipos host del servicio, luego cree el gMSA con New-ADServiceAccountExpand, nombrando su nombre DNS y el grupo de seguridad en PrincipalsAllowedToRetrieveManagedPasswordExpand. Microsoft requiere que los nombres gMSA sean únicos en todo el bosque, no solo en el dominio.

Verifique si el bosque ya tiene una clave raíz KDS antes de crear una, porque la clave es un requisito único a nivel de bosque. Créela en un controlador de dominio Windows Server 2012 o posterior con Add-KdsRootKey -EffectiveImmediatelyExpand, luego confirme el ID de evento 4004Expand en el registro de eventos KDS.

5. Configure el servicio para que se ejecute como el gMSA

Establezca un intervalo de contraseña personalizado con -ManagedPasswordIntervalInDaysExpand durante la creación si el despliegue lo requiere, ya que el intervalo solo puede establecerse al crear. Registre el propietario de la aplicación de la cuenta y los hosts previstos junto con la configuración del despliegue, y excluya los grupos generales de administración de servidores y los grupos que contienen usuarios ordinarios del parámetro de recuperación, como explica "Limit who can retrieve the password".

Pruebe cada servidor miembro individualmente, porque un resultado exitoso en un servidor no garantiza la membresía de grupo o conectividad en otro servidor. Resuelva la validación fallida antes de cambiar la identidad de inicio de sesión de un servicio en producción.

Configure la identidad de inicio de sesión del servicio mediante Service Control Manager, la configuración de identidad del grupo de aplicaciones IIS o la configuración de tareas programadas, y deje la contraseña en blanco. Windows recupera la credencial administrada.

Cómo los atacantes abusan de una contraseña gMSA

Conceda a la cuenta los permisos de aplicación que necesita y luego confirme tanto el inicio del servicio como el acceso a los recursos dependientes. Una prueba de cuenta aprobada solo demuestra la preparación de las credenciales, por lo que la carga de trabajo aún necesita sus propios permisos para archivos, bases de datos y otros recursos.

Agregue la cuenta de computadora de cada host al grupo de seguridad, luego ejecute Install-ADServiceAccountExpand seguido de Test-ADServiceAccountExpand en cada host autorizado. Test-ADServiceAccountExpand verifica que el host pueda recuperar la contraseña.

El laboratorio siguiente usa una cuenta ordinaria llamada notadminExpand y un gMSA privilegiado que está mal configurado. Los nombres de dominio y cuenta pertenecen a ese entorno de ejemplo.

Encuentra los gMSA y quién puede leerlos

Un atacante puede obtener una contraseña gMSA a través de una ruta autorizada o mediante permisos inseguros de Active Directory, y luego autenticarse como la cuenta con sus derechos existentes.Explotación de gMSA abarca una clase de ataque más amplia, incluyendo ataques Golden gMSA, que toman una ruta diferente hacia las credenciales gestionadas.

1. Con el módulo de PowerShell de Active Directory disponible, el atacante enumera las cuentas de servicio administradas con Get-ADServiceAccount -Filter *Expand.

Encuentra un gMSA privilegiado y una forma de entrar

1. Solicitar la propiedad PrincipalsAllowedToRetrieveManagedPasswordExpand muestra qué principales pueden leer la contraseña de cada cuenta.

En los resultados del laboratorio, solo una cuenta administrativa puede consultar las contraseñas, por lo que notadminExpand aún no puede leerlas. Esa configuración es importante cuando el atacante examina quién puede cambiar el objeto gMSA.

1. El atacante verifica si alguna cuenta de servicio pertenece a grupos privilegiados consultando la propiedad memberOfExpand.

El gMSA del laboratorio pertenece a Domain Admins, por lo que el atacante lo selecciona. Su membresía existente proporciona los privilegios necesarios para los pasos posteriores.

Recuperar y descifrar la contraseña

1. Revisar los permisos de objetos identifica a los principales con Control total, Escribir todas las propiedades o acceso a Escribir propiedad en el atributo de autorización para recuperación de contraseña, usando un script adaptado de un enfoque descrito en una publicación sobre Microsoft LAPS. El script de permisos en "Find and audit every gMSA" a continuación realiza la misma comprobación.
2. En el laboratorio, notadminExpand tiene Control total sobre el objeto gMSA, lo que le permite usar Set-ADServiceAccountExpand para agregarse a PrincipalsAllowedToRetrieveManagedPasswordExpand.

Usa la contraseña para escalar

1. El atributo contiene un BLOB con los datos de la contraseña en lugar de la contraseña misma, por lo que el atacante lo decodifica con DSInternals, que expone los valores de la contraseña actual y anteriores y puede convertir la contraseña actual en un hash NT.
2. El atacante compromete a notadminExpand mediante una técnica como el phishing. La cuenta tiene privilegios mínimos de Active Directory pero posee local administrator rights en la máquina comprometida.
3. Después del cambio, notadminExpand puede consultar el atributo msDS-ManagedPasswordExpand y almacenar el objeto devuelto.

Cómo asegurar sus gMSA

Un único permiso excesivamente amplio, Full Control sobre un objeto gMSA, fue lo que permitió que el ataque pasara de una cuenta comprometida ordinaria a la falsificación de credenciales a nivel de dominio.

Los ataques Golden gMSA acceden a la contraseña de un gMSA por una ruta diferente y se explican en la página de explotación de gMSA.

Asegure conjuntamente la autorización de recuperación de un gMSA, los permisos de objetos y los privilegios de servicio.

1. Con la credencial recuperada, el atacante se autentica como el gMSA mediante pass-the-hash y comienza un proceso bajo la identidad del servicio, heredando todos los derechos que esa identidad posee.

Limitar quién puede recuperar la contraseña

Restringir quién puede cambiar el gMSA

1. Debido a que el gMSA del laboratorio pertenece a Domain Admins, el atacante puede usar sus derechos de replicación para ejecutar un ataque DCSync contra la cuenta krbtgtExpand. El material de credenciales de esa cuenta firma cada ticket Kerberos en el dominio, por lo que recuperarlo permite al atacante falsificar tickets para cualquier usuario después.

Mantenga los gMSAs fuera de los grupos privilegiados

Solo las cuentas de equipo que ejecutan el servicio deberían normalmente obtener su contraseña gMSA. Para una implementación en varios servidores, use un grupo de seguridad dedicado que contenga esas cuentas de equipo, configúrelo mediante PrincipalsAllowedToRetrieveManagedPasswordExpand, y revise su membresía cada vez que cambie la lista de hosts del servicio.

Conceda acceso de escritura solo a los administradores que necesiten gestionar la cuenta y revise los permisos de Control total, Escritura de todas las propiedades y Escritura de propiedades específicas en cada gMSA. Un principal con permiso para modificar msDS-GroupMSAMembershipExpand puede autorizar la recuperación de su propia contraseña, que es precisamente la mala configuración que explota la guía anterior.

Conceda a cada gMSA solo los derechos que requiere su servicio. Un gMSA puede pertenecer a Domain Admins, pero esa membresía otorga a cualquiera que obtenga sus credenciales privilegios administrativos en todo el dominio, y la guía de mitigación de Microsoft recomienda revisar los permisos de las cuentas de servicio y eliminar el acceso excesivo.

Aplicar cifrado AES

Proteja la cuenta a través de ambas rutas de permisos. Restringa qué principales representa el atributo msDS-GroupMSAMembershipExpand y limite el acceso al directorio al objeto gMSA en sí, especialmente el permiso para modificar la cuenta o su autorización de recuperación.

Verifique la membresía directa del grupo y los permisos efectivos que otorgan los grupos anidados, y documente el acceso requerido por la aplicación antes de eliminar permisos para que el propietario del servicio pueda validar la configuración revisada.

Los controladores de dominio que ejecutan Windows Server 2025 ya no emiten tickets de concesión de tickets RC4, por lo que un dispositivo heredado que depende de RC4 no puede autenticarse con ellos.

Encuentre y audite cada gMSA

Microsoft está eliminando la encriptación RC4 Kerberos por defecto, no solo recomendándola en contra. Una actualización de 2022 ya cambió el tipo de encriptación predeterminado a Advanced Encryption Standard (AES)-SHA1 para cualquier cuenta sin un tipo de encriptación explícito configurado.

Verifique el atributo msDS-SupportedEncryptionTypesExpand de cada gMSA y confirme que incluya AES en lugar de depender del valor predeterminado de reserva del dominio, ya que esa reserva es exactamente lo que Microsoft está eliminando.

Restablezca la contraseña de la cuenta después de habilitar el soporte AES para generar nuevas claves, y luego pruebe la autenticación, porque un gMSA que quede solo en RC4 puede perder la autenticación Kerberos por completo en lugar de simplemente funcionar con un cifrado más débil.

Monitorear lecturas de contraseñas

Script original: gMSA_Permissions_Collection.ps1.

El evento resultante identifica la cuenta sujeta, el objeto de directorio objetivo y las propiedades accedidas.

El script de permisos a continuación informa qué cuentas tienen acceso de Control total o Escritura de propiedad al atributo msDS-GroupMSAMembershipExpand de un gMSA, la comprobación que el paso 5 del recorrido anterior realiza desde el lado del atacante. Los administradores aún deben revisar la herencia, la membresía de grupos y el acceso efectivo al decidir quién debe conservar esos derechos.

Enumere las cuentas de servicio administradas con Get-ADServiceAccount -Filter *Expand, luego filtre los objetos cuyo ObjectClassExpand sea msDS-GroupManagedServiceAccountExpand para distinguir gMSA de cuentas de servicio administradas independientes.

Retire gMSAs que ya no use

Habilite la política de acceso al servicio de directorio de auditoría y configure una lista de control de acceso del sistema (SACL) en los gMSAs para monitorear, lo que genera el ID de evento 4662Expand cada vez que un principal lee msDS-ManagedPasswordExpand.

Los identificadores de propiedad aparecen como GUID de esquema en el evento, y ADSI Edit puede resolver el GUID relevante para confirmar que corresponde a msDS-ManagedPasswordExpand.

Reenvíe los registros del controlador de dominio a un sistema de gestión de información y eventos de seguridad (SIEM), compare las lecturas de contraseñas con los hosts de servicio aprobados de la cuenta e investigue la recuperación por usuarios o equipos inesperados.

Cómo Netwrix ayuda a proteger los gMSA

Proteger la administración de gMSA

Revisar manualmente los permisos de recuperación y los registros de auditoría no es viable cuando un entorno tiene más de unos pocos gMSA. Estos tres productos de Netwrix cubren el acceso administrativo a la cuenta, detectan el uso indebido de credenciales y ofrecen visibilidad continua sobre qué cuentas aún tienen permisos excesivos.

Elimine un gMSA no utilizado de sus hosts anteriores con Uninstall-ADServiceAccountExpand. La desinstalación del host y la eliminación de la cuenta del directorio son acciones de ciclo de vida separadas. Confirme que todas las cargas de trabajo dependientes se hayan migrado o retirado antes de eliminar el objeto AD, y elimine las autorizaciones de host obsoletas y los permisos de recursos asociados como parte del mismo cambio.

Detectar comportamiento anómalo de cuentas de servicio

Con Netwrix Privilege Secure, el distrito concede acceso inmediato mediante cuentas temporales que se eliminan una vez completada la tarea, e implementó Privileged Access Management para sus sistemas críticos en días en lugar de meses.

Netwrix Privilege Secure reemplaza el acceso permanente a objetos privilegiados como gMSAs con cuentas temporales y específicas para tareas. Eastern Carver County Schools vio cómo los Red Teams accedían repetidamente a sistemas críticos mediante un acceso privilegiado excesivo e innecesario.

Encuentre cuentas de servicio con permisos excesivos y obsoletas

Netwrix Threat Manager detecta el robo de credenciales, el movimiento lateral y la escalada de privilegios en entornos híbridos. Investigue esas detecciones para el abuso de identidades de servicio como gMSAs, donde un atacante que se autentica con una contraseña gestionada robada ejerce los derechos existentes de la identidad.

Combine la rotación automática con permisos estrictos de recuperación

Netwrix Access Analyzer resuelve la membresía de grupos anidados y analiza los permisos efectivos en objetos de Active Directory, y sus informes también señalan cuentas de fiduciarios obsoletas. Use esos hallazgos para revisar la recuperación de gMSA y los permisos de objetos e identificar candidatos para limpieza.

La rotación automática de contraseñas y los permisos estrictos de recuperación son dos controles separados, y un gMSA permanece seguro solo cuando ambos se mantienen. El recorrido anterior muestra qué sucede cuando solo un permiso falla: una cuenta comprometida ordinaria hereda una credencial de Domain Admin y falsifica tickets para todo el dominio, sin que ninguna contraseña sea descifrada o adivinada.

Trate las revisiones de permisos como un trabajo recurrente, no como un paso de configuración único, porque cada nuevo host, cada cambio en la membresía de grupos y cada migración de servicio pueden reabrir el mismo camino.

Solicite una demostración para ver cómo Netwrix Privilege Secure elimina el acceso permanente a cuentas privilegiadas, Netwrix Threat Manager detecta el abuso de cuentas de servicio y Netwrix Access Analyzer identifica cuentas con permisos excesivos.