Cómo recuperarse de un ataque Golden gMSA

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

Síntomas

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

Presentación del ataque 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 del servicio de distribución de claves de Microsoft (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 golden gMSA. Sin embargo, si el atacante puede autenticarse en un controlador de dominio de otro dominio del bosque, es posible que el atacante tenga permisos suficientes para obtener el contenido de msds-ManagedPasswordID. Después, 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 exponer un dominio, debe reemplazar todos los gMSA del dominio expuesto antes de que el atacante pueda usar la información. Normalmente, no conoce los detalles de lo que se ha expuesto. 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. Una lista de control de acceso del sistema (SACL) con lecturas correctas se puede colocar en el contenedor De claves raíz maestras, lo que permite la auditoría de lecturas correctas en el msKds-RootKeyData atributo de la msKds-ProvRootKey clase. Esta acción determina el panorama de exposición del objeto con respecto a un ataque gMSA golden.

Nota:

La auditoría solo ayuda a detectar un ataque en línea en los datos de la 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 la próxima hora gradual.

Reducirá el número teórico de gMSA que se 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 implementen estos gMSA, si se adhiere al escenario 1.

He aquí un escenario de ejemplo:

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

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

   Nota:

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

3. El valor de gMSA ManagedPasswordIntervalInDays es 15.

4. Existen gMSA 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.

He aquí los resultados:

1. Los gMSA creados entre D y D-5 no están interesados^*.

2. Los gMSA creados 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 de 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 del tiempo exacto de compromiso o copia de seguridad.

Esta es una escala de tiempo de ejemplo:

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

Para obtener más información sobre un riesgo, consulte Uso de los 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 enfoques siguientes, en función de su situación. Los enfoques implican crear un nuevo objeto de clave raíz KDS y reiniciar el 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 ha expuesto 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 reenvien su contraseña, pasarán a usar el nuevo objeto KDS Root Key. Para corregir gMSA que han inscrito 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 las gMSA creadas después de que finalice 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 considerar 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 registro de eventos System, Security, Directory Services y Security-Netlogon.
• En la guía se da por supuesto que las gMSA son objetos secundarios del contenedor de cuentas de servicio administradas. Si ha movido las cuentas a contenedores primarios personalizados, debe ejecutar los pasos relacionados con el contenedor de cuentas de servicio administradas en la gMSA de estos contenedores.
• Una restauración autoritativa revierte todos los atributos al estado en que estaban 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. Desconecte un controlador de dominio y aíslelo 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 las gMSA es mayor que la antigüedad de la copia de seguridad, puede decidir tolerar la ventana en la que el material de clave anterior sigue funcionando. Si no puede esperar tanto tiempo y la copia de seguridad anterior coincidente falta demasiados 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 último estado de 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 Crear la clave raíz KDS de servicios de distribución de claves para crear un nuevo objeto de clave raíz KDS.

   Nota:

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

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

7. Cree una gMSA nueva. 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 le permite validar que la nueva clave raíz 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 es datos binarios que incluyen el GUID del objeto KDS Root Key coincidente.

   Por ejemplo, supongamos 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 se encuentran en una secuencia diferente. En esta imagen, las secciones rojas, verdes y azules 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 KDS, todas las gMSA posteriores también usan 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 conectar 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 inicie el servicio de distribución de claves de Microsoft en todos los controladores de dominio. Los secretos de las gMSA restauradas se implementarán y se crearán nuevas contraseñas en función del nuevo objeto de clave raíz KDS a petición.

    Nota:

    Si se restauran los gMSA pero no se usan y tienen PrincipalsAllowedToRetrieveManagedPassword el 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 implementará las gMSA en la nueva clave raíz de KDS.

12. Compruebe que se han inscrito todos los gMSA.

    Nota:

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

13. Elimine el objeto de clave raíz 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 de objetos de clave raíz de KDS y no puede esperar a que se implemente la contraseña.

Si no sabe qué información se expone o cuándo se expone, tal 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 pueda ejecutar ataques sin conexión en todas las contraseñas. En este caso, considere la posibilidad de ejecutar una recuperación del bosque o restablecer todas las contraseñas de cuenta. La recuperación de las gMSA en un estado limpio forma parte de esta actividad.

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

Nota:

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

Siga estos pasos:

1. Deshabilite todas las gMSA existentes y marquelas 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 (deshabilitado).

   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 KDS de servicios de distribución de claves para crear un nuevo objeto de clave raíz 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 los nombres de host DNS y los nombres de entidad de seguridad de servicio (SPN) asociados a cada gMSA marcado 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 con los SID de gMSA quitados 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 de gMSA.

3. Compruebe las nuevas 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 es datos binarios que incluyen el GUID del objeto KDS Root Key coincidente.

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

      

      Una gMSA creada 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 se encuentran en una secuencia diferente. En esta imagen, las secciones rojas, verdes y azules 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 KDS, todas las gMSA posteriores también usan la nueva clave.

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

5. Elimine los gMSA antiguos que usaron el objeto de clave raíz de KDS anterior 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 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 a un administrador de dominio, no se ha robado información en el momento y puede esperar a que se implementen contraseñas.

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 el momento y puede permitirse un período de tiempo para la implementación de contraseñas. No es necesario volver a crear las gMSA.

Como medida preventiva, se debe inscribir la clave raíz KDS para evitar cualquier ataque posterior a la explotación. Por ejemplo, un administrador de dominio anterior ha resultado ser un no autorizado y ha mantenido algunas copias de seguridad.

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

Nota:

Para ver un riesgo relacionado con un administrador de dominio, consulte Escenario 1 o Escenario 2 según lo que se ha 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 KDS de servicios de distribución de claves para crear un nuevo objeto de clave raíz KDS.

   Nota:

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

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

3. Cree una gMSA nueva. 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 le permite validar que la nueva clave raíz 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 es datos binarios que incluyen el GUID del objeto KDS Root Key coincidente.

   Por ejemplo, supongamos 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 se encuentran en una secuencia diferente. En esta imagen, las secciones rojas, verdes y azules 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 KDS, todas las gMSA posteriores también usan la nueva clave.

5. En función del próximo lanzamiento de contraseñas, los secretos de las gMSA se revertirán naturalmente y se crearán nuevas contraseñas en función del nuevo objeto de clave raíz KDS a petición.

   Nota:

   Si los gMSA usados se han inscrito, pero los gMSA sin usar con el mismo intervalo de implementación no lo han hecho y tienen PrincipalsAllowedToRetrieveManagedPassword el 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 KDS.

6. Compruebe que se han inscrito todos los gMSA.

   Nota:

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

7. Una vez que todas las gMSA se hayan inscrito en el nuevo objeto KDS Root Key, elimine el objeto KDS Root Key antiguo 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. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la precisión de esta información de contacto de terceros.