La superficie de ataque de los objetos de equipo en Active Directory es el término colectivo para los riesgos de delegación, derechos de replicación y pertenencia a grupos que suelen portar las cuentas de máquina — cuentas que Active Directory crea automáticamente para cada equipo unido al dominio, y que rara vez audita como audita las cuentas de usuario. A diferencia de las cuentas de usuario, las cuentas de equipo casi nunca reciben atención individual: nadie revisa su configuración de delegación, sus pertenencias a grupos, o su nivel de parcheo como lo haría con un usuario privilegiado. Es exactamente ese punto ciego el que explotan varias técnicas de ataque bien establecidas.
Este artículo cubre específicamente la superficie de ataque de los objetos de equipo — a diferencia de Delegacion Kerberos: no restringida, restringida y RBCD, que explica los propios mecanismos de delegación, y de Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin, que cubre la escalada por ACL de forma general. Aquí el foco es más estrecho: qué objetos de equipo de su dominio portan derechos peligrosos, y por qué es tan fácil pasarlos por alto.
Qué es la superficie de ataque de los objetos de equipo en Active Directory?
Cada máquina Windows unida al dominio obtiene una cuenta de equipo en Active Directory — un principal de seguridad de pleno derecho, con su propio SID, sus propias credenciales Kerberos (rotadas automáticamente, normalmente cada 30 días), y la capacidad de portar pertenencias a grupos y derechos de delegación igual que una cuenta de usuario. Ese es precisamente el punto: los servicios que se ejecutan como SYSTEM en una máquina unida al dominio se autentican ante el resto del dominio como esa cuenta de equipo.
El riesgo se deriva directamente de ese diseño. A una cuenta de equipo se le puede otorgar — deliberadamente o por deriva — las mismas categorías de derechos peligrosos que a una cuenta de usuario: delegación que le permite suplantar a otros usuarios, derechos de replicación que habilitan DCSync, o pertenencia a un grupo privilegiado. La diferencia está en la visibilidad: los equipos de seguridad revisan habitualmente qué usuarios son Domain Admins, pero rara vez preguntan qué equipos pueden actuar como tal.
Por qué los objetos de equipo pasan desapercibidos
Los flujos de aprovisionamiento crean objetos de equipo automáticamente, a menudo mediante imaging, enrolamiento Autopilot, o despliegue SCCM/Intune — sin ninguna revisión humana de los derechos del objeto resultante en el momento de su creación. Rutas de ataque como las cubiertas en Rutas de ataque AD: como se encadenan hasta Domain Admin encadenan precisamente este tipo de derecho no revisado con otras malas configuraciones para alcanzar Domain Admin; los objetos de equipo son un eslabón desproporcionadamente frecuente en esa cadena, precisamente porque rara vez son objeto de un ciclo de revisión dedicado como sí lo son las cuentas de usuario privilegiadas.
Delegación sin restricciones en un objeto de equipo
Cuando una cuenta de equipo está configurada para delegación sin restricciones (el flag de UserAccountControl TRUSTED_FOR_DELEGATION), cualquier usuario que se autentique ante un servicio en esa máquina tiene su Ticket Granting Ticket (TGT) completo — no solo un ticket de servicio — almacenado en caché en la memoria de esa máquina. Según el análisis ampliamente citado del investigador de seguridad Sean Metcalf sobre este riesgo, eso significa que un único host comprometido con delegación sin restricciones puede acumular los TGT de todos los usuarios que se autentican en él, incluidos los propios controladores de dominio cuando son inducidos a conectarse.
⚠️ Advertencia: la documentación de BloodHound de SpecterOps señala que un atacante que compromete un host con delegación sin restricciones puede combinarlo con una técnica de coerción de autenticación de DC (como PrinterBug o PetitPotam) para capturar el propio TGT de un controlador de dominio — y desde ahí solicitar tickets de servicio como cualquier usuario, incluidos los Domain Admins.
Por qué sigue existiendo
La delegación sin restricciones fue el modelo de delegación original de Windows 2000 y ha sido reemplazada por la delegación restringida y RBCD para los casos de uso legítimos; la propia guía de Microsoft recomienda no usarla. Su principal riesgo hoy es de tipo heredado: servidores configurados así hace años — a menudo para servidores de impresión, despliegues web tempranos, o herramientas administrativas ad hoc — y nunca revisados de nuevo una vez que se olvidó la justificación original.
Abuso de la delegación restringida basada en recursos (RBCD)
La delegación restringida basada en recursos (RBCD) funciona de forma distinta a los modelos de delegación más antiguos: en lugar de configurarse en la cuenta que necesita delegar, se configura en el propio recurso destino, mediante el atributo msDS-AllowedToActOnBehalfOfOtherIdentity. Quien esté listado en ese atributo puede suplantar a usuarios arbitrarios ante ese recurso específico.
La implicación de seguridad se detalló en la investigación de Elad Shamir de 2019, «Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory». El hallazgo clave: cualquier principal con acceso de escritura sobre el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de un objeto de equipo puede configurar RBCD para él — sin necesitar los privilegios de nivel domain admin que exigían los modelos de delegación más antiguos. Eso incluye a un principal con solo los derechos GenericAll, GenericWrite, o WriteDacl/WriteProperty sobre el objeto de equipo destino. La investigación de Shamir también mostró que S4U2Self funciona en cualquier cuenta con un SPN, independientemente de su configuración TrustedToAuthForDelegation, y que la respuesta de Microsoft en su momento fue que esto «no era un problema que se fuera a solucionar mediante una actualización de seguridad» — el potencial de abuso de RBCD es consecuencia de su diseño, no un bug parcheable.
Por qué RBCD es un problema de ACL, no un problema de delegación
Esto convierte el abuso de RBCD fundamentalmente en un problema de ACL sobre objetos de equipo, no en un problema de configuración de delegación. Una cuenta de equipo con una concesión de ACL aparentemente de bajo riesgo, heredada de un proyecto pasado o del comportamiento por defecto de un instalador, puede convertirse en una primitiva de suplantación completa. Revisar solo el valor de msDS-AllowedToActOnBehalfOfOtherIdentity en sí pasa por alto la exposición — el punto de control real es quién está autorizado a escribir en él.
Derechos DCSync en manos de una cuenta de máquina
DCSync abusa de los derechos extendidos DS-Replication-Get-Changes y DS-Replication-Get-Changes-All, normalmente reservados a los controladores de dominio, para extraer los hashes de contraseña de cualquier cuenta a través del protocolo de replicación del directorio. Las cuentas de equipo de los controladores de dominio poseen estos derechos de forma legítima. El riesgo tratado aquí es distinto: una cuenta de equipo no-DC a la que se le han otorgado derechos que habilitan DCSync, deliberadamente o por accidente (por ejemplo, mediante una plantilla de ACL demasiado permisiva aplicada en la raíz del dominio, o derechos de replicación otorgados a una cuenta de servicio de backup/monitorización que resulta estar vinculada a una máquina).
La documentación de BloodHound de SpecterOps describe la arista DCSync como la combinación de estos dos derechos en cualquier principal — usuario, grupo, o equipo — y señala que también puede surgir indirectamente a través de malas configuraciones de delegación restringida, sin que el objeto llegue a poseer explícitamente los derechos de replicación.
Equipos en grupos privilegiados
Una cuenta de equipo añadida a un grupo privilegiado (Domain Admins, Enterprise Admins, o un grupo Tier 0 personalizado) otorga derechos equivalentes a Domain Admin a cualquier cosa que se ejecute como SYSTEM en esa máquina — lo que, en la práctica, significa cualquiera que consiga ejecución de código en ella. Es un perfil de exposición distinto al de una cuenta de usuario privilegiada: una estación de trabajo o un servidor de aplicaciones suele ser más fácil de comprometer que un endpoint administrativo endurecido, y su contexto SYSTEM está disponible para muchas más rutas de código (tareas programadas, servicios, cuentas de administrador local) que una única sesión de usuario interactiva.
Este es el mismo problema estructural cubierto en Anidamiento de Grupos AD: Rutas Ocultas a DA — una pertenencia a un grupo que parece intrascendente de forma aislada se vuelve peligrosa en cuanto se rastrea quién controla efectivamente la máquina que la porta.
Sistemas operativos obsoletos que aún están en el dominio
Los objetos de equipo que ejecutan versiones de Windows más allá de su ciclo de soporte — Windows XP, Windows Server 2003, o anteriores — ya no reciben actualizaciones de seguridad de Microsoft, ni siquiera para vulnerabilidades activamente explotadas. Un controlador de dominio o un servidor miembro con un sistema operativo obsoleto es un punto débil permanente e imposible de parchear, y como estos sistemas suelen mantenerse en línea por una aplicación heredada concreta, tienden a quedar excluidos de los procesos rutinarios de gestión de parches y vulnerabilidades en lugar de señalarse como la exposición de máxima prioridad que realmente representan.
Estos sistemas se solapan con frecuencia con el patrón descrito en Cuentas Obsoletas y Sobreprivilegiadas en AD: ambas son exposiciones que persisten precisamente porque nadie asume la decisión de eliminarlas.
Detección
| Indicador | Qué revisar | Notas |
|---|---|---|
| Delegación sin restricciones | Objetos de equipo con TRUSTED_FOR_DELEGATION (bit userAccountControl 0x80000 / ADS_UF_TRUSTED_FOR_DELEGATION) activo | Marcar cada coincidencia; esto debería ser una excepción explícita, no un valor por defecto |
| Configuración RBCD | msDS-AllowedToActOnBehalfOfOtherIdentity no vacío en objetos de equipo | Cruzar quién puede escribir este atributo, no solo quién figura actualmente en él |
| Derechos que habilitan DCSync | DS-Replication-Get-Changes / DS-Replication-Get-Changes-All otorgados a principales no-DC | Auditar en la raíz del dominio y en cualquier OU donde se hayan podido delegar derechos de replicación |
| Pertenencia a grupo privilegiado | Cuentas de equipo en Domain Admins, Enterprise Admins, o grupos Tier 0 | Cualquier coincidencia merece investigación — los casos de uso legítimos son raros |
| Sistema operativo obsoleto | Atributo operatingSystem para versiones más allá del ciclo de soporte de Microsoft | Incluir explícitamente a los controladores de dominio — no están exentos |
💡 Consejo: BloodHound (SpecterOps) mapea la delegación sin restricciones, RBCD, y los derechos que habilitan DCSync como aristas de grafo, lo que permite ver estas exposiciones como rutas de ataque hacia Domain Admin en lugar de como hallazgos aislados sobre objetos individuales.
Remediación
1. Marcar las cuentas sensibles como no delegables
Active el flag «La cuenta es confidencial y no se puede delegar» en las cuentas de alto valor, para que no puedan ser capturadas ni siquiera por un host comprometido con delegación sin restricciones.
2. Eliminar la delegación sin restricciones siempre que sea posible
Migre los casos de uso legítimos a delegación restringida o RBCD, que limitan la suplantación a servicios destino específicos.
3. Auditar cada configuración RBCD — y las ACL que permiten definirla
Revise msDS-AllowedToActOnBehalfOfOtherIdentity en todos los objetos de equipo, y — más importante aún — revise quién posee los derechos GenericAll/GenericWrite/WriteDacl que les permitirían configurarla en primer lugar.
4. Eliminar los derechos que habilitan DCSync de los principales no-DC
Audite las concesiones de DS-Replication-Get-Changes / DS-Replication-Get-Changes-All en la raíz del dominio y en cualquier OU delegada.
5. Retirar las cuentas de equipo de los grupos privilegiados
Salvo que exista una razón específica, documentada y revisada para esa pertenencia, trate cualquier coincidencia como un hallazgo que remediar, no como una configuración que tolerar indefinidamente.
6. Retirar o aislar los sistemas con SO obsoleto
Cuando el retiro no sea posible de inmediato, aísle el sistema en la red y elimine cualquier derecho privilegiado o pertenencia a grupo que posea.
# Listar objetos de equipo configurados para delegación sin restricciones
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, OperatingSystem
# Listar objetos de equipo con una configuración RBCD establecida
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' }
Cómo detecta esto EtcSec
La categoría Computers de EtcSec cubre directamente esta superficie de ataque: COMPUTER_UNCONSTRAINED_DELEGATION, COMPUTER_RBCD, COMPUTER_DCSYNC_RIGHTS, y COMPUTER_IN_ADMIN_GROUP señalan los riesgos de delegación, derechos de replicación y pertenencia a grupos descritos arriba, mientras que COMPUTER_OS_OBSOLETE_XP y COMPUTER_OS_OBSOLETE_2003 señalan los sistemas operativos fuera de soporte que aún están presentes en el dominio.
ℹ️ Nota: EtcSec comprueba automáticamente cada objeto de equipo del dominio para estas condiciones en cada auditoría de AD, tratando las identidades de máquina con el mismo escrutinio que las cuentas de usuario privilegiadas. Ejecute una auditoría gratuita para ver qué objetos de equipo de su entorno portan estos derechos.
Referencias principales
- Elad Shamir: Wagging the Dog — Abusing Resource-Based Constrained Delegation to Attack Active Directory
- ADSecurity.org (Sean Metcalf): Active Directory Security Risk #101 — Kerberos Unconstrained Delegation
- SpecterOps BloodHound Documentation: DCSync edge
- SpecterOps BloodHound Documentation: CoerceToTGT edge
- hackndo: Resource-Based Constrained Delegation — Risks
- Microsoft Learn: Making the second hop in PowerShell Remoting (contexto sobre delegación)
Explore las páginas de identidad que apoyan este tema