Explotando dMSA BadSuccessor
Con Windows Server 2025, nos llegó la "cuenta de servicio administrada delegada" (dMSA) [1]. Suena elegante, verdad? Es una idea noble: una forma moderna de reemplazar esas viejas y polvorientas cuentas de servicio, facilitando la migración [1].
Construyeron un carril expreso para migrar cuentas antiguas a estas nuevas dMSA. El problema, como descubrió el investigador Yuval Gordon, es que olvidaron poner un cerrojo a una puerta que esta medio abierta y con luces neon [1].
Esta vulnerabilidad de diseño, apodada BadSuccessor [1, 2], es la definición de "el camino al infierno está empedrado de buenas intenciones". Permite a un atacante con permisos que la mayoría considera "benignos" convertirse, sin mucho esfuerzo, en Administrador de Dominio [1, 2].
Cómo se supone que funciona esto?
La idea de la migración de dMSA es que si tienes una cuenta antigua (digamos, svc_sql), puedes migrarla a una nueva dMSA (digamos, DMSA$) [1].
El proceso de migración intencionado es complejo, pero la parte importante es esta: para que la transición sea suave, el KDC (el portero de Kerberos) ayuda. Cuando la migración finaliza, el KDC es lo suficientemente amable como para incluir los permisos (SIDs) de la cuenta antigua (svc_sql) en el ticket (PAC) de la nueva cuenta (DMSA$) [1]. De este modo, la nueva cuenta puede hacer todo lo que hacía la antigua sin que nadie se dé cuenta.
Parece lógico. Hasta que te pregunta ,cómo sabe el KDC que la migración fue legítima?
La Migración Falsificada: El Ataque BadSuccessor
Aquí es donde se pone divertido. Resulta que el KDC es demasiado confiado.
Para decidir si debe otorgar a tu dMSA los poderes de un Administrador de Dominio, el KDC no comprueba un historial de migración auditado, ni pide permiso al administrador. No. Comprueba dos atributos en el objeto dMSA [1]:
msDS-ManagedAccountPrecededByLink: Un atributo que simplemente apunta al DN de la cuenta que (supuestamente) está siendo reemplazada [1, 2].msDS-DelegatedMSAState: Un número que debe establecerse en2(migración completada) [1, 2].
El KDC nunca valida si alguna vez se ejecutó el comando Start-ADServiceAccountMigration [1]. Si esos dos atributos están configurados, el KDC se encoge de hombros, asume que eres el "sucesor legítimo" y te entrega los SIDs [1, 2].
Proceso de Explotación Técnico
Este ataque es ridículamente simple. Un atacante solo necesita dos permisos que a menudo se pasan por alto [1, 2].
Paso 1: Identificar Vector de Creación de Objetos
El atacante debe localizar una Unidad Organizativa (OU) dentro del dominio donde posea permisos CreateChild (o equivalentes) para crear nuevos objetos [1]. Esta configuración es sorprendentemente común; un estudio de Akamai reveló que el 91% de los entornos analizados tenían usuarios no administradores con estos privilegios [1].
Paso 2: Crear el Principal dMSA
Usando el permiso identificado, el atacante crea un nuevo objeto msDS-DelegatedManagedServiceAccount (dMSA) en la OU vulnerable [2]. Como "Creador Propietario" de este objeto, el atacante tiene control total sobre sus atributos [1].
Paso 3: Configurar la Migración Simulada
El atacante modifica los dos atributos clave en la dMSA recién creada para simular una migración completada. El atributo msDS-ManagedAccountPrecededByLink se establece para que apunte al Nombre Distinguido (DN) de la cuenta objetivo (ej. un Administrador de Dominio) [2].
Paso 4: Solicitar Ticket de Servicio (TGS) como dMSA
Finalmente, el atacante solicita un TGT para su dMSA maliciosa [1, 2]. Herramientas como Rubeus ahora soportan esta autenticación. El KDC procesa la solicitud, ve los atributos falsificados y emite un ticket que incluye los SIDs y privilegios de la cuenta víctima (Administrator) [1].
Game over. El KDC mira el objeto, ve el enlace falso, dice "¡Ah, eres el nuevo Administrador de Dominio!" y le entrega un ticket con todos los SIDs de Administradores de Dominio [1, 2]. El atacante no tuvo que tocar la cuenta de administrador real, ni modificar grupos [1].
extra Robo de Credenciales :)
Pensabas que eso era todo, verdad? Qué adorable.
Cuando el KDC emite el TGT para la dMSA, incluye amablemente una nueva estructura llamada KERB-DMSA-KEY-PACKAGE. Se supone que esto contiene las claves de la dMSA para que pueda descifrar tickets antiguos destinados a la cuenta que reemplazó [1].
Pero en lugar de solo incluir las claves de la dMSA, el KDC también empaqueta las claves de la cuenta víctima (específicamente, la clave RC4-HMAC) y las mete en el campo previous-keys [1, 2].
Esto significa que el atacante no solo suplanta al Administrador de Dominio. El KDC literalmente le entrega las credenciales del Administrador de Dominio. Es un ataque DCSync regalado por un permiso de CreateChild [1].
Mitigación y Detección
Vamos a ser directos:
Hay un parche? No [1, 2].
Qué dice Microsoft? Han reconocido el problema, pero (en el momento de la publicación) no lo consideran lo suficientemente grave para una solución inmediata, ya que requiere permisos existentes para crear/editar una dMSA [1].
¿Qué decimos nosotros? Discrepamos respetuosamente. Un permiso que se considera "benigno" (Crear Hijos en una OU) no debería ser una vía directa para comprometer todo el dominio [1].
Qué puedes hacer AHORA:
Dado que no puedes parchearlo, tienes que detectarlo y prevenirlo.
Prevención (La Mejor Opción):
Audita tu dominio ahora mismo para ver quién tiene permisos para crear objetos
msDS-DelegatedManagedServiceAccount. Akamai publicó un script de PowerShell para ayudar con esto [1, 2].Trata el permiso para crear dMSAs con la misma seriedad que el de
DCSync. Revisa quién tieneCreateChildoGenericAllen las OUs y restríngelo al máximo [2].
Detección (Si ya es demasiado tarde):
ID de Evento 5137 (Auditoría de Creación): ¡Alerta! Alguien creó un
msDS-DelegatedManagedServiceAccount. ¿Fue un administrador de confianza? ¿O fue "Usuario-Random-Marketing-OU"? [1, 2].ID de Evento 5136 (Modificación de Atributos): Esta es la pistola humeante. Alerta cada vez que alguien escriba en el atributo
msDS-ManagedAccountPrecededByLink. No hay ninguna razón legítima para que esto suceda fuera de una migración de dMSA planificada y aprobada [1, 2].ID de Evento 2946 (Autenticación de dMSA): Rastrea cuándo las dMSA solicitan tickets [1, 2].
En resumen, una nueva característica diseñada para la comodidad creó, sin querer, una de las rutas de escalada de privilegios más limpias y sigilosas en la historia reciente de Active Directory [1].
Referencias
[1] Y. Gordon, "BadSuccessor: Explotación de dMSA para derivar privilegios en Active Directory," Akamai Security Research Blog, 21 de mayo de 2025. [En línea]. Disponible: https://www.akamai.com/es/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory
[2] Unidad S.T.A².R.S, "BadSuccessor: Escalada de privilegios mediante abuso de dMSA en Active Directory," Tarlogic Blog, 27 de mayo de 2025. [En línea]. Disponible: https://www.tarlogic.com/es/blog/badsuccessor/
Última actualización