BadSuccessor: Explotación de dMSA para derivar privilegios en Active Directory
Resumen ejecutivo
Yuval Gordon, investigador de Akamai, descubrió una vulnerabilidad de derivación de privilegios en Windows Server 2025 que permite que los atacantes pongan en peligro a cualquier usuario de Active Directory (AD).
El ataque aprovecha la función de cuenta de servicio administrada delegada (dMSA, del inglés "delegated Managed Service Account") que se introdujo en Windows Server 2025, funciona con la configuración predeterminada y es muy fácil de implementar.
Es probable que este problema afecte a la mayoría de las organizaciones que dependen de AD. En el 91 % de los entornos examinados, encontramos usuarios que no pertenecían al grupo de administradores de dominio y que tenían los permisos necesarios para realizar este ataque.
Aunque Microsoft afirma que planea solucionar este problema en el futuro, actualmente no hay ningún parche disponible. Por lo tanto, las organizaciones deben tomar otras medidas proactivas para reducir su exposición a este ataque. Microsoft ha revisado nuestros resultados y ha aprobado la publicación de esta información.
En esta entrada del blog, proporcionamos todos los detalles del ataque, así como estrategias de detección y mitigación.
Contenido
Introducción
En Windows Server 2025, Microsoft introdujo las cuentas de servicio administradas delegadas (dMSA). Una dMSA es un nuevo tipo de cuenta de servicio en Active Directory (AD) que amplía las capacidades de las cuentas de servicio gestionadas por grupo (gMSA, del inglés "group Managed Service Accounts"). Una característica clave de las dMSA es la capacidad de migrar cuentas de servicio no gestionadas existentes convirtiéndolas a la perfección en dMSA.
Mientras explorábamos el funcionamiento interno de las dMSA de AD, descubrimos algo inesperado. A primera vista, el mecanismo de migración parecía una solución clara y bien diseñada. Pero al analizarlo de forma más detallada, algo sobre cómo funcionaba llamó nuestra atención.
A medida que fuimos profundizando, encontramos una sorprendente ruta de derivación: Al explotar las dMSA, los atacantes pueden apropiarse de cualquier entidad dentro del dominio. Todo lo que un atacante necesita para llevar a cabo este ataque es un permiso benigno en cualquier unidad organizativa (OU) del dominio, un permiso que a menudo pasa desapercibido.
Y lo mejor es que el ataque funciona de forma predeterminada: su dominio no necesita utilizar las dMSA en absoluto. Siempre que exista la característica, y existe en cualquier dominio con al menos un controlador de dominio (DC) de Windows Server 2025, estará disponible.
En esta entrada del blog se explica cómo descubrimos esta vulnerabilidad, cómo funciona el ataque y qué puede hacer para detectarlo o prevenirlo.
¿Qué es una dMSA?
Antes de profundizar en los ataques, es importante comprender qué son realmente las dMSA y cómo se supone que deben funcionar.
Normalmente, una dMSA se crea para reemplazar una cuenta de servicio heredada existente. Para habilitar una transición sin fisuras, una dMSA puede "heredar" los permisos de la cuenta heredada mediante un proceso de migración. Este flujo de migración vincula estrechamente la dMSA a la cuenta reemplazada; es decir, la cuenta original que deben reemplazar. En ese flujo, y los permisos que se conceden durante el proceso, es donde las cosas se ponen interesantes.
Flujo de migración de una dMSA
El proceso de migración de una dMSA se puede desencadenar llamando al nuevo cmdlet Start-ADServiceAccountMigration. Internamente, llama a una nueva operación rootDSE de LDAP denominada migrateADServiceAccount, que obtiene los siguientes argumentos:
El nombre distintivo (DN) de la dMSA
El DN de la cuenta reemplazada
Una constante correspondiente a StartMigration
El estado de migración de una dMSA viene determinado por el atributo msDS-DelegatedMSAState, un nuevo atributo que determina el estado actual de la dMSA. Actualmente no hay ninguna documentación oficial sobre el atributo msDS-DelegatedMSAState, por lo que la siguiente tabla se basa en nuestro propio análisis de comportamiento y experimentación.
Valor |
Significado |
0 |
Desconocido (posiblemente desactivado, pero no está confirmado) |
1 |
Migración en curso |
2 |
Migración completada |
3 |
dMSA independiente (sin migración) |
Valores de migración de msDS-DelegatedMSAState y significados relacionados.
Junto con este atributo, se utilizan otros atributos destacados durante el proceso de migración.
En el objeto dMSA:
msDS-GroupMSAMembership: contiene una lista de las entidades autorizadas para utilizar esta dMSA
msDS-ManagedAccountPrecededByLink: DN de la cuenta reemplazada
En el objeto de cuenta reemplazada:
msDS-SupersededManagedAccountLink: DN de la dMSA "sucesora"
msDS-SupersededServiceAccountState: el mismo significado que msDS-DelegatedMSAState, especificando el estado de migración de la cuenta original
Al activar una migración, la operación realiza los siguientes cambios:
Establece msDS-DelegatedMSAState en 1 (migración en curso)
Actualiza entSecurityDescriptor de la dMSA para conceder a la cuenta reemplazada:
Permisos de lectura
Acceso de escritura al atributo msDS-GroupMSAMembership
Establece el valor de msDS-ManagedAccountPrecededByLink de la dMSA para que haga referencia a la cuenta reemplazada
Establece el valor de msDS-SupersededManagedAccountLink de la cuenta reemplazada para que haga referencia a la dMSA
Establece el valor de msDS-SupersededServiceAccountState de la cuenta reemplazada en 1
En este punto, la dMSA se encuentra en un estado de "migración en curso". Aún no es totalmente funcional, pero ahora es consciente de qué sistemas siguen utilizando la cuenta de servicio antigua.
Una vez que se ha emitido el comando Complete-ADServiceAccountMigration, sucede lo siguiente:
La dMSA hereda configuraciones clave como SPN, configuración de delegación y otros atributos sensibles de la cuenta reemplazada
La cuenta reemplazada se desactiva
msDS-DelegatedMSAState y msDS-SupersededServiceAccountState se establecen en 2 (migración completada)
La migración se ha completado y cualquier servicio que dependía de la cuenta reemplazada utilizará ahora la dMSA para la autenticación.
Autenticación de la dMSA
Ahora que conocemos el proceso de creación y migración de las dMSA, es el momento de centrarnos en cómo funciona la autenticación, los cambios introducidos para admitir las dMSA y cómo estos cambios hacen que el proceso de migración sea perfecto.
Para facilitar la comprensión, examinemos la cuenta de servicio svc_sql heredada, que se utiliza para ejecutar un servicio en el servidor SQL_SRV$. Siempre que el servicio sea necesario para acceder a los recursos del dominio, la autenticación normal se realiza mediante la cuenta svc_sql (Figura 1).
Fig. 1: Legacy service account authentication flow
Autenticación durante la migración
Ahora, cambiamos la cuenta de servicio a una nueva dMSA llamada DMSA$ y activamos una migración. Durante el periodo de migración, cuando el servicio en SQL_SRV$ se autentica como svc_sql, el flujo de autenticación se modifica ligeramente.
El cliente envía un AS-REQ para autenticarse como svc_sql
El Centro de distribución de claves (KDC) devuelve un AS-REP que contiene un campo adicional: KERB-SUPERSEDED-BY-USER (este campo incluye el nombre y el dominio de la nueva dMSA DMSA$)
Si el host admite las dMSA (Windows Server 2025 o Windows 11 24H2) y tiene habilitada la autenticación de dMSA:
Extraiga el nombre DMSA$
Realice una consulta LDAP en DMSA$ para recuperar los siguientes atributos:
msDS-GroupMSAMembership
distinguishedName
objectClass
Puesto que el servicio se está ejecutando en SQL_SRV$ como vc_sql, la autenticación en sí activa una solicitud de modificación de LDAP desde svc_sql, que agrega SQL_SRV$ a la lista de entidades a las que se permite recuperar la contraseña de DMSA$ (Figura 2).
Esto es posible porque, durante el proceso de migración, se concedió a svc_sql acceso de escritura al atributo msDS-GroupMSAMembership en la dMSA, un cambio que le permite autorizar a su equipo host para que acceda a las credenciales de la cuenta.
Fig. 2: Kerberos authentication flow during dMSA migration
Esta concesión de permisos sin fisuras garantiza que, cuando se complete la migración, cada máquina que haya utilizado anteriormente svc_sql aparecerá en el atributo msDS-GroupMSAMembership de DMSA$, lo que le permite autenticarse como la dMSA.
Autenticación tras la finalización de la migración
Una vez completada la migración (a través de Complete-ADServiceAccountMigration), el comportamiento cambia de nuevo.
Cuando el cliente intenta autenticarse como svc_sql enviando un AS-REQ, ya no recibe un AS-REP
En su lugar, el DC responde con un mensaje KRB-ERROR, indicando que svc_sql está desactivada
El mensaje KRB-ERROR contendrá el campo KERB-SUPERSEDED-BY-USER, lo que permitirá al cliente reconocer que svc_sql se ha migrado y volver a intentar la autenticación utilizando DMSA$ (Figura 3).
Fig. 3: Kerberos authentication flow after the dMSA migration is completed
SQL_SRV$ (y cualquier otra máquina que anteriormente confiaba en svc_sql) ahora cambiará de forma transparente al uso de DMSA$.
Comportamiento inesperado
Un aspecto interesante de la autenticación Kerberos de la dMSA implica su Privilege Attribute Certificate (PAC).
Al autenticarse, Kerberos incrusta un PAC en vales, una estructura que los servicios utilizan para determinar el nivel de acceso de un cliente. En el vale de concesión de vales (TGT) estándar, el PAC incluye los SID de los usuarios y de todos los grupos de los que forman parte.
Sin embargo, al iniciar sesión con una dMSA, hemos observado algo inesperado.
El PAC incluía no solo el SID de las dMSA, sino también los SID de la cuenta de servicio reemplazada y de todos sus grupos asociados.
Explotación del proceso de migración de la dMSA para la derivación de privilegios
Después de la migración, el KDC otorga a la dMSA todos los permisos de la cuenta original (reemplazada).
Desde el punto de vista del diseño, esto tiene sentido. El objetivo es proporcionar una experiencia de migración sin fisuras en la que la nueva cuenta se comporte exactamente como la que reemplaza: los mismos SPN, las mismas delegaciones y las mismas pertenencias a grupos.
Sin embargo, desde la perspectiva de un investigador de seguridad, este tipo de comportamiento destaca inmediatamente. Cuando vimos un sistema que copiaba automáticamente los privilegios de una cuenta a otra, sin necesidad de realizar una reconfiguración manual, iniciamos una investigación en profundidad: ¿Cómo decide desde qué cuenta va a copiar? ¿Se puede influir en eso? ¿Se puede explotar?
Este tipo de preguntas nos llevó directamente a un descubrimiento clave. Este interesante comportamiento de la herencia del PAC parece estar controlado por un único atributo: msDS-ManagedAccountPrecededByLink.
El KDC se basa en este atributo para determinar quién está "reemplazando" la dMSA: cuando una dMSA se autentica, el PAC se crea basándose únicamente en este enlace.
Ha llegado el momento de pensar como un atacante
¿Cómo se ve esto desde la perspectiva de un atacante? Vamos a explorar un posible escenario de ataque y ver hasta dónde podría llegar un atacante con esta característica.
Nuestra primera idea fue utilizar una dMSA para crear un ataque primitivo de robo de cuentas. Si asumimos que tenemos permisos sobre una cuenta de usuario, ¿podríamos "migrar" sus permisos a una nueva dMSA para explotarlos sigilosamente? Parece ser que este es un enfoque correcto. Todo lo que tenemos que hacer es:
Crear una dMSA
Iniciar y completar la migración entre el usuario de destino y la dMSA mediante la operación migrateADServiceAccount rootDSE
Autenticarse como la dMSA: obtener todos los permisos del usuario de destino
El único problema es que no funciona.
Incluso si controlamos completamente tanto la dMSA como la cuenta reemplazada, no podemos realizar una migración, ya que la operación migrateADServiceAccount está restringida, por lo que sabemos, a los administradores de dominio. La Figura 4 muestra un ejemplo de un intento frustrado.
Fig. 4: A failed attempt to use a dMSA to create an account takeover primitive
A continuación, examinamos otra idea. Evidentemente, necesitamos algo complejo, creativo y extremadamente técnico. Necesitamos explorar comportamientos indocumentados, tal vez incluso llevar a cabo una ingeniería inversa de alguna parte del KDC… o simplemente podríamos establecer dos atributos.
Aunque no podemos realizar directamente una migración, podemos "simular" muy fácilmente una: simplemente tenemos que establecer los siguientes atributos directamente en el objeto dMSA.
Escribir el DN de la cuenta de destino en msDS-ManagedAccountPrecededByLink
Establezca msDS-DelegatedMSAState en el valor 2 (migración completada)
A partir de este momento, cada vez que nos autenticamos como la dMSA, el KDC crea el PAC utilizando los SID de la cuenta vinculada en el atributo msDS-ManagedAccountPrecededByLink, lo que nos otorga efectivamente los permisos completos de la cuenta reemplazada.
Presentamos BadSuccessor
Un hecho interesante acerca de esta técnica de "migración simulada" es que no requiere ningún permiso sobre la cuenta reemplazada. El único requisito son los permisos de escritura sobre los atributos de una dMSA. Cualquier dMSA.
Una vez que hemos marcado una dMSA como precedida por un usuario, el KDC asume automáticamente que tuvo lugar una migración legítima y otorga automáticamente a nuestra dMSA todos los permisos que tenía el usuario original, como si fuéramos su sucesor legítimo.
Pero, seguramente, esto no funcionaría para las cuentas con privilegios altos, ¿verdad? Pues...
Además, esta técnica, que denominamos "BadSuccessor", funciona en cualquier usuario, incluidos los administradores de dominio (Figura 5). Permite a cualquier usuario que controle un objeto dMSA controlar todo el dominio. Eso es todo lo que se necesita. Sin migración real. Sin verificación. Sin supervisión.
Fig. 5: Full attack flow, showing all steps needed to have a BadSuccessor
Explotación de las dMSA: desde privilegios bajos hasta el control de dominios.
En este punto, puede que esté pensando: "Bueno, no estoy usando la dMSA en mi entorno, así que esto no me afecta". Puede que este no sea el caso.
Imaginemos un escenario de explotación: un atacante obtiene el control de una dMSA existente y utiliza este acceso para realizar el ataque BadSuccessor. Pero en realidad hay otro escenario, que probablemente estará disponible para los atacantes con mucha más frecuencia: un atacante crea una nueva dMSA.
Cuando un usuario crea un objeto en AD, tiene permisos completos sobre todos sus atributos. Por lo tanto, si un atacante puede crear una nueva dMSA, puede explotar todo el dominio.
Normalmente, cuando se crea una dMSA mediante el cmdlet New-ADServiceAccount, se almacena en el contenedor de cuentas de servicio gestionadas. Aunque es posible que los usuarios tengan acceso a este contenedor, solo los grupos de Active Directory con privilegios integrados tienen permisos sobre él de forma predeterminada. Por lo tanto, no es muy probable que podamos escribir en este contenedor.
Sin embargo, las dMSA no están restringidas al contenedor de cuentas de servicio gestionadas; también se pueden crear en cualquier OU normal. Cualquier usuario que tenga los derechos para crear msDS-DelegatedManagedServiceAccount o para crear todos los objetos secundarios en cualquier OU puede crear una dMSA.
Creación de la dMSA
Permitir a los usuarios crear objetos en una OU es una configuración bastante común. Dado que esta capacidad se considera benigna, no es probable que los usuarios con este privilegio se supervisen y refuercen de manera adecuada.
Para crear la dMSA, primero localizamos una OU en la que tenemos privilegios. Afortunadamente, alguien ha creado una OU denominada "temp" en nuestro entorno de ejemplo y ha otorgado a nuestro usuario sin privilegios permisos "débiles" para crear todos los objetos secundarios (Figura 6).
Fig. 6: Example of required privileges on an OU
A continuación, podemos usar esos permisos para crear una dMSA mediante el cmdlet New-ADServiceAccount. Como se muestra en la Figura 7, aunque el usuario sin privilegios no puede crear una dMSA en el contenedor MSA predeterminado, podemos utilizar el argumento path para crear la dMSA en la OU accesible.
Fig. 7: Creating the dMSA in an allowed location using the New-ADServiceAccount PowerShell cmdlet
Ahora somos los felices propietarios de una dMSA recién creada y poco funcional. Como propietario creador, podemos concedernos permiso sobre el objeto, incluido el acceso de escritura en ambos atributos que vamos a utilizar para este ataque, que podemos modificar de la siguiente manera:
msDS-ManagedAccountPrecededByLink: establezca esta opción en el DN de cualquier usuario o equipo: controladores de dominio, miembros de administradores de dominio, usuarios protegidos e, irónicamente, incluso cuentas marcadas como "la cuenta es sensible y no se puede delegar"
msDS-DelegatedMSAState: establezca este valor en 2 para simular una migración completa (Figura 8)
Fig. 8: Modifying attributes to mimic successful migration
Como hemos mencionado, este ataque parece funcionar en todas las cuentas de AD. No hemos podido encontrar ninguna configuración que impida que una cuenta se utilice como destino reemplazado.
Obtención de un TGT para la dMSA
Una forma de autenticarse con nuestra dMSA sería crear un servicio y configurarlo para que se ejecute con la cuenta dMSA. Se puede hacer, pero no es fácil. Afortunadamente, gracias a una gran solicitud de extracción de Joe Dibley, Rubeus ahora admite la autenticación de la dMSA (Figura 9), lo que significa que podemos utilizarla para solicitar un TGT para nuestro dMSA:
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<TGT del equipo>
Fig. 9: Requesting TGT for the new dMSA using Rubeus
dMSA → Administrador de dominio
Para este ejemplo, nos centramos en la cuenta de administrador integrada. Con Wireshark, inspeccionamos el PAC del vale que recibimos para nuestra dMSA (Figura 10), que incluía:
RID de dMSA (1137)
RID de la cuenta reemplazada (500 — Administrador)
Todas las pertenencias a grupos de la cuenta reemplazada (512 — Administradores de dominio, 519 — Administradores de organización)
Fig. 10: dMSA’s PAC that includes the Administrator’s groups’ RIDs
Esto es todo lo que el controlador de dominio necesita para tratarnos como el heredero legítimo. Recuerde: no es necesario realizar cambios en la pertenencia al grupo, no es necesario tocar el grupo de administradores de dominio ni escribir LDAP sospechoso en la cuenta con privilegios real.
Con solo dos cambios de atributo, un humilde nuevo objeto se coronará como sucesor, y el KDC no valida la legitimidad del enlace predecesor; si el vínculo está ahí, los privilegios se conceden. No cambiamos la pertenencia a un solo grupo, no elevamos ninguna cuenta existente ni activamos ninguna alerta de elevación de privilegios tradicional.
Demostración: flujo de ataque de principio a fin
Vea este vídeo para obtener una demostración completa del ataque en acción.
Demostración de la explotación de las dMSA para derivar privilegios en Active Directory
Pero espere, aún hay más: la explotación de las dMSA para obtener las credenciales
Conseguir un TGT para cualquier usuario que queremos es genial, pero queremos más. ¿Y si también deseáramos sus credenciales? Afortunadamente, también tenemos aquí la ayuda de la dMSA en este escenario.
Cuando solicita un TGT para una dMSA, se proporciona con una nueva estructura llamada KERB-DMSA-KEY-PACKAGE. Esta estructura incluye dos campos: current-keys y previous-keys. Según MSDN, se supone que contienen claves relacionadas con la contraseña actual y anterior de la dMSA, y es cierto. Pero esa no es la historia completa.
Nos sorprendió ver que incluso cuando solicitamos un TGT para una dMSA recién creada, el campo previous-keys no estaba vacío. Puesto que se acaba de crear, no debería haber una "contraseña anterior". Ignoramos este hecho, hasta que nos dimos cuenta de que algo nos sonaba muy familiar.
Como se muestra en la Figura 11, el segundo elemento de la estructura tenía una sola clave con tipo 23 (RC4-HMAC). Este tipo de cifrado no está en su forma con sal, lo que significa que las contraseñas idénticas generan claves idénticas, incluso entre los usuarios.
Fig. 11: ASN.1 decoded value of the KERB-DMSA-KEY-PACKAGE, decoded at https://pkitools.net/pages/ca/asn1.html
¿Y esta clave en particular? Los años de reutilización de la misma contraseña en los entornos de laboratorio finalmente dieron sus frutos. La reconocimos inmediatamente. Era la clave correspondiente a Aa123456, la contraseña que utilizamos para nuestra cuenta de destino durante la demostración.
Reflexione sobre esto: la clave para una cuenta independiente de alguna manera terminó en la estructura previous-keys de la dMSA.
Explotación de claves a escala
Entonces, ¿qué es lo que está pasando aquí? ¿Y por qué?
El atributo msDS-ManagedAccountPrecededByLink no solo vincula la dMSA a la cuenta reemplazada con fines de permisos, sino que también permite que la dMSA herede sus claves. Esto significa que este ataque también se puede utilizar para obtener las claves de cualquier usuario y equipo del dominio, o de todos. Podemos utilizar esta clave para autenticarse con la cuenta.
Aunque no hemos analizado toda la implementación, nuestra teoría es que este comportamiento existe para garantizar una continuidad perfecta durante la migración de cuentas para el beneficio del usuario final.
Supongamos que tenemos un servicio que se ejecuta con una cuenta de servicio heredada. Las cuentas del dominio solicitan vales a este servicio, que se cifran con la clave de la cuenta de servicio heredada. Ahora, supongamos que reemplazamos la cuenta heredada por una dMSA, la migración se completa y la cuenta de servicio se reemplaza por la dMSA, pero la dMSA no tiene acceso a la clave de la cuenta antigua.
¿El resultado? Cuando un cliente intenta autenticarse utilizando su vale existente, el servidor no puede descifrarlo utilizando la nueva clave de dMSA, lo que hace que todos los vales emitidos queden inutilizables, aunque no hayan caducado.
Para evitar este tipo de interrupción del servicio, el KDC incluye las claves de la cuenta anterior en la nueva estructura de paquetes de claves de la dMSA, tratándolas como si fueran las credenciales anteriores de la dMSA y permitiéndole descifrar vales "antiguos".
Una vez que entendemos esto, otra rareza comienza a tener sentido. El campo current-keys contiene tres elementos, cada uno de los cuales consta de un entero (que representa el tipo de cifrado) y una cadena de octetos (la clave correspondiente). Puede consultar esta página para comprender los valores del tipo de cifrado. En nuestro caso, la lista incluye claves para RC4-HMAC, AES256 y AES128. Sin embargo, el campo previous-keys tiene un aspecto un poco diferente: contiene solo una clave, que corresponde a RC4-HMAC (Figura 12). ¿Por qué la lista previous-keys contiene solo un tipo de clave y por qué es específicamente RC4-HMAC?
Fig. 12: KERB-DMSA-KEY-PACKAGE structure, highlighting the different keys
La respuesta está en los tipos de cifrado admitidos por la cuenta original (reemplazada). Los vales de servicio solo se cifran mediante tipos de cifrado que admite el servicio de destino. Como se explica en la excelente entrada del blog de Harmj0y, el atributo msDS-SupportedEncryptionTypes controla este comportamiento. Si no se define este atributo (que es el caso predeterminado para las cuentas de usuario), el sistema utiliza solo RC4-HMAC de forma predeterminada, de ahí que sea la única clave RC4-HMAC de la lista previous-keys.
En otras palabras, el KDC proporciona a la dMSA solo las claves de la cuenta original que serían necesarias para descifrar los vales de servicio emitidos antes de la migración. Estos se determinan en función de los tipos de cifrado admitidos por la entidad original, que puede comprobar inspeccionando su atributo msDS-SupportedEncryptionTypes.
Respuesta de Microsoft
Informamos de estos detalles a Microsoft a través de MSRC el 1 de abril de 2025, y después de revisar nuestro informe y la prueba de concepto, Microsoft reconoció el problema y confirmó su validez. Sin embargo, lo evaluaron como una vulnerabilidad de gravedad moderada y afirmaron que actualmente no cumple el umbral de mantenimiento inmediato.
Según Microsoft, una explotación exitosa requiere que el atacante ya tenga permisos específicos en el objeto dMSA, lo que indica privilegios elevados. En respuesta al escenario de creación de una nueva dMSA, Microsoft hizo referencia al artículo KB5008383, que describe los riesgos relacionados con el permiso CreateChild.
Aunque apreciamos la respuesta de Microsoft, afirmamos con todos nuestros respectos que no estamos de acuerdo con la evaluación de la gravedad.
Esta vulnerabilidad introduce una ruta de explotación de alto impacto anteriormente desconocida que permite que cualquier usuario con permisos CreateChild en una OU explote a cualquier usuario del dominio y obtenga un poder similar al privilegio Replicar cambios de directorio utilizado para realizar ataques DCSync.
Además, no hemos encontrado ninguna indicación de que las prácticas o herramientas actuales del sector indiquen que el acceso a CreateChild (o más específicamente, a CreateChild para las dMSA) sea una preocupación crítica. Creemos que esto subraya tanto el sigilo como la gravedad del problema.
Detección y mitigación
Detección
Para detectar una posible explotación de este vector de ataque, las organizaciones deben centrarse en las siguientes áreas:
Auditar la creación de la dMSA: configure una SACL para registrar la creación de nuevos objetos msDS-DelegatedManagedServiceAccount (ID de evento 5137; Figura 13). Preste especial atención a las cuentas que normalmente no son responsables de la creación de cuentas de servicio.
Fig. 13: Event example of dMSA creation
Supervisar las modificaciones de atributos: configure una SACL para modificaciones en el atributo msDS-ManagedAccountPrecededByLink (ID de evento 5136; Figura 14). Los cambios en este atributo son una señal clara de un intento de explotación o una explotación exitosa.
Fig. 14: Event example of dMSA link creation
Realizar el seguimiento de la autenticación de la dMSA: cuando se genera un TGT para una dMSA e incluye la estructura KERB-DMSA-KEY-PACKAGE, el controlador de dominio registra el evento ID 2946 (Registro de servicios de directorio).
El campo Objeto de cuenta de servicio administrado por grupo (aunque se trata de una dMSA y no de una gMSA) mostrará el DN de la dMSA que se está autenticando y el campo SID de origen de la llamada aparecerá como S-1-5-7 (Figura 15). Se deben investigar los eventos 2946 frecuentes o inesperados relacionados con dMSA inusuales.
Fig. 15: Event example of dMSA authentication
Revisar permisos: preste especial atención a los permisos de las OU y los contenedores. Las delegaciones excesivamente permisivas pueden abrir la puerta a esta explotación.
Mitigación
Hasta que Microsoft publique un parche formal, los esfuerzos defensivos deben centrarse en limitar la capacidad de crear las dMSA y en restringir los permisos siempre que sea posible.
Los defensores deben identificar todas las entidades (usuarios, grupos, equipos) con permisos para crear las dMSA en todo el dominio y limitar ese permiso solo a administradores de confianza.
Para ayudarle con esto, hemos publicado un script de PowerShell que:
Enumera todas las entidades no predeterminadas que pueden crear dMSA
Enumera las OU en las que cada entidad tiene este permiso
Microsoft nos ha informado de que sus equipos de ingeniería están trabajando en un parche, y actualizaremos la guía de mitigación en esta entrada del blog una vez que haya más detalles técnicos disponibles.
Conclusión
Esta investigación pone de manifiesto cómo incluso los permisos de ámbito definido, que a menudo se suponen que son de bajo riesgo, pueden tener consecuencias de largo alcance en entornos de Active Directory. Los atacantes son bastante creativos y, si los recientes avances tecnológicos nos han enseñado algo, es que las funciones aparentemente benignas pueden tener algunas consecuencias serias en las manos equivocadas. La dMSA se introdujo como una solución moderna para la gestión de cuentas de servicio, pero su introducción también trajo consigo una nueva complejidad y, con ello, nuevas oportunidades de explotación.
Las organizaciones deben tratar la capacidad de crear las dMSA o de controlar las existentes con el mismo nivel de escrutinio que otras operaciones sensibles. Los permisos para gestionar estos objetos deben estar estrictamente restringidos y los cambios que se realicen en ellos deben supervisarse y auditarse con regularidad.
Esperamos que esta investigación arroje luz sobre los riesgos que conlleva Windows Server 2025 en general, y las dMSA en concreto, y ayude a los defensores a comprender y mitigar mejor el posible impacto de los permisos mal configurados.
