Jorge de Almeida Pinto

Principales resultados

  • BadSuccessor, una técnica de escalada de privilegios que explota las cuentas de servicio gestionadas delegadas (dMSA), presenta un alto riesgo para las organizaciones que utilizan incluso un controlador de dominio (DC) Windows Server 2025. La técnica se puede utilizar para hacerse pasar por cualquier cuenta de Active Directory (AD), incluso los administradores de dominio, la cuenta KRBTGT o cualquier otra cuenta habilitada o deshabilitada con privilegios elevados.
  • Jorge de Almeida Pinto, Jefe Senior de Respuesta a Incidentes de Semperis, descubrió una forma de bloquear completamente el caso de uso de migración dMSA, lo que impide eficazmente que los atacantes utilicen indebidamente un dMSA para tomar potencialmente el control de un dominio AD.
  • La solución se configura en el esquema AD y debe aplicarse a todos los bosques AD.
  • Esta mitigación del riesgo puede aplicarse hasta que Microsoft haya publicado un parche para mitigar la vulnerabilidad.

Hasta Windows Server 2025, AD y Windows admitían cuentas de servicios gestionados independientes (sMSA) y cuentas de servicios gestionados de grupo (gMSA). Windows Server 2025 introduce un nuevo tipo de cuenta de servicios gestionados: las cuentas de servicios gestionados delegadas.

Este nuevo tipo de cuenta está diseñado para mejorar la gestión de credenciales de las cuentas de servicio basadas en usuarios, ya que admite la migración de la cuenta de servicio heredada a una dMSA.

Los investigadores de Akamai1 descubrieron que los atacantes pueden crear y configurar fácilmente un dMSA, y luego abusar de él para hacerse pasar por cualquier entidad de seguridad autenticable en AD. Denominaron a esta técnica de ataque BadSuccessor.

En esta entrada de blog, proporcionamos una introducción detallada e información para mitigar la vulnerabilidad, incluyendo código PowerShell para implementar la solución sugerida para bloquear el caso de uso de migración.

¿Por qué es necesario bloquear BadSuccessor?

Cuando se utiliza según lo previsto, la migración dMSA sólo admite oficialmente cuentas de servicio heredadas como origen (tipo de cuenta user). Sin embargo, el ataque BadSuccessor funciona con cualquier tipo de cuenta autenticable como fuente, incluyendo, cuentas de ordenador, sMSAs, gMSAs, e incluso dMSAs. Además, no importa si la cuenta de origen está habilitada o deshabilitada.

Los únicos componentes necesarios para ejecutar este ataque son:

  • Al menos un 2025 DC grabable
  • Un dMSA (vulnerable) y el utillaje adecuado

Además, no es necesario que el ataque tenga lugar en Windows Server 2025.

El núcleo del ataque BadSuccessor comienza con la capacidad de crear un nuevo dMSA o controlar un dMSA existente. Por lo tanto, la delegación del control de cualquier dominio AD existente requiere una revisión y acción inmediatas.2

Dada la posibilidad de que el dominio AD se vea completamente comprometido, debería tomar medidas para mitigar este riesgo tan pronto como haya introducido su primer DC con capacidad de escritura de Windows Server 2025, incluso si todavía no está utilizando dMSA.

Cómo detectar BadSuccessor: Indicadores de exposición y compromiso

Microsoft aún no ha proporcionado un parche para mitigar esta vulnerabilidad. Semperis ha añadido capacidades de detección en Directory Services Protector DSP) para defenderse de BadSuccessor. La plataforma DSP se ha mejorado con un nuevo indicador de exposición (IOE) y tres nuevos indicadores de compromiso (IOC) centrados en permitir la detección y mitigación de la actividad maliciosa que involucra dMSAs.

¿Cuáles son los casos de uso de dMSA?

Microsoft diseñó el dMSA para un caso de uso específico y difícil de resolver que muchas organizaciones tienen hoy en día. En la práctica, un dMSA admite dos casos de uso.

Debido a los múltiples casos de uso, cualquier dMSA tiene un estado que determina cómo se utiliza el dMSA y que se registra en el atributo msDS-DelegatedMSAState.

Los estados admitidos son:

  • 0: No utilizado (este estado es el predeterminado cuando no está definido)
  • 1: Migración iniciada
  • 2: Migración de uso finalizada
  • 3: Uso autóctono

Un dMSA se puede utilizar como se utiliza un gMSA. En ese caso, el estado del dMSA será 3, lo que significa que se utiliza de forma nativa.

El dMSA fue diseñado para soportar la migración de una cuenta de servicio heredada a un dMSA para una mejor y mejorada gestión de credenciales sin afectar la funcionalidad de un servicio, aplicación o tarea programada que utiliza la cuenta de servicio heredada. Una gestión de cre denciales mejorada significa técnicamente una rotación de contraseñas más frecuente y automatizada utilizando una contraseña más fuerte y compleja.

La migración de la cuenta de servicio heredada a la dMSA la inicia un administrador. El estado tanto de la cuenta de servicio heredada como de la dMSA cambia a 1-migración iniciada. Una vez que el administrador complete la migración y el estado tanto de la cuenta de servicio heredada como de la dMSA cambie a 2-Migración completada: la configuración específica de la cuenta de servicio heredada se migra al dMSA. Sin embargo, la pertenencia a grupos de la cuenta de servicio heredada no se migra al dMSA y permanece con la cuenta de servicio heredada.

Durante el primer estado de migración, el sistema descubre automáticamente dónde se está utilizando la cuenta de servicio heredada y configura la dMSA en consecuencia. En el segundo estado de migración, cuando el sistema intenta autenticarse utilizando la cuenta de servicio heredada (desactivada), la dMSA se hace cargo de la autenticación.

Cuando el dMSA se hace cargo de la autenticación, el controlador de dominio Windows Server 2025 fusiona el certificado de atributo privilegiado (PAC) de la cuenta de servicio heredada y el PAC del dMSA en un PAC que contiene todas las pertenencias a grupos combinadas y otros objectSID aplicables. Por lo tanto, el dMSA hereda todos los derechos, permisos y accesos de usuario para que pueda sustituir a la cuenta de servicio heredada sin que ello afecte al servicio, la aplicación o la tarea programada.

Lo bueno: la sucesión dMSA, como estaba previsto

Los siguientes cmdlets de PowerShell están disponibles para la migración de una cuenta de servicio heredada a una dMSA.

CMDlet PowerShellAcción
Start-ADServiceAccountMigrationIniciar la migración de la cuenta de servicio heredada a la dMSA. Este estado pasa de inicial a iniciado. Sólo puede ejecutarse cuando el estado es 0.
Complete-ADServiceAccountMigrationCompleta la migración de la cuenta de servicio heredada a la dMSA. Transita de iniciado a completado. Sólo puede ejecutarse cuando el estado es 1.
Undo-ADServiceAccountMigrationDeshacer el último paso de la migración y volver al paso anterior. Transiciones de completado a iniciado o de iniciado a inicial. Sólo puede ejecutarse cuando el estado es 1 o 2.
Reset-ADServiceAccountMigrationRestablece la migración al estado inicial, deshaciendo todo. Transiciones de completada o iniciada a inicial. Sólo puede ejecutarse cuando el estado es 1 o 2.

Según el cmdlet de PowerShell que se utilice, se utiliza un atributo operativo con datos de entrada contra el RootDSE de un DC con capacidad de escritura. Cuando esto ocurre, se ejecutan varias acciones simultáneas contra la cuenta de servicio heredada de destino y el dMSA de destino. Los cmdlets de PowerShell o el atributo operacional sólo pueden ser utilizados por miembros del grupo Domain Admins.

Para una mejor comprensión de lo que hace cada cmdlet de PowerShell, he aquí una descripción más detallada de las acciones.

Al utilizar Start-ADServiceAccountMigrationel sistema está ejecutando las siguientes acciones:

  • En la cuenta del servicio heredado:
    • Establecer msDS-SupersededServiceAccountState a 1
    • Establecer msDS-SupersededManagedAccountLink al DN de la dMSA objetivo
  • En la dMSA:
    • Establecer msDS-DelegatedMSAState a 1
    • Establecer msDS-ManagedAccountPrecededByLink al DN de la cuenta del servicio heredado objetivo
    • Asignar permisos de lectura a la cuenta del servicio heredado de destino en todos los atributos del dMSA de destino.
    • Asignar permisos de escritura a la cuenta del servicio heredado objetivo en el atributo msDS-GroupMSAMembership de la dMSA objetivo

Al utilizar Complete-ADServiceAccountMigrationel sistema está ejecutando las siguientes acciones:

  • En la cuenta del servicio heredado:
    • Establecer msDS-SupersededServiceAccountState a 2
    • Desactivar la cuenta
  • En la dMSA:
    • Establecer msDS-DelegatedMSAState a 2
    • Elimine los permisos de lectura previamente asignados a la cuenta de servicio heredada en cuestión de todos los atributos del dMSA.
    • Eliminar del atributo los permisos de escritura previamente asignados a la cuenta de servicio heredada objetivo msDS-GroupMSAMembership de la dMSA
  • Desde la cuenta de servicio heredada al dMSA, traslade las siguientes configuraciones:
    • Nombres principales de servicio (SPN)
    • Permitir delegar en la lista
    • Delegación restringida basada en recursos
    • Política de autenticación asignada
    • Silo de autenticación asignado
    • Autenticación de confianza para delegación UAC Bit

Al utilizar Reset-ADServiceAccountMigrationtodas las acciones ejecutadas por Start-ADServiceAccountMigration o Complete-ADServiceAccountMigration se deshacen, y tanto la cuenta de servicio heredada como la dMSA vuelven a su estado inicial.

Al utilizar Undo-ADServiceAccountMigrationtodas las acciones ejecutadas por Start-ADServiceAccountMigration o Complete-ADServiceAccountMigration se deshacen y tanto la cuenta de servicio heredada como la dMSA vuelven al estado anterior a la ejecución de, respectivamente, Start-ADServiceAccountMigration o Complete-ADServiceAccountMigration. Técnicamente esto significa cualquiera de las siguientes transiciones:

  • De terminado a empezado
  • De principio a fin

Lo malo y lo feo: el abuso de la dMSA

Como descubrieron los investigadores de Akamai, los atributos de la cuenta de servicio heredada y la dMSA implicada en la migración no están protegidos de las escrituras LDAP normales. Cualquiera con al menos permiso de Propiedad de Escritura en los atributos de la dMSA -o cualquier otro permiso que pueda llevar a ese permiso- puede escribir datos. Desafortunadamente, esta laguna invalida las protecciones implementadas a través del cmdlet de PowerShell y el atributo operacional bajo el capó.

Además, en términos de validación, la autenticación de Windows Server 2025 writable DC parece considerar sólo dos atributos de la dMSA y nada de la cuenta de servicio heredada. Si el msDS-DelegatedMSAState de la dMSA se establece en 2 (y ni siquiera importa cómo ha llegado a ese estado), el DC comprobará qué cuenta está especificada en la directiva msDS-ManagedAccountPrecededByLink atributo.

Con esa información, y suponiendo que la cuenta solicitante (normalmente una cuenta de equipo, pero puede ser cualquier cosa) tiene permisos para solicitar la contraseña o las claves del dMSA, el DC con capacidad de escritura de Windows Server 2025 de autenticación fusiona el certificado de atributo privilegiado (PAC) de la cuenta de servicio heredada y el dMSA en un PAC. A continuación, el DC emite ese PAC fusionado en un TGS-REP a la cuenta solicitante.

El Nombre Distinguido (DN) de la cuenta en la carpeta msDS-ManagedAccountPrecededByLink puede ser cualquier cosa, y BadSuccessor aprovecha plenamente esta vulnerabilidad.

El uso de niveles administrativos ayuda a ocultar y proteger las cuentas con privilegios elevados (usuarios, servicios, equipos, sMSA, gMSA, dMSA). El objetivo aquí es "ocultar" las cuentas con privilegios elevados para que su DN no sea visible para ninguna cuenta con privilegios inferiores. También es importante tener en cuenta que el DN de las cuentas con privilegios elevados tampoco debe ser fácil de adivinar.

Este ataque puede convertirse rápidamente en un sucesor muy feo.

If an attacker knows the DN of the default domain Administrator account (CN=administrator,CN=Users, DC=<DOMAIN>,DC=<TLD>) or the KRBTGT account (CN=krbtgt,CN=Users,DC=<DOMAIN>,DC=<TLD>), they can misuse the controlled dMSA to completely take over the AD domain, and ultimately the AD forest.

OBSERVACIÓN: La cuenta KRBTGT puede trasladarse a un modelo de niveles protegido y oculto, pero Microsoft no recomienda hacerlo.3

OBSERVACIÓN: La cuenta de Administrador se puede mover a un modelo de niveles protegido y oculto. También es posible cambiarle el nombre.4

Si decide mover la cuenta de administrador de dominio predeterminada o la cuenta KRBTGT a la estructura administrativa por niveles, asegúrese de colocar ambas en una OU independiente (es decir, no combinada con otras cuentas) y conceda acceso a esa OU únicamente a las cuentas de administrador de nivel 0.

Cómo bloquear sucesores

Observando el funcionamiento interno actual de un dMSA desde un "sucesor bueno" y un "sucesor malo y feo", los objetivos de mi investigación eran:

  • R: Admite todos los casos de uso descritos
  • B: Permitir y apoyar al buen sucesor
  • C: Bloquear al sucesor malo y feo

Las escrituras LDAP regulares, como las descritas para el sucesor malo y feo, requieren que el actor tenga permisos específicos en un dMSA. El uso de los cmdlets de PowerShell requiere que el actor tenga membresía en Domain Admins.

Como señalé anteriormente, los cmdlets de PowerShell realizan acciones diferentes contra la cuenta de servicio heredada y la dMSA, aprovechando un atributo operativo con datos de entrada.

Con estas ideas, revisé el esquema de AD, en concreto la definición del esquema de la directiva msDS-ManagedAccountPrecededByLink ya que controla qué cuenta se migra (oficialmente) o se ataca (Figura 1).

Aunque el atributo msDS-DelegatedMSAState desempeña un papel importante, aún debe gestionarse mediante la ejecución de una escritura LDAP normal para poder establecer el estado del dMSA en 3 cuando se utiliza de forma nativa y no con fines de migración.

Figura 1: Definición del esquema original de AD del atributo msDS-ManagedAccountPrecededByLink con systemOnly establecido en FALSE

Mirando la definición del atributo mostrado, mi intención era bloquear las escrituras LDAP regulares y soportar escrituras de atributos operacionales. Con eso en mente, la propiedad systemOnly destacó, ya que esperaba que lograra el objetivo de la investigación. Ese atributo no puede modificarse como cualquier otro atributo normal. Primero hay que habilitar una característica del DC para que admita una acción de escritura especial y luego volver a deshabilitarla. La intención del bloqueo es impedir la ESCRITURA normal, pero permitiendo la LECTURA.

Vayamos paso a paso.

Figura 2 muestra la comprobación de la configuración del dMSA dMSA.weak.5 Esa dMSA tiene su estado inicial y ninguna cuenta está vinculada a ella (es decir, no se muestra ninguna cuenta).

Figura 2: Visualización de la configuración del dMSA: dMSA.weak

El atacante establece el estado de dMSA.weak a 2configura una cuenta vinculada (el administrador de dominio por defecto, que fue renombrado en este AD a ADM.TEC) y se añade a sí mismo como la cuenta autorizada para recuperar la contraseña/claves de la dMSA.6 (Figura 3). En este caso, la acción es posible porque el atacante tiene una cuenta que es miembro del grupo Operadores de cuentas heredadas.

Figura 3: Reconfiguración dMSA.weak por uso indebido

A continuación, comprobamos la configuración de dMSA.weak5 (Figura 4).

Figura 4: Visualización de la configuración de dMSA.weak

El dMSA tiene ahora el estado de migración completada 2, tiene una cuenta vinculada, y el atacante puede recuperar la contraseña/claves de la dMSA. Usando RUBEUS, por ejemplo, el ataque puede iniciarse contra la dMSA y especialmente contra la cuenta vinculada.

A continuación, eliminamos la configuración anterior6 y validamos que efectivamente se ha eliminado5(Figura 5 y Figura 6).

Figura 5: Eliminación de la configuración establecida anteriormente de dMSA.weak
Figura 6: Visualización de la configuración de dMSA.weak

Ahora podemos ver el estado del bloque7(Figura 7).

Figura 7: Revisión del estado del bloque en el atributo (False significa no bloqueado)

A continuación, habilitamos el bloque para el escenario de migración8(Figura 8).

Figura 8: Activación del bloque en el atributo (True significa bloqueado)

De nuevo, lo confirmamos viendo el estado del bloque7(Figura 9).

Figura 9: Revisión del estado del bloque en el atributo (True significa bloqueado)

El atacante ahora intenta de nuevo6

  • Establecer el estado de dMSA.weak a 2
  • Configurar una cuenta vinculada (de nuevo el administrador de dominio por defecto renombrado)
  • Añadirse a sí mismo como cuenta autorizada para recuperar la contraseña/claves del dMSA(Figura 10).

Ahora, la transacción no se completa porque el atacante no puede escribir el DN de la cuenta vinculada.
¡Objetivo C alcanzado!

Figura 10: Intento de reconfiguración dMSA.weak por uso indebido

Ahora, comprobemos de nuevo la configuración de dMSA.weak5 (Figura11).

Figura 11: Visualización de la configuración de dMSA.weak

Como la transacción completa falló, no se modificó nada. Si los atributos se escribieran individualmente, todos habrían tenido éxito, excepto la escritura en el atributo msDS-ManagedAccountPrecededByLink atributo. No se muestra nada porque no tiene valor.

Con el bloqueo activado, también falla la forma oficial de migrar una cuenta de servicio heredada a una dMSA(Figura 12). Es una lástima. Pero hay luz al final del túnel.

El bloque trata de impedir las escrituras contra el msDS-ManagedAccountPrecededByLink atributo. Si nos fijamos en los cmdlets PowerShell oficiales para la migración, sólo los cmdlets Start-ADServiceAccountMigration y Reset-ADServiceAccountMigration escribir en ese atributo. El cmdlet Undo-ADServiceAccountMigration también escribe en ese atributo al deshacer el paso de iniciado a inicial. En otras transiciones, no se necesita ni se ejecuta ninguna escritura en ese atributo.

Objetivos A y B: parcialmente alcanzados.

Figura 12: Inicio de la migración oficial de una cuenta de servicio heredada sVC.SQL a un dMSA llamado dMSA.SQL$

A continuación, desactivamos el bloque para el escenario de migración9(Figura 13).

Figura 13: Desactivación del bloqueo en el atributo (False significa no bloqueado)

Ahora, volvemos a ver el estado del bloque7(Figura 14).

Figura 14: Revisión del estado del bloque en el atributo (False significa no bloqueado)

Ahora, cuando el atacante intenta6:

  • Establecer el estado de dMSA.weak a 2
  • Configurar una cuenta vinculada (de nuevo el administrador de dominio por defecto renombrado)
  • Añadirse como cuenta autorizada para recuperar la contraseña/claves del dMSA

-lo consiguen porque de nuevo el bloque desaparece(Figura 15).

Figura 15: Reconfiguración dMSA.weak por uso indebido

Ahora, cuando comprobamos la configuración de dMSA.weak5 (Figura 16), vemos que el atacante tiene el estado de migración completado 2tiene una cuenta vinculada a la dMSA y está autorizado a recuperar la contraseña/claves de la dMSA.

Figura 16: Visualización de la configuración de dMSA.weak

Con el bloqueo desactivado, también podemos utilizar el método oficial para iniciar, completar y restablecer con éxito la migración de una cuenta de servicio heredada a un dMSA(Figura 17). Para este ejemplo, se utilizó otra cuenta de servicio heredada y dMSA, y la migración fue ejecutada por una cuenta de Administrador de dominio.

Figura 17: Inicio, finalización y restablecimiento de la migración de la cuenta de servicio heredada sVC.SQL a un dMSA llamado dMSA.SQL$

El bloqueo de BadSuccessor requiere una gestión práctica

Con esta solución, es posible bloquear el escenario de migración dMSA y, por tanto, cualquier uso indebido.

Seguimos animando a las organizaciones a que revisen proactivamente su modelo de delegación2 y actúen en consecuencia para mitigar cualquier riesgo. En este contexto, la revisión se centra en la creación y gestión de dMSA en cualquier dominio AD.

Las organizaciones que deseen actualizar a Windows Server 2025 AD o instalar un nuevo Windows Server 2025 AD pueden implementar esta solución para mitigar los riesgos de un ataque hasta que Microsoft haya publicado un parche.

La implementación del bloqueo en el escenario de migración se realiza en el esquema AD, y el cambio es reversible: Se puede poner en bloqueo8 y, en una fase posterior, poner en desbloqueo7. Esto significa que son posibles múltiples enfoques de gestión.

Es posible que su organización implemente este bloque porque no desea utilizar dMSA para el escenario de migración.

Si su organización desea utilizar dMSA para el escenario de migración, puede seguir implementando el bloqueo para proteger AD. Cada vez que desee iniciar la migración de una cuenta, puede eliminar el bloqueo por adelantado y volver a implementarlo después. Puede completar la migración de una cuenta con o sin el bloqueo.

Con este planteamiento, es posible alcanzar los objetivos A, B y C.

Incluso si implementa un bloque, los IOE e IOC de Semperis DSP ayudan a permitir una estrecha supervisión de los eventos de creación, gestión y autenticación de dMSA, así como de las modificaciones de atributos.

Más información sobre los peligros del exceso de privilegios en AD

Notas finales

  1. BadSuccessor: Abusando de dMSA para Escalar Privilegios en Active Directory
  2. (2025-05-25) Revisión del modelo de delegación antes de introducir los DC de W2K25 y mejorar la seguridad (debido a "BadSuccessor")
  3. Microsoft Learn: Atributos de la cuenta KRBTGT
  4. Microsoft Learn: Cuenta de administrador
  5. Bad Successor - VER DATOS EN ATRIBUTOS "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink"
  6. Bad Successor - WRITE DATA INTO ATTRIBUTES "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink"
  7. Sucesor Malo - VER ESTADO DEL BLOQUE
  8. Bad Successor - BLOQUE AÑADIR/ENABLECER
  9. Sucesor Malo - QUITAR/DESHABILITAR BLOQUEO

AVISO LEGAL

Este contenido se proporciona únicamente con fines educativos e informativos. Su objetivo es promover la concienciación y la corrección responsable de las vulnerabilidades de seguridad que puedan existir en los sistemas que usted posee o está autorizado a probar. El uso no autorizado de esta información con fines maliciosos, explotación o acceso ilegal está estrictamente prohibido. Semperis no respalda ni aprueba ninguna actividad ilegal y declina toda responsabilidad derivada del uso indebido del material. Además, Semperis no garantiza la exactitud o integridad del contenido y no asume ninguna responsabilidad por los daños derivados de su uso.