Cómo recuperarse de un ataque gMSA dorado

En este artículo se describe un enfoque para reparar las credenciales de una cuenta de servicio administrada (gMSA) de grupo que se ven afectadas por un incidente de exposición de la base de datos del controlador de dominio.

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Síntomas

Para obtener una descripción de un ataque de Golden gMSA, consulte el siguiente artículo de Semperis:

Presentación del ataque de Golden GMSA

La descripción del artículo anterior es precisa. El enfoque para resolver el problema es reemplazar el objeto de clave raíz de Microsoft Key Distribution Service (kdssvc.dll, también conocido como KDS) y todos los gMSA que usan el objeto de clave raíz KDS en peligro.

Más información

En un ataque correcto en una gMSA, el atacante obtiene todos los atributos importantes del objeto KDS Root Key y los Sid atributos y msds-ManagedPasswordID de un objeto gMSA.

El msds-ManagedPasswordID atributo solo está presente en una copia grabable del dominio. Por lo tanto, si se expone la base de datos de un controlador de dominio, solo el dominio que hospeda el controlador de dominio está abierto al ataque gMSA golden. Sin embargo, si el atacante puede autenticarse en un controlador de dominio de un dominio diferente en el bosque, es posible que el atacante tenga permisos suficientes para obtener el contenido de msds-ManagedPasswordID. A continuación, el atacante podría usar esta información para crear un ataque contra gMSA en dominios adicionales.

Para proteger dominios adicionales del bosque después de que se haya expuesto un dominio, debe reemplazar todos los gMSA del dominio expuesto antes de que el atacante pueda usar la información. Por lo general, no se conocen los detalles de lo que se expuso. Por lo tanto, se recomienda aplicar la resolución a todos los dominios del bosque.

Como medida proactiva, la auditoría se puede usar para realizar un seguimiento de la exposición del objeto KDS Root Key. Se puede colocar una lista de control de acceso del sistema (SACL) con lecturas correctas en el contenedor De claves raíz maestras, lo que permite auditar las lecturas correctas en el msKds-RootKeyData atributo de la msKds-ProvRootKey clase. Esta acción determina el paisaje de exposición del objeto con respecto a un ataque gMSA dorado.

Nota:

La auditoría solo ayuda a detectar un ataque en línea en los datos de clave raíz de KDS.

Puede considerar la posibilidad de establecer el ManagedPasswordIntervalInDays parámetro en 15 días o elegir un valor adecuado al crear una gMSA, ya que el ManagedPasswordIntervalInDays valor se convierte en de solo lectura después de crear una gMSA.

En caso de peligro, esta configuración puede reducir el siguiente tiempo de puesta en marcha.

Reducirá el número teórico de gMSA que se va a volver a crear entre la fecha de la copia de seguridad restaurada y el final de la exposición de la base de datos, o al menos, la duración de la ventana de riesgo hasta que se reviertan estos gMSA, si se mantiene con el escenario 1.

Este es un escenario de ejemplo:

1. Después de una exposición de la base de datos, se realiza la recuperación en "Día D".

2. La copia de seguridad restaurada es de D-15.

   Nota:

   D-15 significa el día que es 15 días antes del "Día D".

3. El valor de gMSA ManagedPasswordIntervalInDays es 15.

4. Las gMSA existen y han inscrito D-1.

5. Se han creado gMSA más recientes a partir de D-10.

6. El compromiso se produce en D-5 y algunos gMSA se han creado en esta fecha.

Estos son los resultados:

1. Las gMSA creadas entre D y D-5 no se preocupan^*.

2. Las gMSA creadas entre D-15 (copia de seguridad restaurada) y D-5 (peligro)^* deben volver a crearse o se deben asumir las ventanas de riesgo si puede esperar desde D+5 hasta D+10. Por ejemplo:

   • En D+5, se deben volver a crear gMSA creadas en D-10.
   • En D+10, se deben volver a crear gMSA creadas en D-5.

   ^*Depende de la hora exacta del compromiso o la copia de seguridad.

Esta es una escala de tiempo de ejemplo:

Para la depuración, puede revisar los identificadores de evento del registro de eventos System, Security, Directory Services y Security-Netlogon.

Para obtener más información sobre un riesgo, consulte Uso de recursos de seguridad de Microsoft y Azure para ayudar a recuperarse del riesgo de identidad sistémica.

Solución

Para resolver este problema, use uno de los siguientes enfoques, en función de su situación. Los enfoques implican la creación de un nuevo objeto de clave raíz de KDS y el reinicio del servicio de distribución de claves de Microsoft en todos los controladores de dominio del dominio.

Escenario 1: Tiene información confiable sobre qué información se expuso y cuándo

Si sabe que la exposición se produjo antes de una fecha determinada y esta fecha es anterior a la contraseña de gMSA más antigua que tiene, puede resolver el problema sin volver a crear las gMSA, como se muestra en el procedimiento siguiente.

El enfoque consiste en crear un nuevo objeto KDS Root Key desconocido para el atacante. Cuando los gMSA reviertan su contraseña, se moverán al uso del nuevo objeto KDS Root Key. Para corregir los gMSA que han rodado recientemente su contraseña mediante la clave raíz de KDS antigua, se requiere una restauración autoritativa para forzar una actualización de contraseña inmediatamente después de la restauración.

Nota:

• No es necesario reparar manualmente los gMSA que se crearon una vez finalizada la exposición de la base de datos de Servicios de dominio de Active Directory (AD DS). El atacante no conoce los detalles de estas cuentas y las contraseñas de estas cuentas se regenerarán en función del nuevo objeto KDS Root Key.
• Debe tener en cuenta el objeto gMSA en "modo de mantenimiento" hasta que se complete el procedimiento y omitir los posibles errores que se notifican con las cuentas del sistema, la seguridad, los servicios de directorio y Security-Netlogon registro de eventos.
• En la guía se supone que los gMSA son objetos secundarios del contenedor Cuentas de servicio administradas . Si ha movido las cuentas a contenedores primarios personalizados, debe ejecutar los pasos relacionados con el contenedor Cuentas de servicio administradas en gMSA en estos contenedores.
• Una restauración autoritativa revierte todos los atributos al estado en el que se encontraban en el momento de la copia de seguridad, incluidas las cuentas que pueden recuperar las credenciales de gMSA (PrincipalsAllowedToRetrieveManagedPassword).

En el dominio que contiene los gMSA que desea reparar, siga estos pasos:

1. Desconectar un controlador de dominio y aislarlo de la red.

2. Restaure el controlador de dominio a partir de una copia de seguridad que se creó antes de la exposición de la base de datos de AD DS.

   Si el intervalo de contraseña de los gMSA es mayor que la antigüedad de la copia de seguridad, puede decidir tolerar la ventana en la que sigue funcionando el material de clave anterior. Si no puede esperar tanto tiempo y la copia de seguridad anterior coincidente no tiene demasiadas gMSA, debe cambiar el plan al escenario 2.

3. Ejecute una operación de restauración autoritativa en el contenedor De cuentas de servicio administradas del dominio. Asegúrese de que la operación de restauración incluye todos los objetos secundarios de los contenedores que podrían estar asociados a este controlador de dominio. Este paso revierte el estado de la última actualización de contraseña. La próxima vez que un servicio recupere la contraseña, la contraseña se actualizará a una nueva basada en el nuevo objeto KDS Root Key.

4. Detenga y deshabilite el servicio de distribución de claves de Microsoft en el controlador de dominio restaurado.

5. En otro controlador de dominio, siga los pasos descritos en Creación de la clave raíz de KDS de Servicios de distribución de claves para crear un nuevo objeto de clave raíz de KDS.

   Nota:

   En el entorno de producción, debe esperar 10 horas para asegurarse de que la nueva clave raíz de KDS está disponible. Compruebe el EffectiveTime atributo para saber cuándo se podrá usar la nueva clave raíz de KDS.

6. Reinicie el servicio de distribución de claves de Microsoft en todos los controladores de dominio.

7. Cree una nueva gMSA. Asegúrese de que la nueva gMSA usa el nuevo objeto KDS Root Key para crear el valor del msds-ManagedPasswordID atributo.

   Nota:

   Este paso es opcional, pero permite validar que la nueva clave raíz de KDS está actualmente en uso y se usa en el servicio de distribución de claves de Microsoft.

8. Compruebe el msds-ManagedPasswordID valor de la primera gMSA que creó. El valor de este atributo son datos binarios que incluyen el GUID del objeto de clave raíz KDS coincidente.

   Por ejemplo, suponga que el objeto KDS Root Key tiene el siguiente .CN

   

   Una gMSA que se crea mediante este objeto tiene un msds-ManagedPasswordID valor similar al siguiente.

   

   En este valor, los datos GUID comienzan en el desplazamiento 24. Las partes del GUID están en una secuencia diferente. En esta imagen, las secciones roja, verde y azul identifican las partes reordenadas. La sección naranja identifica la parte de la secuencia que es la misma que el GUID original.

   Si la primera gMSA que creó usa la nueva clave raíz de KDS, todas las gMSA posteriores también usarán la nueva clave.

9. Deshabilite y detenga el servicio de distribución de claves de Microsoft en todos los controladores de dominio.

10. Vuelva a conectar y vuelva a poner en línea el controlador de dominio restaurado. Asegúrese de que la replicación funciona.

    Ahora, se replican la restauración autoritativa y todos los demás cambios (incluidos los gMSA restaurados).

11. Vuelva a habilitar e iniciar el servicio de distribución de claves de Microsoft en todos los controladores de dominio. Los secretos de los gMSA restaurados se implementarán y se crearán nuevas contraseñas en función del nuevo objeto de clave raíz de KDS a petición.

    Nota:

    Si las gMSA se restauran pero no se usan y tienen el PrincipalsAllowedToRetrieveManagedPassword parámetro rellenado, puede ejecutar el Test-ADServiceAccount cmdlet en la gMSA restaurada mediante una entidad de seguridad que pueda recuperar la contraseña. Si se necesita un cambio de contraseña, este cmdlet revertirá los gMSA a la nueva clave raíz de KDS.

12. Compruebe que todos los gMSA se han rodado.

    Nota:

    La gMSA sin el PrincipalsAllowedToRetrieveManagedPassword parámetro rellenado nunca se revertirá.

13. Elimine el objeto de clave raíz de KDS anterior y compruebe las replicaciones.

14. Reinicie el servicio de distribución de claves de Microsoft en todos los controladores de dominio.

Escenario 2: No conoce los detalles de la exposición del objeto clave raíz de KDS y no puede esperar a que las contraseñas se reviertan.

Si no sabe qué información se expuso o cuándo se expuso, dicha exposición podría formar parte de una exposición completa del bosque de Active Directory. Esto puede crear una situación en la que el atacante puede ejecutar ataques sin conexión en todas las contraseñas. En este caso, considere la posibilidad de ejecutar una recuperación de bosque o restablecer todas las contraseñas de cuenta. La recuperación de los gMSA en un estado limpio forma parte de esta actividad.

Durante el proceso siguiente, debe crear un nuevo objeto KDS Root Key. A continuación, use este objeto para reemplazar todos los gMSA de los dominios del bosque que usan el objeto de clave raíz de KDS expuesto.

Nota:

Los pasos siguientes son similares al procedimiento que se encuentra en Introducción con cuentas de servicio administradas de grupo. Sin embargo, hay algunos cambios importantes.

Siga estos pasos:

1. Deshabilite todos los gMSA existentes y márquelos como cuentas que se van a quitar. Para ello, para cada cuenta, establezca el userAccountControl atributo en 4098 (este valor combina marcas WORKSTATION_TRUST_ACCOUNT y ACCOUNTDISABLE (deshabilitadas ).

   Puede usar un script de PowerShell como este para establecer las cuentas:

    $Domain = (Get-ADDomain).DistinguishedName
    $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
    ForEach ($GMSA In $DomainGMSAs)
    {
        Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
    }
   

2. Use un único controlador de dominio y siga estos pasos:

   1. Siga los pasos descritos en Creación de la clave raíz de KDS de Servicios de distribución de claves para crear un nuevo objeto de clave raíz de KDS.

   2. Reinicie el servicio de distribución de claves de Microsoft. Una vez reiniciado, el servicio recoge el nuevo objeto.

   3. Realice una copia de seguridad de nombres de host DNS y nombres de entidad de seguridad de servicio (SPN) asociados a cada gMSA marcada para quitarse.

   4. Edite los gMSA existentes para quitar los SPN y los nombres de host DNS.

   5. Cree nuevas gMSA para reemplazar las gMSA existentes. También deben configurarse con los nombres de host DNS y los SPN que acaba de quitar.

      Nota:

      También debe revisar todas las entradas de permisos mediante los SID de gMSA eliminados directamente, ya que ya no se pueden resolver. Al reemplazar una entrada de control de acceso (ACE), considere la posibilidad de usar grupos para administrar entradas de permisos gMSA.

3. Compruebe los nuevos gMSA para asegurarse de que usan el nuevo objeto KDS Root Key. Para ello, siga estos pasos:

   1. Anote el CN valor (GUID) del objeto KDS Root Key.

   2. Compruebe el msds-ManagedPasswordID valor de la primera gMSA que creó. El valor de este atributo son datos binarios que incluyen el GUID del objeto de clave raíz KDS coincidente.

      Por ejemplo, suponga que el objeto KDS Root Key tiene el siguiente .CN

      

      Una gMSA que se crea mediante este objeto tiene un msds-ManagedPasswordID valor similar a la imagen.

      

      En este valor, los datos GUID comienzan en el desplazamiento 24. Las partes del GUID están en una secuencia diferente. En esta imagen, las secciones roja, verde y azul identifican las partes reordenadas. La sección naranja identifica la parte de la secuencia que es la misma que el GUID original.

      Si la primera gMSA que creó usa la nueva clave raíz de KDS, todas las gMSA posteriores también usarán la nueva clave.

4. Actualice los servicios adecuados para usar los nuevos gMSA.

5. Elimine los gMSA antiguos que usaron el antiguo objeto KDS Root Key mediante el siguiente cmdlet:

   $Domain = (Get-ADDomain).DistinguishedName
   $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
   ForEach ($GMSA In $DomainGMSAs)
   {
       Remove-ADObject "$GMSA" -Confirm:$False
   }
   

6. Elimine el objeto de clave raíz de KDS anterior y compruebe las replicaciones.

7. Reinicie el servicio de distribución de claves de Microsoft en todos los controladores de dominio.

Escenario 3: Renuncia de un administrador de dominio, no se ha robado información en ese momento y puede esperar a que las contraseñas se reviertan.

Si un miembro con privilegios elevados con administradores de dominio o derechos equivalentes renuncia, no hay ninguna prueba de la exposición de la clave raíz de KDS en ese momento y puede permitirse un período de tiempo para la puesta en marcha de contraseñas. No es necesario volver a crear los gMSA.

Como medida preventiva, se debe enrollar la clave raíz de KDS para evitar ataques posteriores a la explotación. Por ejemplo, un antiguo administrador de dominio ha resultado ser un no autorizado y ha guardado algunas copias de seguridad.

Se crea un nuevo objeto KDS Root Key y los gMSA se lanzarán de forma natural.

Nota:

Para ver un riesgo relacionado con un administrador de dominio, consulte El escenario 1 o el escenario 2 según lo expuesto y siga las actividades de corrección locales en "Uso de recursos de seguridad de Microsoft y Azure para ayudar a recuperarse del riesgo de identidad sistémica".

En el dominio que contiene los gMSA que desea implementar, siga estos pasos:

1. En un controlador de dominio, siga los pasos descritos en Creación de la clave raíz de KDS de Key Distribution Services para crear un nuevo objeto de clave raíz de KDS.

   Nota:

   En el entorno de producción, debe esperar 10 horas para asegurarse de que la nueva clave raíz de KDS está disponible. Compruebe el EffectiveTime atributo para saber cuándo se podrá usar la nueva clave raíz de KDS.

2. Reinicie el servicio de distribución de claves de Microsoft en todos los controladores de dominio.

3. Cree una nueva gMSA. Asegúrese de que la nueva gMSA usa el nuevo objeto KDS Root Key para crear el valor del msds-ManagedPasswordID atributo.

   Nota:

   Este paso es opcional, pero permite validar que la nueva clave raíz de KDS está actualmente en uso y se usa en el servicio de distribución de claves de Microsoft.

4. Compruebe el msds-ManagedPasswordID valor de la primera gMSA que creó. El valor de este atributo son datos binarios que incluyen el GUID del objeto de clave raíz KDS coincidente.

   Por ejemplo, suponga que el objeto KDS Root Key tiene el siguiente .CN

   

   Una gMSA que se crea mediante este objeto tiene un msds-ManagedPasswordID valor similar a la siguiente imagen.

   

   En este valor, los datos GUID comienzan en el desplazamiento 24. Las partes del GUID están en una secuencia diferente. En esta imagen, las secciones roja, verde y azul identifican las partes reordenadas. La sección naranja identifica la parte de la secuencia que es la misma que el GUID original.

   Si la primera gMSA que creó usa la nueva clave raíz de KDS, todas las gMSA posteriores también usarán la nueva clave.

5. En función de la siguiente sustitución de contraseñas, los secretos de los gMSA se implementarán de forma natural y se crearán nuevas contraseñas en función del nuevo objeto de clave raíz de KDS a petición.

   Nota:

   Si se han rodado las gMSA usadas, pero las gMSA sin usar con el mismo intervalo de lanzamiento no lo han hecho y tienen el PrincipalsAllowedToRetrieveManagedPassword parámetro rellenado, puede ejecutar el Test-ADServiceAccount cmdlet. Usa una entidad de seguridad que puede recuperar la contraseña de gMSA y, a continuación, este paso mueve la gMSA a la nueva clave raíz de KDS.

6. Compruebe que todos los gMSA se han rodado.

   Nota:

   La gMSA sin el PrincipalsAllowedToRetrieveManagedPassword parámetro nunca se revertirá.

7. Después de que todos los gMSA se hayan inscrito en el nuevo objeto KDS Root Key, elimine el objeto de clave raíz de KDS anterior y compruebe las replicaciones.

8. Reinicie el servicio de distribución de claves de Microsoft en todos los controladores de dominio.

Referencias

Introducción a las cuentas de servicio administradas de grupo

Aviso de declinación de responsabilidades sobre la información de contacto de terceros

Microsoft proporciona información de contacto de otros proveedores para ayudarle a encontrar información adicional sobre este tema. Dicha información de contacto puede cambiar sin notificación previa. Microsoft no garantiza la precisión de esta información de contacto de terceros.