Recientemente se ha descubierto una grave vulnerabilidad en Windows Server 2025 que podría permitir a los atacantes tomar el control de cualquier cuenta dentro de Active Directory (AD).
Según un investigador de seguridad en Akamai, el problema está relacionado con una nueva funcionalidad llamada cuentas de servicio administradas delegadas (o dMSA, por sus siglas en inglés). Esta función, que llegó con Windows Server 2025, viene activada por defecto y es muy fácil de aprovechar.
En palabras simples, esta falla permite que un usuario sin privilegios de administrador pueda explotar la dMSA para escalar permisos y comprometer el directorio entero. Y lo preocupante es que esto no es un caso aislado: el equipo de Akamai encontró que en el 91 % de los entornos que analizaron, había al menos un usuario fuera del grupo de administradores con los permisos necesarios para lanzar este tipo de ataque.
Lo más llamativo del asunto es que el ataque se basa en una función que, irónicamente, se creó para mejorar la seguridad. Las dMSA están pensadas para reemplazar cuentas de servicio antiguas y vulnerables, como medida contra ataques conocidos como Kerberoasting. Pero esta herramienta de seguridad ha terminado abriendo una nueva puerta a los atacantes.
El equipo de seguridad ha bautizado esta técnica como "BadSuccessor", haciendo referencia al hecho de que esta nueva función, pensada para suceder a las cuentas de servicio tradicionales, ha terminado convirtiéndose en una sucesora problemática.
Según la propia documentación de Microsoft, las dMSA pueden crearse como cuentas nuevas o para reemplazar cuentas de servicio existentes. Cuando una dMSA toma el lugar de una cuenta antigua, bloquea la autenticación usando la contraseña anterior y redirige todo el proceso de autenticación a través de la Autoridad de Seguridad Local (LSA).
Lo más delicado es que, durante esta migración, la dMSA detecta automáticamente en qué dispositivos se usaba la cuenta antigua. Eso significa que hereda por completo los accesos y permisos anteriores en Active Directory, facilitando el abuso si un atacante logra manipular el proceso.
¿Cómo una migración simulada con dMSA puede dar acceso total al dominio?
El problema radica en cómo funciona la autenticación Kerberos cuando se usa una cuenta dMSA. Resulta que, durante ese proceso, el PAC (Certificado de Atributo de Privilegio) incluido en el ticket (básicamente las credenciales que prueban quién eres) no solo contiene el identificador de seguridad (SID) de la dMSA, sino también el de la cuenta de servicio original que está siendo reemplazada... y el de todos sus grupos asociados.
¿Y qué implica eso? Que en el momento en que alguien simula una migración de cuenta usando una dMSA, puede heredar todos los permisos que tenía la cuenta original, incluso si esta pertenecía a un administrador de dominio. Lo más preocupante es que este truco puede usarse incluso en entornos donde no se estén utilizando dMSA de forma activa. Basta con que la funcionalidad esté disponible y mal gestionada.
Un detalle que llama bastante la atención es que no hace falta tener control sobre la cuenta original para llevar a cabo este ataque. Lo único que se necesita es tener permiso para modificar ciertos atributos de alguna dMSA, cualquier dMSA. Es decir, si un usuario tiene ese acceso en una sola unidad organizativa (OU), ya tiene una puerta abierta.
Una vez que se marca una dMSA como sucesora de otro usuario, el Controlador de Dominio (KDC) da por hecho que hubo una migración legítima y otorga automáticamente a esa cuenta todos los privilegios del usuario anterior. Es como si dijera: “Ah, tú eres el nuevo encargado, toma las llaves de la casa”.
Aunque ya se notificó este fallo a Microsoft el 1 de abril de 2025, la compañía lo clasificó como un problema de gravedad moderada, y no ha lanzado aún una solución inmediata. ¿La razón? Argumentan que para explotar esta falla hace falta tener permisos específicos sobre objetos dMSA, lo que técnicamente implica una escalada de privilegios, y no un acceso inicial abierto.
Aun así, ya se está trabajando en una solución.
Mientras tanto, como no existe un parche oficial, la mejor medida es restringir la capacidad de crear dMSA lo más posible. Se recomienda también revisar y reforzar los permisos en las unidades organizativas (OU), sobre todo aquellos relacionados con la creación y gestión de cuentas.
También se ha compartido un script de PowerShell muy útil que identifica quién puede crear dMSA en tu entorno y en qué OUs tiene ese permiso. Esta herramienta puede ayudarte a tomar medidas preventivas antes de que alguien malintencionado lo haga por ti.
En resumen, esta vulnerabilidad abre una nueva vía de ataque de alto impacto que hasta ahora no se conocía. Cualquier usuario con permisos de "CreateChild" en una OU podría terminar comprometiendo cuentas críticas del dominio, con niveles de acceso comparables a los necesarios para ataques de tipo DCSync —esos que permiten robar toda la base de datos de contraseñas del dominio.
