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 de seguridad, incluida la introducción de cuentas de servicio gestionadas delegadas (dMSA) diseñadas para revolucionar la gestión de cuentas de servicio. A diferencia de las cuentas estáticas basadas en contraseñas que pueden ser víctimas de ataques Kerberoasting, las dMSA vinculan la autenticación directamente a máquinas autorizadas 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 administradas por grupo (gMSA). Windows Server 2012 resolvió la limitación de múltiples máquinas, permitiendo identidades de servicio compartidas a través de clústeres, balanceadores de carga y servicios distribuidos, manteniendo los beneficios de seguridad de la MSA.
• Cuentas de servicio administradas delegadas (dMSA). La última innovación de Windows Server 2025 pasa de la gestión centralizada de contraseñas a la autenticación vinculada a máquinas, 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 la perspectiva de un atacante, la capacidad de enumerar dMSAs como un usuario sin privilegios es crucial para la escalada de privilegios y el movimiento lateral. Para obtener la contraseña de un dMSA, debes conocer su nombre y 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 dMSAs, empezamos con el archivo CreateDelegatedServiceAccount comando que Figura 1 espectáculos.

Ahora viene la parte divertida. Intentemos mostrar 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 obtiene absolutamente nada: resultados vacíos(Figura 3). ¿Por qué? Todo se reduce a los valores predeterminados en 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? Tanto los usuarios autenticados como Everyone están completamente bloqueados para leer cualquier 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 delatan su finalidad, pero la Figura 6 muestra la documentación oficial de Microsoft para que quede meridianamente claro.

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

Ahora viene la parte emocionante: Veamos qué ocurre cuando liberamos estas funciones Win32(Figura 7).

¡Lotería! Hemos recuperado todas las cuentas del dominio, además de otros objetos con SID.

Este método tiene éxito porque elude completamente LDAP, saltándose eficazmente esas ACL restrictivas. Aquí está la belleza técnica: LsaLookupSids y LsaOpenPolicy no se basan en LDAP en absoluto. 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á la parte inteligente: Marcamos todas las cuentas que terminan en $ como sospechosas. Luego eliminamos sistemáticamente las cuentas de máquinas y las gMSA.

¡Voilà! Nos queda 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.

He aquí un descubrimiento extra.

Gracias a mis colegas 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 KDS es la joya de la corona de la infraestructura gMSA de Microsoft. Piense en ella como el cerebro criptográfico detrás del servicio de distribución de claves de Microsoft, el motor que genera y distribuye las contraseñas para los 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 la hace tan poderosa: La clave raíz KDS funciona como la clave maestra definitiva. A partir de ella, se derivan todas las contraseñas gMSA 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 del KDS suele residir en el DC raíz del bosque, el inmueble más protegido de AD. Microsoft no estaba jugando con la seguridad aquí. Las ACL de estas claves son increíblemente restrictivas(Figura 10) y limitan el acceso únicamente a las cuentas más privilegiadas: administradores de dominio raíz, administradores de empresa 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

La recomendación de Microsoft es mantener sólo una clave raíz 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.

He descubierto algo aún más intrigante durante mi investigación. Incluso en entornos con múltiples claves raíz KDS, el sistema utiliza sistemáticamente la primera clave raíz KDS (la más antigua) por razones de compatibilidad. Esto significa que la clave original que hemos comprometido podría ser preservada por el diseño de Microsoft, creando 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 metemos de lleno en el meollo del ataque: la extracción del dMSA. ManagedPasswordId atributo.

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

Si esto le resulta familiar, tiene toda la razón. La gran 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 encontramos con nuestro primer gran obstáculo. Esas ACL restrictivas que descubrimos antes nos impiden completamente leer estos datos críticos en las cuentas dMSA. Necesitábamos profundizar 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 no existe o expira, 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 crucial: Los valores L1 y L2 están limitados a 31 (inclusive). Esto no es sólo teoría; está confirmado tanto en la DLL (Figura 19) y 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 estos 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)

Aquí está la 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.

Puse a prueba esta conclusión calculando la contraseña correcta y el hash NTLM para cada vector, y luego intenté ataques 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 dMSA no puede recuperarse ni encontrarse en ningún otro lugar que no sea el 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, y luego recibe la contraseña real para autenticarse.

Los dMSA funcionan según un principio totalmente distinto. Deben autenticarse utilizando la identidad de la máquina para obtener un ticket para el usuario dMSA. La contraseña del dMSA nunca sale del DC. En su lugar, se utiliza para cifrar el ticket que se devuelve a la máquina 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. Golden dMSA elude completamente las protecciones normales de Credential Guard(Figura 28). Ya no estamos jugando con las reglas normales de autenticación.

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

• No se requiere la identidad de la máquina. No necesitamos comprometer la máquina anfitriona.
• Credential Guard se vuelve irrelevante. Dado que no estamos robando credenciales de la máquina, esta protección ofrece cero defensa.

Microsoft ha reconocido que, "a partir de la actualización de seguridad de Windows de abril(KB5055523), las cuentas de máquina protegidas por Credential Guard están temporalmente deshabilitadas en Windows Server 2025 y Windows 11, versión 24H2. Esta función se ha deshabilitado debido a un problema con la rotación de contraseñas de máquina mediante Kerberos. La característica permanece deshabilitada hasta que esté disponible una solución permanente".

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

Una vez que un atacante ha logrado comprometer una cuenta dMSA utilizando la técnica Golden dMSA, comienza la verdadera diversión. No se trata sólo de obtener acceso a una cuenta de servicio. Se trata de aprovechar ese punto de apoyo para un movimiento lateral devastador. Además, esta técnica permite a los atacantes descifrar contraseñas y obtener permisos de cuentas de servicio que han iniciado y completado migraciones al dMSA comprometido.

Aquí es donde el ataque se vuelve realmente aterrador desde el punto de vista de la seguridad. El ataque Golden dMSA no está limitado por los límites del dominio. Opera a nivel de bosque. Una vez que comprometemos la clave raíz KDS de cualquier dominio dentro del bosque, podemos sistemáticamente atacar y comprometer cada cuenta dMSA a través de todos los dominios en 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 escala exponencialmente. Lo que empieza como el compromiso de un DC escala a la posesión de cada servicio protegido por dMSA en todo un bosque empresarial. No es sólo una escalada de privilegios. Es el dominio digital 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, he creado un nuevo usuario -oculto en el DC raíz- que sólo la cuenta dMSA puede leer. Si podemos leer correctamente los datos del usuario, sabremos que el ticket 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 explota la base arquitectónica de las cuentas de servicio gestionadas delegadas. El ataque aprovecha un fallo de diseño crítico: la 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 lo hace especialmente devastador es su alcance en todo el bosque. 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 sus recursos de forma indefinida, ya que las claves raíz KDS no tienen fecha de caducidad. La vulnerabilidad transforma la tecnología de cuentas de servicio más segura de Microsoft en una potencial puerta trasera para toda la empresa, eludiendo protecciones modernas como Credential Guard y desafiando fundamentalmente los supuestos beneficios de seguridad de la autenticación vinculada a máquinas.

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 dispone de los secretos utilizados para derivar la clave, puede autenticarse como ese usuario. Estas características nunca han sido pensadas para proteger contra un 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.