BadSuccessor dMSA Privilege Escalation: cómo un usuario con pocos privilegios se convierte en Domain Admin

BadSuccessor dMSA privilege escalation — bautizada BadSuccessor por Akamai — es una técnica que abusa de las Delegated Managed Service Accounts (dMSA), una función introducida en Windows Server 2025, para permitir que un usuario con pocos privilegios suplante cualquier cuenta del dominio, hasta llegar a Domain Admin. Fue documentada por el investigador de Akamai Yuval Gordon en mayo de 2025 y se le asignó el identificador CVE-2025-53779; Microsoft entregó una corrección en la actualización de seguridad del 12 de agosto de 2025 (KB5064010).

Este artículo explica el mecanismo, por qué afecta a una parte tan amplia de entornos reales, y cómo detectarlo y remediarlo — incluyendo qué cambió realmente el parche y qué dice la investigación pública que aún merece atención después.

Para rutas de escalada de Active Directory relacionadas, consulta Delegación Kerberos no restringida: del abuso al RBCD y Abuso de ACL y DCSync: las rutas silenciosas hacia Domain Admin. BadSuccessor es un mecanismo distinto de ambos — no toca la ACL ni la configuración de delegación de una cuenta existente; abusa de los derechos de creación de objetos en una OU para fabricar uno nuevo. También comparte un aire de familia con Shadow Credentials: abuso de msDS-KeyCredentialLink en Active Directory — ambas técnicas escalan privilegios escribiendo en un atributo de vinculación de identidad en lugar de crackear una credencial.

¿Qué es BadSuccessor dMSA Privilege Escalation?

Las Delegated Managed Service Accounts (dMSA) son una función de Windows Server 2025 diseñada para permitir que las organizaciones migren cuentas de servicio antiguas a un modelo de identidad gestionado y sin contraseña, sin tener que reaprovisionar cada dependencia. Parte de ese diseño de migración incluye un mecanismo de "sucesión": un dMSA puede vincularse a una cuenta más antigua que está destinado a reemplazar, y Active Directory traslada parte del acceso de esa cuenta durante la transición.

Por qué existe dMSA en primer lugar

Microsoft diseñó dMSA para resolver un problema operativo real: las cuentas de servicio autónomas heredadas suelen tener contraseñas estáticas, raramente rotadas, y privilegios amplios y permanentes, porque migrar a un modelo de identidad gestionado tradicionalmente implicaba reaprovisionar cada aplicación dependiente. El modelo de sucesión de dMSA — vincular la nueva cuenta gestionada con la antigua que reemplaza — buscaba hacer esa migración casi transparente. BadSuccessor abusa de la confianza integrada en esa transparencia, no de un fallo en el manejo de contraseñas en sí.

El mecanismo de BadSuccessor

Según la investigación original de Akamai (corroborada por Unit 42, Semperis y Tarlogic), el ataque abusa de dos atributos de dMSA en los que el KDC confía sin verificación cruzada durante la "migración" que representan:

• msDS-ManagedAccountPrecededByLink — un enlace (DN, distinguished name) a la cuenta que el dMSA está destinado a "suceder". La investigación pública describe que el KDC previo al parche construía el PAC (Privilege Attribute Certificate) de la cuenta a partir de cualquier DN presente en este campo, sin verificar que existiera una relación de migración real.
• msDS-DelegatedMSAState — el estado de migración (0 = ninguno, 1 = en curso, 2 = completado).

Paso a paso: cómo funcionaba el ataque antes del parche

1. El atacante identifica una OU o contenedor donde posee derechos CreateChild — según las pruebas de Akamai, un permiso a la vez común y raramente auditado en detalle.
2. El atacante crea un nuevo objeto dMSA en esa OU.
3. El atacante escribe el DN de la cuenta objetivo (por ejemplo, un Domain Admin) en msDS-ManagedAccountPrecededByLink.
4. El atacante establece msDS-DelegatedMSAState en 2 ("completado"), marcando la migración fabricada como terminada.
5. La investigación pública describe que el KDC previo al parche trataba entonces cada autenticación posterior como el dMSA como si fuera una continuación de la identidad de la cuenta objetivo — construyendo el PAC con los SID y membresías de grupo de la cuenta objetivo, sin que esta fuera modificada en ningún momento.

Las pruebas de Akamai reportaron que el 91 % de los entornos examinados tenían al menos un usuario no administrador con permisos suficientes para llevar a cabo este ataque, en gran parte porque la delegación CreateChild a nivel de OU es común y raramente se audita en detalle.

Impacto del parche de agosto de 2025

La actualización del 12 de agosto de 2025 de Microsoft (KB5064010, CVE-2025-53779) cambió la forma en que kdcsvc.dll valida la relación de sucesión: la emisión de tickets ahora exige que el enlace refleje un emparejamiento mutuo genuino en lugar de aceptar una escritura unidireccional en msDS-ManagedAccountPrecededByLink. El simple hecho de apuntar un dMSA recién creado hacia una cuenta privilegiada, como se describió antes, ya no produce un ticket de suplantación tras la actualización.

La evaluación de severidad de Microsoft

MSRC evaluó inicialmente el problema reportado como que no cumplía el umbral para una corrección inmediata y lo calificó de severidad moderada cuando Akamai lo reportó por primera vez; se entregó como una corrección regular en el ciclo de Patch Tuesday de agosto de 2025, en lugar de como una publicación fuera de banda. La evaluación actual de Microsoft califica la explotación como "menos probable", y los informes públicos no describen explotación confirmada en la práctica a la fecha de publicación.

Lo que dice la investigación sobre el parche

La propia investigación de seguimiento de Akamai ("BadSuccessor Is Dead, Long Live BadSuccessor(?)") y un artículo posterior de la comunidad publicado por AlteredSecurity ("BetterSuccessor") describen ambos el parche como el cierre de la ruta directa de enlace unidireccional, señalando a la vez que la investigación sobre abuso de dMSA ha continuado en escenarios más acotados. Este artículo no reproduce esas técnicas derivadas; considera que el parche cierra sustancialmente — no necesariamente por completo — la ruta original de BadSuccessor, y prioriza los pasos de detección y endurecimiento de la delegación descritos más abajo, independientemente del estado del parche.

Por qué está tan extendido

BadSuccessor es inusual entre las técnicas de escalada de privilegios de AD porque no requiere una mala configuración en el sentido tradicional. Funciona contra el modelo de permisos predeterminado de dMSA en cuanto existe un DC Windows Server 2025 en el dominio. La exposición real proviene de lo ampliamente que se delegan los derechos CreateChild sobre OU y contenedores en entornos reales — a menudo a equipos de soporte, equipos de aplicaciones, o delegaciones heredadas que nunca se revisaron. La investigación pública de Semperis y Unit 42 apunta ambas a la misma causa raíz: prácticas de delegación de OU y de raíz de dominio más amplias de lo previsto, no un simple parche faltante.

Esto conecta directamente con un patrón tratado en Rutas de ataque en AD: cómo se encadenan las malas configuraciones hacia Domain Admin: las exposiciones más peligrosas casi nunca son un único bug crítico — son delegaciones y permisos acumulados que nadie ha revisado desde que se establecieron.

Detección

Remediación — pasos accionables

1. Parchear primero

Aplica la actualización de seguridad del 12 de agosto de 2025 (KB5064010 / CVE-2025-53779) en cada controlador de dominio Windows Server 2025.

2. Auditar y restringir la delegación CreateChild

Revisa los permisos de OU y de raíz de dominio para cuentas y grupos que puedan crear objetos — en particular objetos msDS-DelegatedManagedServiceAccount — y elimina la delegación que no sea activamente necesaria. Este es el control que determina si la ruta de ataque existe siquiera, independientemente del estado del parche.

3. Habilitar auditoría basada en SACL

Configura la auditoría para la creación de objetos dMSA (ID de evento 5137) y para modificaciones a msDS-ManagedAccountPrecededByLink / msDS-DelegatedMSAState (ID de evento 5136), y genera alertas ante cualquier cambio de este tipo realizado por una cuenta no privilegiada.

4. Inventariar los dMSA existentes

Confirma que cada dMSA del dominio corresponde a una migración legítima y esperada, y revisa el valor de msDS-ManagedAccountPrecededByLink de cada uno.

# Inventariar todos los objetos dMSA y su enlace de sucesión, para revisión manual
Get-ADServiceAccount -Filter "ObjectClass -eq 'msDS-DelegatedManagedServiceAccount'" -Properties msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState |
  Select-Object Name, msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState

Cómo detecta esto EtcSec

El catálogo de vulnerabilidades de AD de EtcSec incluye una verificación dedicada, BADSUCCESSOR_DMSA_ESCALATION, que señala este riesgo de escalada mediante dMSA. Dado que la exposición raíz es la amplitud de la delegación y no un objeto mal configurado aislado, EtcSec también muestra hallazgos de DELEGATION_PRIVILEGE — delegaciones amplias a nivel de OU o de raíz de dominio — como la condición subyacente que hace viable BadSuccessor en un entorno dado, independientemente de si ya existe un DC Windows Server 2025. Los equipos que ya siguen el desvío del acceso privilegiado con Desvío del acceso privilegiado en Active Directory: cómo los derechos de administrador regresan tras las auditorías están observando el mismo problema subyacente — delegación nunca revisada — desde un ángulo diferente.

Referencias principales

• Akamai: BadSuccessor — Abusing dMSA to Escalate Privileges in Active Directory
• Akamai: BadSuccessor Is Dead, Long Live BadSuccessor(?)
• Microsoft Security Update Guide: CVE-2025-53779
• NVD: CVE-2025-53779
• Help Net Security: Microsoft fixes "BadSuccessor" Kerberos vulnerability (CVE-2025-53779)
• Unit 42 (Palo Alto Networks): When Good Accounts Go Bad — Exploiting Delegated Managed Service Accounts in Active Directory
• Semperis: BadSuccessor — How to Detect and Mitigate dMSA Privilege Escalation
• Tarlogic: BadSuccessor — Escalating Privilege Using dMSA Abuse in Active Directory
• AlteredSecurity: BetterSuccessor — Still Abusing dMSA for Privilege Escalation (BadSuccessor After Patch)