TL;DR: Este blog complementario, creado en colaboración con investigadores de seguridad de Akamai, desglosa dMSA Ouroboros, una técnica de extracción de credenciales autosuficiente en Windows Server 2025. Después de leer su blog, vuelve aquí para ver qué significa en la práctica: un usuario con CreateChild en cualquier OU o contenedor y WriteProperty en una cuenta objetivo puede crear un dMSA que extrae el hash NT del objetivo, persiste durante la rotación de contraseñas, sobrevive a la eliminación de la cuenta del atacante original y bloquea a los administradores de dominio de la remediación. Seis comandos. Windows Server 2025 totalmente parchado.

Introducción

Windows Server 2025 introdujo las cuentas de servicio administradas delegadas (dMSA) con un modelo de seguridad rediseñado que elimina el primitivo de recuperación de contraseñas y lo reemplaza con un flujo de autorización mediado por el KDC. El diseño es genuinamente mejor que gMSA: no puedes leer una contraseña administrada desde el directorio, y el acceso a las credenciales de la cuenta reemplazada está controlado mediante una verificación de autorización independiente.

Esta publicación presenta Ouroboros, una técnica de persistencia autosuficiente que usa esta misma semántica en contra del defensor. En lugar de evadir una sola validación, Ouroboros diseña una configuración donde el dMSA satisface continuamente ambas puertas de autorización por sí mismo: se autentica como él mismo mediante una credencial fantasma (Shadow Credential) plantada y se autoriza a sí mismo para recibir las credenciales de la cuenta reemplazada escribiendo su propio SID en GroupMSAMembership. Una vez cerrado el ciclo, la cuenta del atacante original ya no forma parte de la cadena.

El resto de la publicación construye el modelo mental preciso de estas verificaciones y luego recorre la cadena de Ouroboros y cómo deben responder los defensores.

Antecedentes: BadSuccessor y Golden dMSA

Dos equipos encontraron problemas con dMSA antes de esta investigación.

BadSuccessor (Yuval Gordon, Akamai, 2025) demostró que CreateChild en cualquier OU o contenedor era suficiente para crear un dMSA con una cuenta reemplazada objetivo arbitraria. El ataque original usaba manipulación de enlace unidireccional para engañar al KDC y que emitiera las credenciales del objetivo. Microsoft solucionó esto como CVE-2025-53779 al agregar validación del lado del KDC que exige enlaces bidireccionales: tanto msDS-ManagedAccountPrecededByLink en el dMSA como msDS-ManagedAccountSucceededByLink en el objetivo deben existir antes de que el KDC emita el KERB-DMSA-KEY-PACKAGE.

Golden dMSA (Adi Malyanker, Semperis, julio de 2025) demostró que la posesión de la clave raíz de KDS permite forzar por fuerza bruta las contraseñas administradas de dMSA porque la estructura ManagedPasswordId solo tiene 1.024 combinaciones posibles basadas en el tiempo. Microsoft no asignó un CVE y respondió que la clave raíz de KDS solo es accesible para administradores de dominio, administradores empresariales y SYSTEM, y que estas funciones nunca tuvieron la intención de proteger contra el compromiso de un DC.

Lo que Microsoft parchó después de BadSuccessor: ahora el KDC valida el enlace bidireccional antes de emitir el material de credenciales. Los enlaces unidireccionales ya no funcionan. Sin embargo, el parche no impide que un usuario con pocos privilegios cree enlaces bidireccionales legítimos si tiene los permisos delegados correctos. Tampoco aborda lo que sucede después de crear el dMSA: quién puede escribir en los atributos relevantes de seguridad del dMSA y qué hace el KDC cuando el dMSA intenta autorizarse a sí mismo.

Ahí es donde comienza Ouroboros.

Cómo entender el modelo de seguridad de dMSA

Para entender por qué funciona Ouroboros, necesitas entender qué cambió realmente Microsoft con dMSA en comparación con gMSA. El rediseño toca dos áreas, y ambas importan.

Puerta 1: se elimina la recuperación de contraseñas

Con gMSA, msDS-ManagedPassword es un atributo construido. El DC calcula el blob de contraseña administrada bajo demanda, y si puedes leerlo, puedes derivar material de autenticación reutilizable. Todo el modelo de amenazas de gMSA se reduce a "quién puede leer este atributo".

dMSA elimina intencionalmente ese flujo de recuperación. El atributo todavía existe en los objetos dMSA, pero es efectivamente inutilizable: se deniega de forma predeterminada en el defaultSecurityDescriptor, y hay una validación adicional del lado del DC que bloquea las lecturas LDAP sin importar la ACL. El resultado práctico es lo que afirma Microsoft: no puedes recuperar la contraseña de un dMSA desde AD.

Esta es una mejora real. La ruta de ataque clásica de gMSA (comprometer una entidad en msDS-GroupMSAMembership, leer el blob, derivar las claves) no funciona contra dMSA.

Puerta 2: GroupMSAMembership controla la operación, no la recuperación

Para gMSA, msDS-GroupMSAMembership se suele pensar como "quién tiene permitido recuperar la contraseña". Para dMSA, el significado del atributo cambia: se convierte en una puerta de autorización para quién tiene permitido operar como la cuenta. Específicamente, controla quién puede obtener un TGT para el dMSA mediante el flujo S4U2Self --dmsa y recibir el KERB-DMSA-KEY-PACKAGE que contiene las credenciales de la cuenta reemplazada.

Aquí es también donde entra Credential Guard. Si los endpoints protegen el material de Kerberos correctamente, robar y reutilizar las credenciales de dMSA se vuelve más difícil que el patrón clásico de "leer un blob de AD". El modelo de seguridad asume que el material de autenticación está protegido durante su uso, y que la puerta de autorización en GroupMSAMembership controla quién entra al flujo en primer lugar.

El matiz crítico: dos puertas separadas

Esto lleva a una distinción importante que la mayoría pasa por alto: poder autenticarse como el dMSA no es lo mismo que heredar la identidad reemplazada.

Dado que dMSA está diseñado para migración, la identidad dMSA por sí sola no siempre es el objetivo. El valor proviene de los privilegios del usuario reemplazado. El KDC trata esto como verificaciones separadas: puedes autenticarte como el dMSA y aun así no recibir el PAC y las claves de la cuenta reemplazada a menos que pases por el flujo dMSA solicitando un TGT que satisfaga msDS-GroupMSAMembership.

Entonces, para que un atacante extraiga de forma persistente las credenciales de la cuenta reemplazada, necesita satisfacer continuamente ambas condiciones:

1. Autenticarse como el dMSA (obtener un TGT para la identidad del dMSA)

2. Estar autorizado en GroupMSAMembership (para que el KDC emita el KERB-DMSA-KEY-PACKAGE con el material de la cuenta reemplazada)

Si cualquiera de las dos puertas falla, la cadena se rompe. La rotación de contraseñas debería invalidar el material de autenticación. La remediación debería eliminar al atacante de GroupMSAMembership. Credential Guard debería proteger los tickets en memoria.

Ouroboros vence las tres defensas al hacer que el dMSA satisfaga ambas puertas por sí mismo, de forma permanente, sin ningún principal externo en el proceso.

La pregunta de investigación

Esto no comenzó como investigación sobre dMSA.

El punto de partida fue una auditoría sistemática del principal SELF (S-1-5-10) en todo el esquema de Active Directory. SELF es la identidad que se resuelve como "el objeto mismo". Cuando un ACE le otorga a SELF un permiso de escritura, cualquier principal de seguridad puede realizar esa acción sobre su propio objeto de AD. Usuarios que actualizan sus números de teléfono, computadoras que escriben sus nombres DNS. Comportamiento estándar de AD desde Windows 2000.

La pregunta era: ¿qué atributos autoescribibles cruzan un límite de seguridad? La mayoría son inofensivos (telephoneNumber, displayName). Varios no lo son.

La auditoría produjo múltiples envíos a MSRC en distintas superficies de ataque. Dos fueron cerrados (ocultamiento de datos en atributos escribibles por DA, coerción de msTSHomeDirectory) porque requerían acceso de nivel administrativo y no cruzaban un límite de seguridad significativo. Los que superaron el umbral compartían un patrón: un atributo autoescribible alimenta un sistema que toma decisiones de autorización, y nadie estaba monitoreando la escritura.

Los hallazgos sobre dMSA surgieron al examinar qué ocurre después de que un usuario sin privilegios de administrador crea un dMSA. La clase dMSA (msDS-DelegatedManagedServiceAccount, OID 1.2.840.113556.1.5.302) hereda de la clase computer (subClassOf: computer). Tiene su propio defaultSecurityDescriptor que agrega ACE de denegación para lectura y cambio de contraseña, además de ACE de escritura de Creator Owner para dNSHostName, servicePrincipalName, displayName y sAMAccountName. Pero hereda ACE de escritura SELF de la clase computer y, más importante aún, el creador se convierte en el Owner del objeto.

La propiedad otorga WriteDacl. WriteDacl te da la capacidad de otorgarte a ti mismo GenericAll. Y GenericAll otorga acceso de escritura a cada atributo del objeto, incluyendo msDS-KeyCredentialLink y msDS-GroupMSAMembership.

Los dos hallazgos

Hallazgo 1: Autorreferencia en GroupMSAMembership

El KDC no impide que el propio SID de un dMSA aparezca en su descriptor de seguridad de msDS-GroupMSAMembership.

No existe validación que diga "un dMSA no puede autorizarse a sí mismo para recuperar sus propias credenciales". Un atacante con acceso de escritura a GroupMSAMembership puede agregar el SID del dMSA, y a partir de ese momento, el dMSA puede realizar S4U2Self --dmsa contra sí mismo y recibir el KERB-DMSA-KEY-PACKAGE que contiene el hash NT de la cuenta reemplazada.

Este es el núcleo del bucle autorreferencial. El dMSA le pide al KDC su propio paquete de credenciales, el KDC revisa GroupMSAMembership, encuentra el SID del dMSA y aprueba la solicitud.

Un efecto secundario: GroupMSAMembership también funciona como mecanismo de exclusión. Si el atacante escribe un SD que solo contiene el SID del dMSA y su propio SID, los administradores de dominio quedan bloqueados. Verificamos esto: el DA tony.soprano recibió KDC_ERR_POLICY ("Requested start time is later than end time") al intentar S4U2Self --dmsa contra un dMSA donde no estaba listado en GroupMSAMembership. Esto se probó con un TGT derivado de contraseña, lo que confirma que es una aplicación a nivel de KDC, no un artefacto de las herramientas.

Hallazgo 2: Falta de control de acceso en msDS-KeyCredentialLink para dMSAs

El defaultSecurityDescriptor del dMSA agrega ACE de denegación explícita para operaciones con contraseñas, pero no restringe las escrituras en msDS-KeyCredentialLink. Cualquier entidad con GenericAll o WriteProperty en el dMSA (que el creador puede obtener mediante la cadena Owner -> WriteDacl -> GenericAll) puede plantar una Shadow Credential.

Una Shadow Credential es un certificado X.509 escrito en msDS-KeyCredentialLink que habilita la autenticación PKINIT. Una vez plantado, el certificado ofrece una vía de autenticación completamente independiente de la contraseña administrada del dMSA. La contraseña administrada puede rotar según lo programado; el certificado sigue funcionando. Credential Guard, que Microsoft posiciona como una mejora de seguridad clave para los despliegues de dMSA, protege la contraseña administrada en memoria. No puede proteger contra una vía de autenticación que evita por completo la contraseña administrada y se autentica mediante un certificado plantado a través de PKINIT.

Figura 1: La cadena de ataque Ouroboros del dMSA. Las etapas 1-4 (naranja) requieren las credenciales del atacante. Después de la etapa 4, el ciclo se autosostiene (verde). El dMSA se autentica y se autoriza a sí mismo indefinidamente sin ninguna entidad externa.

La cadena Ouroboros: siete etapas

Antes de que comience la cadena, silvio.dante es un usuario de dominio estándar. Sus únicas pertenencias a grupos son tres roles de laboratorio en OU=Soprano Crew. Ninguno de los grupos privilegiados de AD (Domain Admins, Account Operators, Administradores Empresariales) está presente. Todo lo que sigue es alcanzable desde esta posición inicial.

Figura 2: la pertenencia a grupos de silvio.dante. Sin Domain Admins, sin Account Operators, sin Administradores Empresariales.

silvio.dante tiene exactamente dos derechos delegados. El primero es CreateChild para la clase de objeto dMSA en OU=Soprano Crew, lo que le permite crear dMSAs en esa OU. El segundo es WriteProperty en svc-ouroboros para los tres atributos de enlace de migración (msDS-SupersededServiceAccountState, msDS-ManagedAccountPrecededByLink, msDS-SupersededManagedAccountLink), lo que le permite establecer el enlace de migración hacia la cuenta reemplazada. Estas dos delegaciones son todo el requisito previo de BadSuccessor. Nada más en la cadena requiere derechos elevados.

Figura 3: derechos delegados de silvio.dante. Arriba: CreateChild en OU=Soprano Crew (GUID de clase de objeto 0feb936f... = msDS-DelegatedManagedServiceAccount). Abajo: WriteProperty en svc-ouroboros para los tres atributos de enlace de migración.

Etapa 1: crear un dMSA con enlace bidireccional

Desde esta posición, silvio crea dmsa-adriana con svc-ouroboros configurado como la cuenta reemplazada. La cadena toma el control a partir de ahí.

Figura 4: creación de dMSA por silvio.dante, un usuario de dominio estándar con CreateChild delegado en OU=Soprano Crew. El dMSA queda en la OU sobre la que silvio tiene derechos, no en el contenedor Managed Service Accounts. Salida filtrada con head -2 para mostrar solo los pasos de creación e impersonación.

Se configuran tanto msDS-ManagedAccountPrecededByLink (enlace directo) como msDS-SupersededManagedAccountLink (enlace inverso). Esto cumple con el requisito del parche de CVE-2025-53779. El atacante se convierte automáticamente en Owner del nuevo objeto.

Etapa 2: otorgar GenericAll mediante la cadena de propiedad

Como Owner, el atacante tiene WriteDacl implícito. Úsalo para otorgar GenericAll:

Figura 5: Silvio se otorga a sí mismo GenericAll sobre dmsa-adriana. Como creador y propietario del objeto, ya tiene WriteDAC implícito y podría modificar la DACL a voluntad; este paso solo hace explícito el permiso para las herramientas posteriores.

Etapa 3: plantar una credencial sombra

Escribe un certificado X.509 en msDS-KeyCredentialLink. El defaultSecurityDescriptor del dMSA deniega la lectura/cambio de contraseña, pero no restringe este atributo:

Figura 6: Silvio planta una credencial sombra en dmsa-adriana. La clave pública se escribe en msDS-KeyCredentialLink, y silvio conserva el .pfx correspondiente. A partir de este punto, puede autenticarse como el dMSA mediante PKINIT, sin depender de ninguna contraseña, membresía de grupo, ni de que su propia cuenta siga activa.

Salida: archivo PFX guardado como dmsa-adriana.pfx.

Etapa 4: autoinscripción de GroupMSAMembership (el paso crítico)

Este es el corazón del Ouroboros. Escribe el propio SID del dMSA en su msDS-GroupMSAMembership, autorizándolo a recuperar su propio KERB-DMSA-KEY-PACKAGE.

La trampa del SDDL: el SDDL debe usar derechos específicos expandidos (CCDCLCSWRPWPDTLOCRSDRCWDWO), NO la abreviatura de Generic All (GA). La verificación de autorización del KDC no asigna derechos genéricos a derechos específicos. Usar GA da como resultado KDC_ERR_POLICY. Usar derechos expandidos funciona correctamente.

Descubrimos esto al escribir los mismos permisos lógicos en ambas formas y observar que una funcionaba y la otra fallaba. A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;; se autenticó. A;;GA;;; falló con KDC_ERR_POLICY. El KDC no expande derechos genéricos a derechos específicos durante la verificación de autorización del dMSA.

La solución: usa System.DirectoryServices.ActiveDirectorySecurity (no System.Security.AccessControl.RawSecurityDescriptor). El primero genera correctamente el formato binario expandido.

Figura 7: Silvio escribe msDS-GroupMSAMembership en dmsa-adriana desde Kali a través de LDAPS. La membresía otorga el flujo del dMSA a dos principales: el propio Silvio y el dMSA. Con el dMSA en su propia lista de membresía, la cadena se vuelve autoautorizante, y la cuenta de Silvio ya no se necesita para cerrar el ciclo.

Figura 8: verificado desde el DC: la membresía que Silvio escribió desde Kali quedó correctamente registrada. Dos ACE en formato expandido, el segundo otorga al dMSA autoridad sobre la emisión de sus propias credenciales.

Después de este paso, la cadena se autosostiene. No se necesita ninguna cuenta de usuario externa.

Etapa 5: autenticación PKINIT

Autentícate como el dMSA usando el certificado plantado:

Figura 9: autenticación PKINIT como dmsa-adriana usando el certificado plantado. Certificado adentro, hash afuera. Sí, esto es UnPAC-the-hash. Lo sé. Lo sé.

Etapa 6 - S4U2Self --dmsa (extracción autoautorizada)

El dMSA solicita su propio KERB-DMSA-KEY-PACKAGE:

Figura 10: el dMSA le pide al KDC sus propias claves. El KDC accede, y la línea de claves anteriores es el hash NT de svc-ouroboros. La serpiente se ha mordido la cola.

Etapa 7: hash NT extraído

El KDC verifica GroupMSAMembership, encuentra el propio SID del dMSA, aprueba la solicitud y devuelve el KERB-DMSA-KEY-PACKAGE que contiene el RC4 (hash NT) de la cuenta reemplazada.

Figura 11: el hash del flujo del dMSA (bdfb66498271947e40b00394086dbc76) coincide con lo que devuelve DCSync para svc-ouroboros. Mismo hash, dos fuentes, sin dependencia compartida. La extracción de credenciales es real.

Una nota sobre terminología: "claves anteriores" se refiere a las claves que precedieron al dMSA en la cadena de migración, desde la perspectiva del dMSA. Según si la contraseña del dMSA se haya rotado desde la migración, estas se resuelven como las claves actuales del usuario reemplazado (si aún no hubo rotación) o como las claves previas reales del dMSA (si ya ocurrió la rotación). De cualquier forma, la rotación de contraseña en la cuenta reemplazada no rompe la extracción. Solo actualiza el hash extraído en la siguiente solicitud S4U2Self.

La serpiente se ha mordido la cola.

Por qué falla la remediación

Rotación de contraseña

La contraseña administrada de la dMSA rota según lo programado. No importa. La Shadow Credential se autentica mediante PKINIT, lo cual es completamente independiente de la contraseña administrada. El certificado persiste hasta que se elimina explícitamente de msDS-KeyCredentialLink.

La rotación de la contraseña de la cuenta reemplazada tampoco rompe la cadena. Como se señaló en la etapa 7, el KDC vuelve a poblar el KERB-DMSA-KEY-PACKAGE con las credenciales actuales de la cuenta reemplazada en cada solicitud. Verificamos esto en dmsa-adriana/svc-ouroboros: la extracción inicial devolvió RC4 bdfb66498271947e40b00394086dbc76. Luego restablecimos la contraseña de svc-ouroboros.

Figura 12: se restableció la contraseña de svc-ouroboros en el DC. La nueva marca de tiempo de pwdLastSet confirma que la rotación surtió efecto.

La siguiente extracción de dMSA devolvió RC4 0dd62b698ae591f86e6a40d73420820a, lo cual coincide con el DCSync de la cuenta rotada.

Figura 13: verificación de que la rotación no afecta la cadena. El flujo de dMSA devolvió un nuevo RC4 de claves anteriores (0dd62b...), que el DCSync confirma que es el hash NT actual de svc-ouroboros. La extracción rastrea el estado en vivo de la cuenta reemplazada; rotar la contraseña solo actualiza lo que se extrae.

Eliminación de la cuenta del atacante

Eliminamos a silvio.dante del directorio. Los intentos de autenticación como silvio fallaron porque la cuenta ya no existía. La cadena Ouroboros siguió funcionando: Certipy se autenticó como dmsa-adriana mediante PKINIT usando el certificado plantado, y badS4U2self devolvió el hash NT actual de svc-ouroboros. silvio no se referencia en ninguna parte de la cadena en tiempo de ejecución. La dMSA se autentica con su propio certificado y se autoriza a sí misma mediante su propio GroupMSAMembership.

Figura 14: silvio.dante se eliminó de Active Directory

Figura 15: bloodyAD intenta autenticarse como silvio y falla con SEC_E_LOGON_DENIED. La cuenta ya no existe.

Figuras 16 (arriba) y 17: silvio ya no existe. La autenticación PKINIT se realiza con éxito (arriba), y la extracción S4U2Self devuelve el hash NT de svc-ouroboros (abajo). El estado de la cuenta del atacante es irrelevante.

¡La cadena sigue viva!

La única solución realmente efectiva

Elimina el objeto dMSA por completo. Las soluciones parciales (borrar msDS-KeyCredentialLink, restablecer msDS-GroupMSAMembership) pueden deshacerse por cualquiera que conserve WriteDacl sobre el objeto. Una limpieza completa debe eliminar la dMSA en sí. Primero también hay que identificar al atacante, lo que requiere buscar Shadow Credentials en objetos msDS-DelegatedManagedServiceAccount, una clase que ninguna herramienta defensiva actual cubre.

No existe una solución parcial. Eliminas la dMSA, o la cadena sigue viva.

Golden dMSA frente a dMSA Ouroboros

Realidad operativa

Dificultad de ejecución

La herramienta se reduce a seis comandos. La prueba de concepto es tan simple como copiar y pegar. Pero eso engaña. Lo difícil no es ejecutar los comandos. Es llegar a la posición inicial y saber qué estás viendo.

Necesitas entender los modelos de delegación de AD lo suficientemente bien como para identificar quién tiene CreateChild en cualquier OU o contenedor, saber qué significa WriteProperty en una cuenta objetivo y cómo encontrar las cuentas sobre las que tienes ese permiso, y comprender qué es un dMSA, qué es PKINIT, qué hace S4U2Self y qué controla GroupMSAMembership. Si algún paso falla, como el problema de formato SDDL que encontramos, te quedas varado sin un conocimiento sólido de los internos de AD.

Nivel de habilidad: técnicas intermedias de AD. Alguien cómodo con BloodHound, Certipy y bloodyAD podría lograrlo. Sin esa base, la cadena se desmorona ante el primer error inesperado.

Esto NO es una forma rápida de obtener DA

Ouroboros explícitamente no es una escalada de privilegios a DA. Es un mecanismo de extracción de credenciales y persistencia. No te conviertes en DA, robas el hash NT de la cuenta con la que esté vinculado el dMSA. Si esa cuenta resulta ser DA, entonces sí. Pero primero necesitas WriteProperty sobre esa cuenta específica.

El escenario realista: comprometiste una cuenta de mesa de servicio o un sistema de aprovisionamiento con derechos delegados, CreateChild en algún punto del directorio y WriteProperty sobre cuentas de servicio dentro de su ámbito de responsabilidad. Extraes credenciales de una cuenta de servicio de alto valor, tal vez una con delegación restringida a un DC, tal vez una en un grupo privilegiado. Es movimiento lateral y persistencia, no escalada directa.

Dónde esto realmente brilla

Pentests (con tiempo limitado, para demostrar impacto): Probablemente es excesivo. Es mejor restablecer directamente la contraseña objetivo y capturar una captura de pantalla de la sesión DA.

Equipos rojos (simular un adversario real, probar la detección): Esto es oro puro. Planta el dMSA, espera dos semanas y vuelve a través del certificado. Prueba si el SOC detecta la creación de dMSA, las escrituras de Shadow Credential o S4U2Self con la bandera --dmsa. La mayoría de los SIEM no están ajustados para nada de esto.

Adversarios reales (APT, ransomware): Este es el escenario de pesadilla. Poco ruido, autosuficiente, sobrevive a la respuesta a incidentes. Si un atacante planta esto durante el acceso inicial y el equipo de IR no busca específicamente dMSAs maliciosos, el atacante mantiene acceso persistente indefinidamente.

Bordes de BloodHound propuestos (para la comunidad <3)

El Ouroboros encaja de forma natural en el modelo de grafo de BloodHound. Estos son los bordes que deberían existir en un entorno de Server 2025:

Borde 1: CreateDMSA — CreateChild para la clase de objeto dMSA en cualquier OU o contenedor. BloodHound ya rastrea CreateChild, pero no marca específicamente el CreateChild de clase dMSA como un objetivo de alto valor.

Borde 2: BadSuccessor — Borde compuesto a partir de un principal que tiene TANTO CreateChild en un OU/contenedor COMO WriteProperty sobre los atributos de enlace de migración de una cuenta objetivo. Esta es la relación de "puede migrar".

Borde 3: OuroborosSelfEnroll — Una vez que un principal tiene Owner o GenericAll sobre un dMSA, puede escribir el propio SID del dMSA en GroupMSAMembership, permitiendo que el dMSA se autorice a sí mismo. Este es el borde autorreferencial: el dMSA se apunta a sí mismo como un miembro válido de GroupMSAMembership.

Figura 18: Tres bordes de BloodHound propuestos para Ouroboros, superpuestos a los primitivos nativos de AD que los componen. CreateDMSA: un refinamiento de CreateChild que marca la creación de clase dMSA como de alto valor. BadSuccessor: un compuesto a partir de un principal que posee CreateChild en un contenedor y WriteProperty sobre los atributos de enlace de migración de un objetivo. Ninguno por sí solo es suficiente. OuroborosSelfEnroll: el borde autorreferencial disponible para un principal con Owner o GenericAll sobre un dMSA, que puede escribir el propio SID del dMSA en msDS-GroupMSAMembership.

La consulta que debería encender todas las alarmas del SOC: "Encontrar todos los principales que tienen CreateChild en cualquier OU o contenedor Y WriteProperty en cualquier cuenta de usuario o servicio". Ese es tu radio de impacto: cada cuenta alcanzable mediante esa combinación es un objetivo potencial de Ouroboros.

Consultas de detección que BloodHound podría mostrar:

• "Encontrar todos los dMSAs donde GroupMSAMembership contiene el propio SID del dMSA" — eso es un Ouroboros activo. Cero razones legítimas para que eso exista.

• "Encontrar todos los dMSAs con msDS-KeyCredentialLink poblado" — posible persistencia de Shadow Credential.

• "Encontrar todos los dMSAs donde msDS-ManagedAccountPrecededByLink apunta a una cuenta de alto valor" — ataque activo a cuentas privilegiadas.

Tres capas de detección: la capacidad (quién PUEDE hacer esto), la actividad (quién YA lo hizo) y la persistencia (qué dMSAs están autoinscritos con Shadow Credentials).

Guía de detección

Indicadores del registro de eventos

Por qué la detección es difícil

Cada operación individual se ve normal de forma aislada. La creación de dMSA es una acción administrativa estándar. Las escrituras de Shadow Credential ocurren durante el aprovisionamiento de Windows Hello. Los cambios en GroupMSAMembership ocurren durante una configuración legítima de dMSA. La señal maliciosa es la combinación, y la mayoría de los SIEM no correlacionan entre estos tipos de eventos.

Reglas de detección de alta confianza

1. Cualquier dMSA donde GroupMSAMembership contenga el propio SID del dMSA. Tasa de falso positivo de cero. Ninguna configuración legítima requiere esto.

2. Creación de dMSA por principales que no son administradores. La mayoría de los dMSA deberían crearse mediante herramientas privilegiadas de gestión de servicios, no desde cuentas de helpdesk.

3. msDS-KeyCredentialLink poblado en objetos dMSA. Los dMSA usan contraseñas administradas. La autenticación basada en certificados en un dMSA es sospechosa por defecto.

4. Establece una línea base de tu inventario de dMSA. Sabe cuántos existen, quién los creó y a qué reemplazan. Los dMSA fraudulentos son obvios cuando tienes una línea base.

Soluciones recomendadas

Para los defensores (ahora)

1. Audita las delegaciones de CreateChild en todas las OU y contenedores, no solo en el contenedor de MSA.

2. Monitorea la creación de nuevos objetos dMSA por principales que no son administradores.

3. Consulta todos los dMSA existentes y verifica si su propio SID aparece en msDS-GroupMSAMembership.

4. Revisa msDS-KeyCredentialLink en todos los objetos dMSA para detectar Shadow Credentials plantadas.

La respuesta de Microsoft

Enviamos dos informes a MSRC. Esta sección documenta el intercambio completo para que los lectores puedan evaluar el razonamiento de ambas partes.

Caso 1: dMSA Ouroboros (VULN-173664 / MSRC Case 107173)

10 de febrero de 2026 -- Envío. El informe describía ambos hallazgos (autorreferencia de GroupMSAMembership y evasión de Shadow Credential) como una cadena combinada, con una prueba de concepto completa en un DC de Server 2025 parchado (KB5072725, KB5073379), detalles del entorno de prueba y la remediación recomendada.

11 de febrero -- Caso abierto. MSRC asignó el Case 107173 y nos pidió enviar informes separados para cada hallazgo, para poder dar seguimiento a las correcciones y la recompensa de forma independiente. Cumplimos (ver Caso 2 abajo).

17 de febrero -- Revisión de estado. Pedimos una actualización.

17 de febrero -- Respuesta de MSRC. Will, de MSRC, confirmó que el equipo de ingeniería estaba discutiendo el informe y que esperaban tener una respuesta en unos días.

10 de marzo -- Caso cerrado. MSRC cerró el caso:

"Hemos completado nuestra investigación y determinamos que este problema no cumple con el umbral para recibir servicio.

RAZÓN: Los pasos de reproducción requieren que se alineen bastantes factores:

• Se debe tener acceso a la cuenta de un usuario del dominio. <

• El usuario del dominio debe tener delegación de CreateChild en una OU.

• El usuario del dominio debe tener WriteProperty sobre la cuenta de servicio a la que apunta.

• Se debe tener acceso a una máquina unida al dominio con RSAT-AD-PowerShell."
  
  

10 de marzo -- Nuestra apelación. Respondimos el mismo día:

"Solicito respetuosamente que se reevalúe VULN-173664 a la luz de CVE-2025-53779 (BadSuccessor), que recibió servicio por un ataque en la misma superficie de migración de dMSA con requisitos previos equivalentes.

El razonamiento del cierre indica que la explotación requiere:

• Acceso a la cuenta de un usuario del dominio

• Delegación CreateChild en una OU

• WriteProperty en la cuenta de servicio objetivo

• Acceso a una máquina unida al dominio con RSAT-AD-PowerShell

Quiero abordar esto directamente: cada requisito previo mencionado arriba se aplica igualmente a vulnerabilidades que MSRC ha atendido, parchado y a las que ha asignado CVE. Estos no son "astros que se alinean" -- son los requisitos estándar para toda una categoría de ataques a Active Directory que Microsoft ha tratado consistentemente como atendibles:

• CVE-2025-53779 (BadSuccessor): CreateChild en una OU. Misma superficie de ataque de dMSA. Akamai confirmó que el 91 % de los entornos tienen usuarios no administradores con estos permisos.

• CVE-2022-26923 (Certifried): GenericWrite en el dNSHostName del objeto de un equipo. Parchado. CVSS 8,8.

• CVE-2021-42278 / CVE-2021-42287 (noPac): Creación de cuenta de máquina + escritura de sAMAccountName. Parchado. CVSS 8,8.

• Shadow Credentials: GenericWrite en msDS-KeyCredentialLink. Atendido.

• Abuso de RBCD: GenericWrite en msDS-AllowedToActOnBehalfOfOtherIdentity. Atendido.

El requisito previo para cada uno de estos es GenericWrite en un objeto de AD. Este es el mismo requisito previo que nuestro hallazgo. La mala configuración de GenericWrite no es un caso hipotético excepcional -- es el hallazgo más común en las evaluaciones de seguridad de Active Directory. Herramientas como BloodHound, que Microsoft ha reconocido e integrado en su propia guía de seguridad, existen específicamente porque estas delegaciones son generalizadas en los entornos empresariales. Cada ruta de ataque basada en DACL que BloodHound identifica -- Shadow Credentials, RBCD, Kerberoasting dirigido, abuso de delegación restringida, noPac, Certifried -- requiere el mismo requisito previo de GenericWrite o CreateChild que aquí se cita como motivo de descalificación.

Si este requisito previo descalifica un hallazgo para ser atendido, entonces Shadow Credentials, RBCD, noPac, Certifried y BadSuccessor tampoco deberían haberse parchado nunca. MSRC no puede atender toda una categoría de ataques basados en DACL y luego cerrar un nuevo hallazgo sobre la misma superficie de ataque, calificando esos mismos requisitos previos como excepcionales.

Además, mencionar "acceso a RSAT-AD-PowerShell" como requisito previo no es significativo. Nuestra prueba de concepto usa Python con ldap3 sobre un socket de red. Las mismas operaciones funcionan desde ldapsearch, SharpLDAP, bloodyAD o LDAP puro desde cualquier equipo Linux en la red. La disponibilidad de herramientas nunca ha sido un límite de seguridad en el modelo de amenazas de Microsoft, y su inclusión infla el número aparente de requisitos previos.

dMSA Ouroboros explota los mismos atributos msDS-ManagedAccountPrecededByLink y msDS-DelegatedMSAState que BadSuccessor, mediante una secuencia de manipulación diferente que logra una escalada de privilegios equivalente. Cerrar este hallazgo mientras se atendió CVE-2025-53779 para la misma superficie de ataque, con los mismos requisitos previos, aplica un estándar inconsistente.

Solicito que este caso se vuelva a abrir y se evalúe con los mismos criterios aplicados a CVE-2025-53779."

16 de marzo -- Escalamiento de MSRC. Will respondió:

"Voy a conversar con el ingeniero que realizó la evaluación sobre tus inquietudes y te responderé pronto."

19 de marzo -- Respuesta sustantiva de MSRC. MSRC dio un seguimiento detallado que abordó la apelación directamente. La reproducimos por completo porque es una respuesta cuidadosa que merece leerse entera:

"Gracias por el seguimiento detallado. Reconocemos que nuestra respuesta anterior fue brusca, y es razonable que esto haya generado frustración. Valoramos el cuidado con el que has planteado tus inquietudes.
La autenticación está implícita en el ataque descrito. Esto no es un factor descalificador, pero sí afecta la evaluación de severidad. Desde la perspectiva del modelo de riesgo, partir de una posición anónima o sin autenticación sería considerablemente peor. Si este comportamiento fuera posible de forma anónima, sin duda recibiría una severidad superior a Moderada.
El ataque requiere un usuario de dominio autenticado y depende de permisos delegados. Si bien CreateChild sí introduce cierta flexibilidad, este permiso idealmente no debería otorgarse de forma amplia, y contamos con documentación que respalda esa posición. Además, WriteProperty puede ser heredado por la cuenta propietaria en escenarios donde se crea un objeto hijo (por ejemplo, mediante CreateChild).
Las herramientas no representan una barrera significativa aquí; en general se espera que los atacantes traigan sus propias herramientas, por lo que las herramientas específicas utilizadas no cambian de forma material la evaluación.
En general, existen supuestos sobre los entornos típicos y su vulnerabilidad inherente que nos dificultan evaluar el impacto de este caso como Importante.
Este comportamiento no constituye una elevación de privilegios. Más bien, representa un mecanismo de persistencia que no es muy distinto a técnicas existentes como Shadow Credentials. Esta es una distinción clave entre este problema y otras vulnerabilidades que mencionaste, incluyendo BadSuccessor, noPac y Certifried, que demostraron resultados directos de elevación de privilegios.
Para abordar la comparación directamente: si bien este problema y BadSuccessor comparten una superficie de ataque similar, el impacto de ambos es muy distinto.
También reconocemos la ambigüedad en torno a los mecanismos de autenticación provistos a las cuentas dMSA y agradecemos que se haya planteado. Tal como está, esto no cumple con el umbral para una atención inmediata."

Vale la pena señalar varias cosas sobre esta respuesta. MSRC reconoció que su cierre inicial fue brusco. Aceptaron el punto sobre las herramientas ("en general se espera que los atacantes traigan sus propias herramientas"). Demostraron entender la cadena de propiedad ("WriteProperty puede ser heredado por la cuenta propietaria en escenarios donde se crea un objeto hijo"). Y dejaron la puerta abierta para una reevaluación.

El desacuerdo central es de clasificación. MSRC ve a Ouroboros como un mecanismo de persistencia comparable al abuso existente de Shadow Credentials. Nuestra postura es que el abuso existente de Shadow Credentials no produce bucles autosostenibles que sobreviven a la eliminación de la cuenta atacante, bloquean a los administradores de dominio de la remediación, y rastrean automáticamente las rotaciones de contraseña en la cuenta objetivo. La etiqueta de "persistencia" es técnicamente correcta, pero subestima el impacto práctico.

Caso 2: Evasión de Shadow Credentials (VULN-173807 / MSRC Case 107235)

11 de febrero de 2026 -- Envío. Presentado a petición de MSRC para dividir el informe original. Este informe describió la omisión de Shadow Credentials como un hallazgo independiente: el defaultSecurityDescriptor de dMSA incluye reglas de denegación explícitas para la lectura y el cambio de contraseña, pero no restringe las escrituras a msDS-KeyCredentialLink. Cualquier principal con WriteProperty o GenericAll puede plantar un certificado que proporciona autenticación PKINIT permanente, anulando la propiedad de seguridad central de las cuentas administradas y volviendo irrelevante a Credential Guard.

El informe también documentó la superficie de escritura SELF heredada de la clase de equipo: más allá de msDS-KeyCredentialLink, un dMSA que se autentica como sí mismo puede escribir en msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD), servicePrincipalName, dNSHostName, ms-TPM-Tpm-Information-For-Computer, el conjunto de propiedades de Información Personal (71 atributos), el conjunto de propiedades de Información Web y el conjunto de propiedades de Información Privada (atributos de roaming de credenciales msPKI). Esta superficie heredada es más amplia que lo que el defaultSecurityDescriptor de dMSA fue diseñado para exponer.

12 de febrero -- Caso abierto. MSRC asignó el Case 107235.

23 de febrero -- Caso cerrado. MSRC cerró el caso:

"Reportaste una omisión de función de seguridad que afecta a los objetos dMSA en Active Directory. Se confirmó que esto está relacionado con MSRC 107173."

Esta es una decisión administrativa razonable dado que originalmente los presentamos juntos. Sin embargo, la omisión de Shadow Credentials es explotable de forma independiente: cualquier principal que pueda escribir en el msDS-KeyCredentialLink de un dMSA obtiene autenticación permanente como ese dMSA, sin importar la configuración de GroupMSAMembership. No recibió una evaluación independiente.

Nuestra postura

Respetamos el proceso de MSRC y apreciamos el compromiso sustantivo en la respuesta del 19 de marzo. Entendemos la distinción que hacen entre persistencia y elevación de privilegios.

No estamos de acuerdo con el resultado por una razón: el impacto práctico para los defensores es el mismo sin importar la clasificación. Un usuario de dominio estándar que parte de permisos comúnmente delegados (91 % de los entornos según la investigación de Akamai) puede producir un mecanismo de extracción de credenciales autosostenido que sobrevive a la rotación de contraseñas, sobrevive a la eliminación de la cuenta del atacante, bloquea a los administradores de dominio de la remediación, vuelve ineficaz a Credential Guard, y devuelve automáticamente el hash NT actual del objetivo en cada extracción. Ninguna herramienta defensiva actual lo detecta.

Publicamos esta investigación para que los defensores puedan detectar y responder a esta técnica ahora.

Cronología de divulgación

Agradecimientos

• Yuval Gordon (Akamai), cuya investigación sobre BadSuccessor es la base sobre la que se construye este trabajo. Leyó la publicación de principio a fin, dejó comentarios de revisión detallados y fue un punto de referencia para esta y otras investigaciones sobre dMSA a lo largo del proceso. El informe de MSRC es considerablemente mejor gracias a él.

• CravateRouge por bloodyAD

• Oliver Lyak (ly4k) por Certipy

• el proyecto kerbad por badS4U2self

• Fortra por impacket

• Equipo Huntress: Gracias a Adam Bienvenu, Aaron Deal, Lizzie Danielson, y Lindsey O’Donnell-Welch por su ayuda en la revisión de esta publicación.