Contenido
Resumen ejecutivo
- Los investigadores de Akamai analizaron el parche de Microsoft para la vulnerabilidad conocida como BadSuccessor (CVE-2025-53779) para evaluar su eficacia.
- Llegamos a la conclusión de que, aunque el parche fue eficaz para mitigar una parte significativa del riesgo asociado con BadSuccessor, la técnica sigue vigente y sigue siendo relevante en determinados escenarios.
- En esta entrada de blog, detallamos dos técnicas que se basan en los mismos principios de BadSuccessor y que pueden permitir a los atacantes obtener credenciales y comprometer las cuentas de usuario.
En el DEF CON 2025, presentamos la historia de BadSuccessor, una vulnerabilidad de Active Directory (AD) que hace un uso indebido del nuevo tipo de cuenta de Windows Server 2025: delegated Managed Service Account (dMSA). La vulnerabilidad permite a un usuario con privilegios bajos ascender directamente a administrador de dominios.
Menos de una semana después, Microsoft asignó el identificador CVE-2025-53779 a la vulnerabilidad y lanzó un parche. La ruta de derivación directa está cerrada.
En esta entrada de blog, analizaremos el parche, explicaremos lo que ha cambiado y lo que no, y demostraremos que, aunque BadSuccessor ya no proporciona una derivación instantánea, sus mecanismos subyacentes siguen siendo importantes.
Si te perdiste la historia del origen, lee nuestra anterior publicación de blog sobre BadSuccessor.
Qué era BadSuccessor (antes del parche)
BadSuccessor hizo un uso indebido de la dMSA: un tipo de cuenta de Windows Server 2025 destinada a simplificar la administración de cuentas de servicio. Cuando una dMSA controlada se vinculaba a cualquier cuenta en AD, el Centro de distribución de claves (KDC) trataba la dMSA como la sucesora durante la autenticación.
Ese único enlace hacía dos cosas peligrosas a la vez: combinaba los privilegios efectivos de la cuenta de destino en el Privilege Attribute Certificate (PAC) de dMSA y devolvió un paquete de claves dMSA que incluía las claves Kerberos de destino (credenciales). Sin cambios de grupo, sin herramientas especializadas: solo un enlace silencioso y las utilidades de Windows integradas.
Lo más importante es que el listón estaba bajo: el control sobre cualquier unidad organizativa (OU) era suficiente. un atacante podría crear una dMSA allí y vincularla a cualquier objetivo, incluso a controladores de dominio, administradores de dominio, usuarios protegidos o cuentas marcadas como “confidenciales y que no se pueden delegar”, y comprometerlos inmediatamente.
Para obtener más información y ver una demostración, consulte nuestra anterior publicación de blog sobre BadSuccessor.
Parche de Microsoft para CVE-2025-53779
Antes del parche, nuestra suposición era sencilla: el error principal era que no tenía que realizar una migración real a través de la operación rootDSE migrateADServiceAccount: solo podía editar los atributos de enlace en una dMSA y el KDC lo aceptaría.
Esperábamos que Microsoft protegiera ese atributo para que únicamente la ruta de migración adecuada pudiera establecerlo, lo que impediría migraciones “simuladas”.
Después de instalar el parche, hicimos la prueba obvia: como usuario que controla una dMSA, escribí el atributo de enlace exactamente como antes. La escritura todavía tuvo éxito, sin una nueva protección en el atributo, y pude vincular una dMSA a cualquier cuenta. Pero cuando me autentiqué como la dMSA para “heredar” los privilegios y claves de destino, el KDC se negó a emitir un ticket (Figura).
The error when authenticating a dMSA with a one-sided link — failure occurs at ticket issuance
Esto nos llevó a fijarnos en el propio KDC. Los cambios en kdcsvc.dll fuerzan al KDC a validar la relación en el momento de lanzarse el ticket. Un enlace unidireccional desde la dMSA al destino ya no funciona.
En nuestra prueba, la única manera de obtener un ticket válido para una dMSA que está vinculada a otra cuenta después del parche fue hacer el enlace mutuo: El objetivo también debe hacer referencia a la dMSA, reflejando lo que produce una migración real. Así que, a diferencia de antes, “tener éxito” ahora requiere controlar el propio objeto de la cuenta, no solo la dMSA.
Esto significa que la aplicación de parches se implementó en la validación del KDC, no en las protecciones del lado del directorio en el atributo. El atributo todavía se puede escribir, pero el KDC no lo respetará a menos que el emparejamiento parezca una migración legítima.
Otro hecho interesante es que la migración sigue funcionando incluso si la cuenta de destino permanece activada (mientras que el flujo de migración formal la desactiva al finalizar).
Qué es BadSuccessor (después del parche)
Aunque la vulnerabilidad se puede corregir mediante un parche, BadSuccessor sigue existiendo como técnica; es decir, la verificación del KDC elimina la ruta de derivación anterior al parche, pero no mitiga el problema del todo.
Debido a que el parche no introdujo ninguna protección al atributo de enlace, un atacante puede heredar otra cuenta vinculando una dMSA controlada y una cuenta de destino.
Este hecho permite (al menos) dos prácticas primitivas que los expertos en protección deben esperar y supervisar:
- Adquisición de credenciales y privilegios
- Volcado de credenciales objetivo en dominios que ya son propiedad
Primitiva 1: adquisición de credenciales y privilegios (alternativa de credenciales en la sombra)
Hoy en día, si un atacante controla un principal de destino (p. ej., tiene GenericWrite en un usuario o equipo), puede ponerlo en peligro mediante la adición de una credencial oculta o mediante la realización de un ataque de Kerberoasting dirigido.
BadSuccessor abre una nueva ruta de ataque: si un atacante controla una dMSA, puede realizar un emparejamiento mutuo y solicitar un ticket para la dMSA. Esto le permite:
- Actuar con los privilegios efectivos del destino mientras se utiliza la identidad dMSA (útil cuando la cuenta de destino está estrechamente vigilada)
- Obtener las claves del destino del paquete de claves de la dMSA, que es más rápido y fiable que agregar un SPN y que el Kerberoasting (que afecta solo a usuarios, depende de un crackeo y es más ruidoso)
- Cambiar la telemetría para que el ataque solo genere registros en las↔ediciones de enlaces de destino de dMSA y la emisión del ticket de concesión de tickets (TGT) a dMSA
Primitiva 2: volcado de credenciales específicas en dominios que ya son propiedad (alternativa DCSync)
En un dominio ya comprometido, BadSuccessor proporciona una forma de volcar las claves de los principales mediante la emisión normal de tickets. No se trata de un sustituto de DCSync, sino más bien de una ruta diferente con señales diferentes que pueden eludir las detecciones existentes.
Cómo se puede detectar un ataque de BadSuccessor después del parche
BadSuccessor todavía se puede explotar a través de dos primitivas diferentes después de que se publicara el parche de Microsoft. Para detectar una posible actividad, pruebe lo siguiente:
- Listas de control de acceso al sistema (SACL): audite la creación de dMSA y los cambios en los atributos de enlace de migración en ambos lados: el enlace de la dMSA y el enlace de la cuenta reemplazada o anterior
- Indicaciones de comportamiento:
- entradas de registro repetidas que indican que se ha obtenido una contraseña de dMSA en una breve ventana
- Un usuario habilitado que parece estar vinculado a una dMSA (debería ser inusual)
- Un usuario previamente deshabilitado que se ha vinculado a una nueva dMSA
Para obtener una guía de detección más detallada, consulte nuestra anterior publicación de blog sobre BadSuccessor.
Mitigación
- Aplique el parche primero. Actualice los controladores de dominio de Windows Server 2025 para CVE-2025-53779.
- Reduzca la superficie de ataque. Revise los permisos de las OU, los contenedores y los objetos dMSA. Refuerce las delegaciones y elimine los derechos generales para que solo los administradores de nivel 0 puedan crear o modificar dMSA y sus atributos de enlace de migración.
Conclusión
Microsoft cerró la ruta de derivación directa al requerir un emparejamiento mutuo que parece una migración real; un enlace unilateral ya no da como resultado privilegios o claves. Pero BadSuccessor siempre ha sido algo más que un error: es una técnica. Se trata de un problema cada vez mayor dentro del sector: incluso después de que se haya solucionado la vulnerabilidad principal, los atacantes pueden seguir encontrando puntos de entrada alternativos.
BadSuccessor persiste después del parche como (1) una primitiva de adquisición de credenciales y privilegios cuando un atacante controla un principal de destino y una dMSA, y (2) una ruta sin replicación para volcar secretos en dominios que ya son propiedad.
Estos resultados no son novedosos: hay otras formas de lograr ambos. Sin embargo, cada uno de ellos tiene diferentes requisitos y telemetría, por lo que un atacante podría preferir BadSuccessor.
Un apunte final
Un breve apunte sobre la dMSA: desde mi punto de vista, la dMSA posterior al parche es una importante incorporación a la seguridad de AD. Si se utiliza según lo previsto, mejora la higiene de la cuenta de servicio y reduce los secretos de larga duración. Compartiré más información sobre la dMSA y por qué creo que es una gran incorporación en una entrada de blog de seguimiento. ¡Permanezca atento!
Etiquetas
