Golden dMSA: ¿Qué es el bypass de autenticación dMSA?

Principales resultados

• Adi Malyanker, investigador de seguridad de Semperis, descubrió un fallo de diseño crítico en las cuentas de servicio gestionadas delegadas (dMSA) introducidas en Windows Server 2025.
• Dado que el fallo simplifica enormemente la generación de contraseñas por fuerza bruta, explotarlo es poco complejo.
• El ataque Golden dMSA permite a los atacantes saltarse la autenticación y generar contraseñas para todos los dMSA y gMSA y sus cuentas de servicio asociadas.
• La detección de la actividad de Golden dMSA requiere la configuración y auditoría manual de los registros, lo que dificulta su mitigación.
• Los investigadores de Semperis califican esta vulnerabilidad como MODERADA porque para explotarla, los atacantes deben poseer una clave raíz KDS disponible sólo para las cuentas con más privilegios: root Domain Admins, Enterprise Admins y SYSTEM.
• Sin embargo, este ataque puede ser de alto impacto, permitiendo el movimiento lateral entre dominios y el acceso persistente a todas las cuentas de servicios gestionados y sus recursos de forma indefinida.

Windows Server 2025 de Microsoft ofrece importantes innovaciones en materia de seguridad, entre las que destaca la introducción de las cuentas de servicio gestionadas delegadas (dMSA), diseñadas para revolucionar la gestión de las cuentas de servicio. A diferencia de las cuentas estáticas basadas en contraseñas, que pueden ser víctimas de ataques de «kerberoasting», las dMSA vinculan la autenticación directamente a los equipos autorizados en Active Directory (AD).

Este enfoque centrado en la máquina elimina el robo de credenciales al vincular la autenticación a la identidad del dispositivo en lugar de a contraseñas gestionadas por el usuario. Sólo las máquinas explícitamente autorizadas pueden acceder al dMSA.

Este artículo revela un nuevo ataque contra las cuentas de servicio gestionadas delegadas denominado ataque Golden DMSA. La técnica permite a los atacantes eludir la autenticación gestionada por máquina prevista y generar contraseñas para todas las dMSA asociadas sin conexión.

¿Qué es Golden dMSA?

Golden dMSA es un método de persistencia y escalado de privilegios que permite a los atacantes generar contraseñas para todas las dMSA -y cuentas de servicio gestionadas por grupo (gMSA)- y sus cuentas de servicio asociadas.

El ataque aprovecha un fallo de diseño crítico: una estructura que se utiliza para el cálculo de generación de contraseñas contiene componentes predecibles basados en el tiempo con sólo 1.024 combinaciones posibles, lo que hace que la generación de contraseñas por fuerza bruta sea computacionalmente trivial.

Este ataque puede ser utilizado tanto para la persistencia como para la escalada de privilegios en cualquier entorno AD con cuentas dMSA. Semperis califica esta vulnerabilidad como de riesgo moderado porque su ejecución depende de un compromiso parcial del bosque.

Siga leyendo para saber cómo descubrimos la vulnerabilidad que permite Golden dMSA, los detalles que encontramos tras el fallo de diseño,
y cómo puede detectar y mitigar la actividad de omisión de autenticación.

¿Cómo funciona un ataque Golden dMSA?

Después de que un atacante obtiene privilegios elevados dentro de un dominio, puede comprometer sistemáticamente todas las cuentas dMSA y gMSA a través de un ataque directo de cuatro fases.

Fase 1: Extracción del material de la clave raíz KDS (requisito previo para el ataque). El atacante vuelca el material criptográfico de la clave raíz de Key Distribution Services (KDS), la base de todas las contraseñas de cuentas de servicios gestionados.

Fase 2: Enumeración de las cuentas dMSA. En la fase 1, el usuario SYSTEM o Domain Admin no tiene permisos para enumerar dMSAs en otros dominios. En esta segunda fase, el atacante intenta, por fuerza bruta o utilizando LDAP, descubrir datos como sAMAccountName atributos e identificadores de seguridad (SID) en cuentas dMSA en el bosque AD.

Fase 3: Adivinar el ManagedPasswordID. A continuación, el atacante intenta identificar el ManagedPasswordId y hashes de contraseñas mediante adivinación selectiva.

Fase 4: Generación de contraseñas. Utilizando herramientas especializadas como GoldenDMSA, el atacante puede generar contraseñas válidas para cualquier gMSA o dMSA asociado a la clave comprometida.

Este proceso no requiere ningún acceso privilegiado adicional una vez obtenida la clave raíz KDS, lo que lo convierte en un método de persistencia especialmente peligroso.

El ataque pone de relieve el límite de confianza crítico de las cuentas de servicios gestionados. Dependen de claves criptográficas a nivel de dominio para su seguridad. Aunque la rotación automática de contraseñas proporciona una excelente protección contra los típicos ataques de credenciales, los administradores de dominio, los administradores DNS y los operadores de impresión pueden eludir por completo estas protecciones y poner en peligro todas las dMSA y gMSA del bosque.

¿Qué son las dMSA? Breve historia de las cuentas de servicio

Durante décadas, los administradores de Windows utilizaron cuentas de dominio normales para ejecutar servicios, un enfoque funcional pero defectuoso que evolucionó con la introducción de las cuentas de servicio. A diferencia de las cuentas de usuario interactivas que representan a personas reales, las cuentas de servicio existen únicamente para proporcionar un contexto de identidad para los procesos automatizados.

Las primeras cuentas de servicio se basaban en contraseñas estáticas que creaban pesadillas operativas. Coordinar los cambios de contraseña en varios equipos, servicios y aplicaciones a menudo provocaba interrupciones y resistencia a las buenas prácticas de seguridad.

Peor aún, las contraseñas estáticas permitían ataques devastadores. Los exploits de Kerberoasting permitían a los atacantes solicitar tickets de servicio y descifrar contraseñas fuera de línea, mientras que las credenciales débiles o inalteradas proporcionaban objetivos fáciles para la escalada de privilegios.

Desde entonces, Microsoft ha creado diferentes versiones de cuentas de servicio.

• Cuentas de servicio administradas (MSA). Windows Server 2008 R2 introdujo la rotación automática de contraseñas de 240 caracteres cada 30 días junto con la gestión automática de nombres principales de servicio (SPN). ¿El inconveniente? Las MSA se limitan a equipos individuales.
• Cuentas de servicio gestionadas de grupo (gMSA). Windows Server 2012 resolvió la limitación relativa al número de equipos, permitiendo compartir identidades de servicio entre clústeres, equilibradores de carga y servicios distribuidos, al tiempo que se mantenían las ventajas de seguridad de las MSA.
• Cuentas de servicio gestionadas delegadas (dMSA). La última innovación de Windows Server 2025 supone un cambio de la gestión centralizada de contraseñas a la autenticación vinculada al equipo, lo que representa un cambio fundamental en la seguridad de las cuentas de servicio.

Esta evolución de las cuentas tradicionales a las gMSA y a las dMSA crea una interesante superficie de ataque, que la técnica Golden dMSA explota aprovechando la base criptográfica compartida entre los sistemas gMSA y dMSA.

Cómo encuentran los atacantes los dMSA: Romper la barrera de la invisibilidad

Desde el punto de vista de un atacante, la capacidad de enumerar los dMSA como usuario sin privilegios es fundamental para la escalada de privilegios y el movimiento lateral. Para obtener la contraseña de un dMSA, es necesario conocer su nombre y su SID.

Sin embargo, uno de los retos más intrigantes a la hora de tratar con las dMSA es, en primer lugar, encontrar estas cuentas escurridizas.

Según la documentación de Microsoft, para crear dMSA, empezamos con el CreateDelegatedServiceAccount comando que Figura 1 espectáculos.

Ahora viene lo divertido. Intentemos visualizar nuestra cuenta DMSA-Demo recién creada utilizando Get-ADServiceAccount (Figura 2).

Aquí es donde nos encontramos con nuestro primer obstáculo. Un usuario con privilegios puede ver la cuenta sin problemas, pero un usuario sin privilegios no ve absolutamente nada: los resultados están vacíos (Figura 3). ¿Por qué? Todo se reduce a la configuración predeterminada de las listas de control de acceso (ACL) de la cuenta. Y, créeme, ningún administrador quiere meterse con ellas.

¿Notas algo sospechoso en la Figura 4? Los usuarios autenticados no pueden leer ningún dato de estas cuentas.

Entonces, ¿cómo puede un usuario sin privilegios acceder a la información sobre las cuentas dMSA?

Aquí es donde empieza el trabajo de detective. Después de innumerables investigaciones e intentos fallidos, descubrí que podemos construir una lista de potenciales SIDs y traducir cada uno a objetos NTAccount. (Usé C# para esta magia).

Bajo el capó, la función translate aprovecha estas potentes API Win32: LsaOpenPolicy y LsaLookupSids (Gráfico 5).

Los nombres de las funciones revelan su finalidad, pero la figura 6 muestra la documentación oficial de Microsoft para dejarlo muy claro.

Curiosamente, una herramienta de Impacket llamada lookupsid¹ utiliza exactamente la misma técnica, empleando hLsarOpenPolicy2 y hLsarLookupSids para enumerar los SID.

Ahora viene lo emocionante: veamos qué pasa cuando activamos estas funciones Win32 (Figura 7).

¡Bingo! Hemos recuperado todas y cada una de las cuentas del dominio, además de otros objetos con SID.

Este método funciona porque elude por completo el LDAP, sorteando así de forma efectiva esas ACL restrictivas. He aquí la genialidad técnica: LsaLookupSids y LsaOpenPolicy No se basa en absoluto en LDAP. En su lugar, el protocolo LSA se comunica a través de \PIPE\lsarpc como punto final RPC sobre SMB.

Pero espera, ¿cómo podemos identificar qué cuentas de esta enorme lista son dMSA?

Aquí está el truco: marcamos como sospechosas todas las cuentas que terminan en $. A continuación, eliminamos sistemáticamente las cuentas automáticas y las gMSA.

¡Y ya está! Ahora disponemos de un inventario completo de todos los dMSA del dominio.

Giro argumental: ¡esta técnica también funciona más allá de las fronteras de los dominios! Podemos enumerar los dMSA de otros dominios utilizando exactamente el mismo método.

Aquí tienes un descubrimiento extra.

Gracias a mis compañeros Andrea Pierini y Shai Laronne, hemos descubierto un enfoque alternativo basado en LDAP (figura 8).

¿La salsa secreta? Cuando iniciamos la búsqueda directamente desde el propio contenedor, podemos cazar estos tipos de cuenta específicos. Combinado con nuestro método anterior de enumeración de SID, podemos extraer la información del SID al tiempo que filtramos los gMSA y las cuentas informáticas(Figura 9).

Este doble enfoque nos proporciona múltiples vectores de ataque para el descubrimiento de dMSA, un cambio de juego para cualquier evaluación de seguridad.

¿Por qué la clave raíz KDS es fundamental para los ataques Golden dMSA?

Introducida por primera vez en Windows Server 2012, la clave raíz de KDS es la joya de la corona de la infraestructura gMSA de Microsoft. Piensa en ella como el cerebro criptográfico que hay detrás del Servicio de Distribución de Claves de Microsoft: el motor que genera y distribuye contraseñas para las cuentas gMSA.

La obtención de esta clave raíz es el primer paso crítico en la cadena de ataque, ya que permite a los atacantes calcular las contraseñas de cualquier gMSA del dominio sin conexión. Esta capacidad es devastadora porque los gMSAs están diseñados para que sus contraseñas sean rotadas automáticamente por el controlador de dominio (DC), haciéndolos parecer seguros a los administradores. Sin embargo, con la clave raíz KDS en la mano, un atacante puede derivar matemáticamente la contraseña actual para cualquier cuenta gMSA sin conectarse nunca más al DC.

Esto es lo que lo hace tan potente: la clave raíz KDS funciona como la llave maestra definitiva. A partir de ella, todas las contraseñas gMSA se derivan mediante un elegante proceso de derivación de claves.

Pero aún hay más. Microsoft ha ampliado recientemente la clave raíz KDS para controlar las cuentas dMSA.

Ahora la clave raíz KDS es el doble de valiosa para los atacantes, ya que desbloquea las contraseñas gMSA y dMSA.

La clave raíz KDS reside en el contexto de nomenclatura de la configuración (CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=,DC=), que se replica en todos los controladores de dominio (DC) con permisos de escritura del bosque desde el DC raíz del bosque, pero permanece oculta para los usuarios sin privilegios. Microsoft no se ha andado con rodeos en materia de seguridad en este caso. Las listas de control de acceso (ACL) de estas claves son increíblemente restrictivas (Figura 10) limitando el acceso sólo a las cuentas más privilegiadas: root Domain Admins, Enterprise Admins y SYSTEM.

Sin embargo, a pesar de estas férreas restricciones, estas preciadas claves pueden recuperarse de otros DC en todo el bosque, pero sólo con acceso a nivel de SISTEMA(Figura 11).

En este punto se podría pensar que tener permisos de SISTEMA en un DC disminuye la explotabilidad de Golden dMSA. Sin embargo, este es un único DC de todo el bosque, y el flujo de ataque cambia fundamentalmente el panorama de amenazas de un compromiso localizado a una puerta trasera persistente en todo el bosque.

Esto significa que aunque el acceso a SYSTEM en un DC ya representa una brecha significativa, la técnica Golden dMSA transforma esa brecha en una amenaza mucho más peligrosa y duradera al permitir al atacante mantener un acceso persistente a gMSAs, dMSAs y sus cuentas de servicio asociadas en todo el bosque, sin requerir una presencia continua en el DC comprometido.

Preste mucha atención a este detalle crítico: Las claves raíz KDS no tienen fecha de caducidad

Microsoft recomienda mantener una sola clave raíz de KDS por entorno.

Haz los cálculos. Teóricamente, después de comprometer una sola clave raíz KDS, un atacante podría generar contraseñas para todas las futuras cuentas dMSA y gMSA indefinidamente.

Durante mi investigación he descubierto algo aún más intrigante. Incluso en entornos con varias claves raíz de KDS, el sistema puede seguir utilizando la antigua clave raíz de KDS debido al almacenamiento en caché (a menos que reiniciemos el servicio KDS de una forma concreta). Esto significa que la clave original que hemos comprometido podría conservarse por el propio diseño de Microsoft, lo que crearía una puerta trasera persistente que podría durar años.

Esta decisión arquitectónica transforma una única extracción de clave con éxito en una ventaja estratégica a largo plazo para los atacantes, convirtiendo la clave raíz KDS en uno de los objetivos más valiosos de cualquier dominio de Windows.

Descifrando el código: De la gMSA a la generación de contraseñas dMSA

Ahora nos adentramos en el meollo del ataque: la extracción de los dMSA ManagedPasswordId atributo.

ManagedPasswordId es un atributo almacenado en AD que contiene los metadatos necesarios para derivar la contraseña actual de una MSA. Necesitamos obtener este atributo porque contiene los parámetros criptográficos esenciales —entre ellos, el identificador de la clave, la hora de creación y otros detalles de la derivación— que, junto con la clave raíz del KDS, permiten calcular matemáticamente la contraseña real de la gMSA.

Si esto te suena, tienes toda la razón. La magnífica investigación de Yuval Gordon sobre Ataques al Directorio Activo gMSA presentó al mundo Golden gMSA. Esta técnica de ataque consiste en extraer la clave raíz KDS de AD, consultar los gMSA disponibles junto con su SID y ManagedPasswordId y calcular contraseñas a partir de los datos.

Al investigar Golden dMSA, mi hipótesis era simple pero contundente: Microsoft podría haber reciclado el mismo código de gMSA a dMSA para la creación y renovación de contraseñas. Pero, ¿podríamos realmente reproducir el ataque Golden gMSA contra cuentas dMSA?

Aquí es donde nos topamos con nuestro primer gran obstáculo. Esas ACL restrictivas que habíamos descubierto anteriormente nos impedían por completo acceder a estos datos fundamentales sobre las cuentas de dMSA. Teníamos que profundizar más y ampliar nuestro algoritmo.

Ingeniería inversa de la estructura ManagedPasswordId

Para descifrar este enigma, empecé a investigar la ManagedPasswordId estructura en sí. Creé una nueva cuenta dMSA y extraje su ManagedPasswordID atributo.

Tras analizar la matriz de bytes y compararla en diferentes instancias, descubrí que contiene los componentes que muestra la Figura 12 .

Esta estructura me resultaba familiar. Es prácticamente idéntica a la de gMSA. ManagedPasswordID formato (Gráfico 13).

La figura 14 muestra el desglose completo de esta estructura, con estos componentes clave:

• Versión: Valor entero con valor decimal (1,0,0,0)
• Reservado: Valor entero con valor decimal de (75, 68, 83, 75)
• isPublicKey: Valor entero con valor decimal (2,0,0,0)
• L0Index: valor entero que representa una variable temporal (lo veremos más adelante)
• L1Index: valor entero que representa una variable temporal (lo veremos más adelante)
• L2Index: valor entero que representa una variable temporal (lo veremos más adelante)
• RootKeyIdentifier: Valor GUID construido a partir del ID de la clave raíz KDS.

El ámbito de RootKeyIdentifier puede construirse a partir de las claves raíz KDS (RKL es el id de la clave raíz KDS, es decir, f06c3c8d-b2c2-4cc6-9a1a-8b3b3c82b9f0), como Figura 15 espectáculos.

• cbUnknown: Valor entero con valor decimal (0, 0, 0, 0)
• cbNombreDominio: Valor entero que representa (longitud del nombre de dominio * 2) + 2.
• cbNombreBosque: Valor entero que representa (longitud del nombre del bosque * 2) + 2.
• NombreDominio: Nombre de dominio de la cuenta dMSA en este formato especial.
• ForestName: Nombre del bosque de la cuenta dMSA en este formato especial.

Observe algo en el cbDomainName y cbForestName: Multiplicamos por 2 y añadimos 2 porque se insertan bytes ASCII con valor 0 entre cada carácter. Así root.test se convierte en r.o.o.t…t.e.s.t.. en la estructura real.

Mediante el estudio de la Artículo de Microsoft Learn sobre msDS-ManagedPassword y el proveedor KDS de Microsoft KdsCli.dll (que implementa la mayor parte de la lógica de contraseñas), he trazado el flujo empezando por GetgMSAPasswordBlob()como Figura 16 espectáculos.

La lógica es elegante. Cuando el ManagedPasswordId si no existe o ha caducado, el sistema establece una nueva hora de inicio y llama a GetPasswordBasedOnTimestamp()como Figura 17 espectáculos.

Esto nos lleva a una de las observaciones más significativas de nuestra investigación. Los valores L0, L1 y L2 se generan en GetIntervalID()y luego se pasa a GetKey() al construir un nuevo BLOB clave (Figura 18).

A partir de esta observación, descubrí algo fundamental: los valores de L1 y L2 están limitados a 31 (incluido). No se trata solo de una teoría; queda confirmado tanto en la DLL (Figura 19) y el de Microsoft GetKey() documentación (Figura 20).

En GetPasswordBasedOnTimestamp() también será llamado cuando se produzca una renovación del ManagedPasswordId es necesario.

El descubrimiento decisivo

Ahora viene la revelación que cambia el juego.

Podemos predecir la mayor parte de ManagedPasswordID vector necesario para calcular las contraseñas gMSA y dMSA. Sabemos que L1Index y L2Index se limitan a valores que podemos obtener por fuerza bruta. El principal reto parecía ser L0Indexque, como entero de 4 bytes, podría tener miles de millones de valores potenciales.

Al profundizar en el algoritmo de Golden gMSA, descubrí que crea los siguientes objetos:

• L0Keyque contiene atributos de clave raíz KDS (Figura 21)
• L0KeyIdcalculado a partir de la hora actual
• GenerateKDFContext y GenerateDerivedKeyque derivan L1Key y L2Key vectores byte una vez (Figura 21) o un par de veces (Figura 22)

Esta es la idea clave.

• L0Keyid, L1Keyidy L2Keyid son totalmente temporales e independientes del usuario (como Figura 19 más arriba).
• El único valor controlado por el usuario es el ManagedPasswordId que proporcionamos junto con la clave raíz KDS, los nombres de dominio y bosque y el SID.

Aquí es donde todo encajó. Cuando rastreé dónde L0Index (del ManagedPasswordId) se utiliza realmente en el algoritmo, encontré las revelaciones que Figura 23 y Figura 24 espectáculo.

Es un detalle asombroso. L0index no se utiliza en absoluto desde el MsdsManagedPasswordId lo que significa que no importa el valor que utilicemos.

Adivinar contraseñas: Unirlo todo

Ahora podemos construir casi todo el ManagedPasswordId la última pieza necesaria para predecir contraseñas y hashes gMSA y dMSA. Dado que L0Index se ignora, y L1Index y L2Index debe estar comprendido entre 0 y 31 (ambos inclusive), sólo tenemos 32 × 32 = 1.024 vectores posibles para probar.

Comprobé esta conclusión calculando la contraseña correcta y el hash NTLM para cada vector; a continuación, realicé ataques de tipo «Pass the Hash» utilizando^{el smbclient2} de Impacket (Figura 25).

¡Éxito! Este método funcionó perfectamente para las cuentas gMSA. Pudimos predecir sus hashes dentro de 1.024 intentos sin necesidad de la específica ManagedPasswordId.

Pero aún así, no podía Pass the Hash con el hash de la contraseña de dMSA. Además, necesitábamos preguntarnos cómo podíamos aprovechar este ataque cuando los ataques Pass the Hash están mitigados desde este dominio.

Después de examinar los atributos de uno de mis dMSA, vi que requiere conexión con cifrado Kerberos tipo AES 256, como muestra la Figura 26 . (Recordarás que seguí la recomendación de Microsoft de aplicar AES 256 al crear un dMSA).

Intenté generar un hash AES 256 a partir de la contraseña del servicio. Después de algunos intentos agotadores, descubrí que los gMSA y los dMSA utilizan un formato de sal ligeramente diferente para el hash AES 256:

<Domain name in UPPER case>host<user's full UPN in lower case (without $)>

Por ejemplo:

ROOT.TESThostdmsa-demo8.root.test

Con este formato de sal, finalmente pude generar tickets Kerberos válidos para cuentas dMSA.

Trazado del flujo de ataque Golden dMSA

El diagrama de la Figura 27 resume el ataque Golden dMSA.

1. Comience con privilegios SYSTEM en uno de los DC del dominio o privilegios Enterprise Admin para volcar las claves raíz KDS.
2. Forzar los SID de las cuentas dMSA o utilizar consultas LDAP para identificar las cuentas objetivo.
3. Crear una lista de palabras que contenga todas las 1.024 posibles ManagedPasswordIds para este usuario en concreto.
4. Calcula la contraseña para cada par posible (claves raíz KDS, ManagedPasswordIds) y hash a NTLM/AES256.
5. Pruebe cada hash de contraseña mediante las técnicas Pass the Hash o Overpass the Hash.

Este ataque transforma las cuentas dMSA de objetivos aparentemente impenetrables en desafíos de fuerza bruta manejables, requiriendo sólo 1.024 intentos para descifrar cualquier contraseña dMSA en el dominio.

Cómo un ataque Golden dMSA elude la autenticación normal

En su documentación, Microsoft afirma que «el secreto de la dMSA no se puede recuperar ni encontrar en ningún otro lugar que no sea el servidor de dominio (DC)», lo que pone de relieve una diferencia fundamental entre los mecanismos de autenticación gMSA y dMSA. Con las gMSA, el proceso es sencillo. Una entidad se autentica y solicita directamente las credenciales (contraseña) de la gMSA; a continuación, recibe la contraseña real para fines de autenticación.

Los dMSA funcionan según un principio totalmente diferente. Deben autenticarse utilizando la identidad del equipo para obtener un ticket para el usuario del dMSA. La contraseña del dMSA nunca sale del DC. En su lugar, se utiliza para cifrar el ticket que se devuelve al equipo solicitante.

Para evitar los casos en los que un atacante roba el hash de la máquina y lo utiliza para solicitar un ticket, Microsoft recomienda utilizar Credential Guard. Esta mitigación crea una barrera sólida que debería detener en seco la mayoría de los ataques de robo de credenciales.

Pero aquí es donde el ataque «Golden dMSA» lo cambia todo. El «Golden dMSA» elude por completo las protecciones habituales de Credential Guard (Figura 28). Ya no seguimos las reglas habituales de autenticación.

En lugar de seguir el flujo de autenticación previsto por Microsoft, las credenciales dMSA se utilizan directamente mediante un ataque criptográfico (figura 29). Esto significa que:

• No se requiere ninguna identidad de máquina. No es necesario comprometer la máquina anfitriona.
• Credential Guard deja de ser relevante. Dado que no estamos robando credenciales de los equipos, esta protección no ofrece ninguna defensa.

Microsoft ha reconocido que: «A partir de la actualización de seguridad de Windows de abril (KB5055523), la función Credential Guard para cuentas de equipo protegidas queda desactivada temporalmente en Windows Server 2025 y Windows 11, versión 24H2. Esta función se ha desactivado debido a un problema con la rotación de contraseñas de equipo mediante Kerberos. La función permanecerá desactivada hasta que se disponga de una solución definitiva».

¿Cuál es el verdadero riesgo de Golden dMSA? Devastación de todo el bosque

Una vez que un atacante ha conseguido comprometer una cuenta dMSA utilizando la técnica «Golden dMSA», empieza lo divertido. No se trata solo de obtener acceso a una cuenta de servicio, sino de aprovechar ese punto de apoyo para llevar a cabo un movimiento lateral devastador. Además, esta técnica permite a los atacantes descifrar contraseñas y obtener permisos de cuentas de servicio que hayan iniciado o completado migraciones a la cuenta dMSA comprometida.

Aquí es donde el ataque se vuelve realmente aterrador desde el punto de vista de la seguridad. El ataque Golden dMSA no se ve limitado por los límites de los dominios. Opera a nivel de bosque. Una vez que comprometemos la clave raíz del KDS de cualquier dominio concreto dentro del bosque, podemos atacar y comprometer de forma sistemática todas las cuentas dMSA de todos los dominios de ese bosque.

Esto significa que una sola extracción exitosa de la clave raíz KDS se transforma en:

• Compromiso de cuentas entre dominios. Ningún límite de dominio puede detenernos.
• Recolección de credenciales en todo el bosque. Cada dMSA en cada dominio se vuelve vulnerable.
• Movimiento lateral ilimitado. Podemos saltar entre dominios a voluntad usando cuentas dMSA comprometidas.
• Acceso persistente. Sin caducidad de las claves KDS, este acceso podría durar indefinidamente.

El ataque se expande de forma exponencial. Lo que comienza como una única intrusión en un centro de datos (DC) acaba traduciéndose en el control total de todos los servicios protegidos por dMSA en todo el bosque empresarial. No se trata solo de una escalada de privilegios. Se trata de un dominio digital a escala de toda la empresa a través de una única vulnerabilidad criptográfica.

¿Qué es la herramienta Golden dMSA?

Para aprender cómo se explota esta técnica de ataque, tomamos la lógica del ataque y la incluimos en una herramienta llamada ^GoldenDMSA3. La herramienta incorpora los principios estructurales de la herramienta^GoldenGMSA4.

Un atacante puede utilizar la herramienta GoldenDMSA para enumerar todos los gMSAs, dMSAs y sus claves raíz KDS asociadas, utilizar ataques de fuerza bruta para obtener sus contraseñas y conseguir tickets para las cuentas. Un atacante con altos privilegios también puede utilizar la herramienta GoldenDMSA para volcar las claves raíz KDS.

Para demostrar la herramienta en acción, veamos una explotación entre dominios de un bosque.

Para empezar, el atacante se sitúa en un dominio llamado child.root.test (Gráfico 30) e intenta obtener dMSA de root.test (Figura 31).

A continuación, el atacante debe crear una lista de palabras (Figura 32) que se utilizará para el ManagedPasswordIds ataque de fuerza bruta.

Por último, lanzaremos un ataque de fuerza bruta con ayuda de la lista de palabras(Figura 33).

La contraseña está codificada en Base64 (Figura 34) porque podría incluir caracteres no imprimibles. Para comprobar la validez del ticket, creé un nuevo usuario —oculto en el controlador de dominio raíz— al que solo la cuenta dMSA podía acceder. Si conseguimos leer los datos del usuario, sabremos que el ticket que hemos generado es válido.

Cómo detectar Golden dMSA: descubrir indicadores ocultos

Por defecto, no se registra ningún evento de seguridad cuando una clave raíz KDS se ve comprometida. Para detectar ataques Golden dMSA, los defensores deben configurar manualmente una lista de control de acceso al sistema (SACL) en los objetos de clave raíz KDS para auditar el acceso de lectura a los objetos de clave raíz KDS. msKds-RootKeyData atributo.

Para ello, abra la herramienta Active Directory Editor Interface (ADSI Edit) y:

• Seleccione el contexto de nomenclatura Configuración
• Vaya a Servicios y, a continuación, haga clic en Servicio de distribución de claves de grupo
• Seleccione Claves Raíz Maestras y haga clic con el botón derecho del ratón en la clave raíz KDS correspondiente
• Vaya a la pestaña Seguridad, haga clic en el botón Avanzado
• Seleccione la pestaña Auditoría y configure una regla de auditoría para el acceso de lectura en Usuarios autenticados/Todos

Cuando este SACL está en su lugar, cualquier intento no autorizado de extraer los datos de la clave raíz KDS activará el evento de seguridad 4662 en el DC (Figura 35). Este evento mostrará un tipo de objeto de msKds-ProvRootKey y un nombre de cuenta que no es un DC, lo que indica una posible actividad maliciosa.

El nuevo indicador de seguridad DSP ayuda a detectar Golden dMSA

Como puede ver, la detección manual del compromiso de la clave raíz KDS es un reto para la mayoría de los equipos. Semperis ha proporcionado un nuevo módulo de protección de cuentas de servicio, una mejora de las capacidades Directory Services Protector DSP). El módulo incluye un indicador de seguridad llamado KDS root key ACL was modified, que busca modificaciones ACL en las claves raíz KDS(Figura 36) que podrían permitir a los atacantes leer esas claves y lanzar un ataque Golden dMSA.

Otros indicios a tener en cuenta

Además, los defensores deben:

• Supervisión de volúmenes anormales de solicitudes de autenticación AS-REQ dirigidas a la misma cuenta de servicio (identificable por las cuentas terminadas en $), especialmente cuando van seguidas de PREAUTH-FAILED (código de error 24). Este patrón puede indicar un intento de ataque Overpass the Hash.
• Busque solicitudes anormales de Ticket-Granting Ticket (TGT) de cuentas dMSA, especialmente cuando son lanzadas por cuentas de usuario.

Instantánea de Semperis

El ataque «Golden dMSA» aprovecha una vulnerabilidad criptográfica que puede socavar la última innovación de seguridad de Microsoft en Windows Server 2025. Esta técnica se aprovecha de la base arquitectónica de las cuentas de servicio gestionadas delegadas. El ataque aprovecha un fallo de diseño crítico: el ManagedPasswordId contiene componentes temporales predecibles con sólo 1.024 combinaciones posibles, lo que hace que la generación de contraseñas por fuerza bruta sea computacionalmente trivial.

Lo que hace que esto resulte especialmente devastador es su alcance, que abarca todo el entorno. Una sola extracción exitosa de la clave permite el movimiento lateral entre dominios y el acceso persistente a todas las cuentas de servicio gestionadas y a sus recursos de forma indefinida, ya que las claves raíz de KDS no tienen fecha de caducidad. La vulnerabilidad convierte la tecnología de cuentas de servicio más segura de Microsoft en una posible puerta trasera a nivel de toda la empresa, eludiendo protecciones modernas como Credential Guard y poniendo en tela de juicio de forma fundamental las supuestas ventajas de seguridad de la autenticación vinculada al equipo.

Divulgación

El problema se notificó inicialmente al Centro de respuesta de seguridad de Microsoft (MSRC) el 27 de mayo de 2025.

El 8 de julio de 2025, Microsoft respondió, en parte: «Si se dispone de los secretos utilizados para derivar la clave, es posible autenticarse como ese usuario. Estas funciones nunca se han concebido para proteger contra el compromiso de un controlador de dominio».

Más información sobre las amenazas a las cuentas de servicios gestionados

• BadSuccessor: Cómo Detectar y Mitigar la Escalada de Privilegios dMSA
• Cómo bloquear BadSuccessor
• Ataques al Directorio Activo gMSA

Notas finales

1. https://github.com/fortra/impacket/blob/master/examples/lookupsid.py
2. https://github.com/fortra/impacket/blob/master/examples/smbclient.py
3. https://github.com/Semperis/GoldenDMSA/tree/main
4. https://github.com/Semperis/GoldenGMSA

Descargo de responsabilidad

Este contenido se proporciona únicamente con fines educativos e informativos. Su objetivo es promover la concienciación y la corrección responsable de las vulnerabilidades de seguridad que puedan existir en los sistemas que usted posee o está autorizado a probar. El uso no autorizado de esta información con fines maliciosos, explotación o acceso ilegal está estrictamente prohibido. Semperis no respalda ni aprueba ninguna actividad ilegal y declina toda responsabilidad derivada del uso indebido del material. Además, Semperis no garantiza la exactitud o integridad del contenido y no asume ninguna responsabilidad por los daños derivados de su uso.