Abusando de ACLs/ACEs de Active Directory

Reading time: 5 minutes

tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Resumen

Las Delegated Managed Service Accounts (dMSAs) son un nuevo tipo de principal de AD introducido con Windows Server 2025. Están diseñadas para reemplazar cuentas de servicio heredadas al permitir una “migración” de un clic que copia automáticamente los Service Principal Names (SPNs), membresías de grupo, configuraciones de delegación e incluso claves criptográficas de la cuenta antigua a la nueva dMSA, proporcionando a las aplicaciones una transición sin problemas y eliminando el riesgo de Kerberoasting.

Investigadores de Akamai encontraron que un solo atributo — msDS‑ManagedAccountPrecededByLink — indica al KDC qué cuenta heredada “sucede” a una dMSA. Si un atacante puede escribir ese atributo (y alternar msDS‑DelegatedMSAState → 2), el KDC construirá felizmente un PAC que hereda cada SID de la víctima elegida, permitiendo efectivamente que la dMSA impersonifique a cualquier usuario, incluidos los Administradores de Dominio.

¿Qué es exactamente una dMSA?

  • Construida sobre la tecnología gMSA pero almacenada como la nueva clase de AD msDS‑DelegatedManagedServiceAccount.
  • Soporta una migración optativa: llamar a Start‑ADServiceAccountMigration vincula la dMSA a la cuenta heredada, otorga a la cuenta heredada acceso de escritura a msDS‑GroupMSAMembership, y cambia msDS‑DelegatedMSAState = 1.
  • Después de Complete‑ADServiceAccountMigration, la cuenta reemplazada se desactiva y la dMSA se vuelve completamente funcional; cualquier host que anteriormente usó la cuenta heredada está automáticamente autorizado para obtener la contraseña de la dMSA.
  • Durante la autenticación, el KDC incrusta una pista KERB‑SUPERSEDED‑BY‑USER para que los clientes de Windows 11/24H2 reintenten de manera transparente con la dMSA.

Requisitos para atacar

  1. Al menos un Windows Server 2025 DC para que existan la clase LDAP de dMSA y la lógica del KDC.
  2. Cualquier derecho de creación de objetos o escritura de atributos en una OU (cualquier OU) – por ejemplo, Create msDS‑DelegatedManagedServiceAccount o simplemente Create All Child Objects. Akamai encontró que el 91 % de los inquilinos del mundo real otorgan tales permisos “benignos” de OU a no administradores.
  3. Capacidad para ejecutar herramientas (PowerShell/Rubeus) desde cualquier host unido al dominio para solicitar tickets de Kerberos. No se requiere control sobre el usuario víctima; el ataque nunca toca la cuenta objetivo directamente.

Paso a paso: BadSuccessor*escalada de privilegios

  1. Localiza o crea una dMSA que controles
bash
New‑ADServiceAccount Attacker_dMSA `
‑DNSHostName ad.lab `
‑Path "OU=temp,DC=lab,DC=local"

Dado que creaste el objeto dentro de una OU a la que puedes escribir, automáticamente posees todos sus atributos.

  1. Simula una “migración completada” en dos escrituras LDAP:
  • Establece msDS‑ManagedAccountPrecededByLink = DN de cualquier víctima (por ejemplo, CN=Administrator,CN=Users,DC=lab,DC=local).
  • Establece msDS‑DelegatedMSAState = 2 (migración completada).

Herramientas como Set‑ADComputer, ldapmodify, o incluso ADSI Edit funcionan; no se necesitan derechos de administrador de dominio.

  1. Solicita un TGT para la dMSA — Rubeus soporta la bandera /dmsa:
bash
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>

El PAC devuelto ahora contiene el SID 500 (Administrador) más los grupos de Administradores de Dominio/Administradores Empresariales.

Reúne todas las contraseñas de los usuarios

Durante migraciones legítimas, el KDC debe permitir que la nueva dMSA descifre tickets emitidos a la cuenta antigua antes de la transición. Para evitar romper sesiones activas, coloca tanto las claves actuales como las anteriores dentro de un nuevo blob ASN.1 llamado KERB‑DMSA‑KEY‑PACKAGE.

Debido a que nuestra migración falsa afirma que la dMSA sucede a la víctima, el KDC copia diligentemente la clave RC4‑HMAC de la víctima en la lista de claves anteriores – incluso si la dMSA nunca tuvo una contraseña “anterior”. Esa clave RC4 no está salada, por lo que es efectivamente el hash NT de la víctima, dando al atacante capacidad de cracking offline o “pass‑the‑hash”.

Por lo tanto, vincular masivamente miles de usuarios permite a un atacante volcar hashes “a gran escala”, convirtiendo BadSuccessor en un primitivo tanto de escalada de privilegios como de compromiso de credenciales.

Herramientas

Referencias

tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks