Modificación de AdminSDHolder – Cómo funciona y estrategias de defensa

¿Qué es la modificación de AdminSDHolder?

AdminSDHolder es un contenedor especial en AD (CN=AdminSDHolder,CN=System,DC=...) que contiene un descriptor de seguridad utilizado para proteger cuentas y grupos privilegiados. El proceso SDProp copia periódicamente ese descriptor a objetos cuyo atributo adminCount es igual a 1, asegurando que estos objetos mantengan una ACL reforzada y no se debiliten por la herencia normal de ACL. Un atacante que pueda modificar la ACL de AdminSDHolder — o crear un objeto privilegiado con ACLs manipuladas o adminCount — puede hacer que ese cambio se aplique automáticamente a muchas cuentas privilegiadas a través de SDProp.

¿Cómo funciona la modificación de AdminSDHolder?

A continuación se muestra una cadena de ataque típica que demuestra cómo los adversarios abusan de AdminSDHolder y comportamientos relacionados.

1. Obtenga una posición inicial

El atacante obtiene acceso en el dominio — por ejemplo: un usuario de dominio con privilegios bajos, una cuenta de servicio comprometida, un administrador delegado (Operadores de Cuenta, Administrador de Esquema, etc.), o una credencial de automatización mal configurada. También pueden explotar una interfaz de gestión expuesta o un host vulnerable.

2. Reconocer la protección de AD y las ACLs

Desde el punto de apoyo, el atacante enumera objetos de directorio para descubrir el objeto AdminSDHolder y su ACL, quién tiene permisos de Escritura/Modificación en AdminSDHolder y CN=System, el conjunto de cuentas con adminCount=1, y la membresía de grupos privilegiados. Herramientas: PowerShell Get-ACL, consultas LDAP, scripts ADSI.

3. Identificar una ruta de modificación

El atacante busca un camino que permita cambiar las ACLs en AdminSDHolder (por ejemplo, un usuario delegado incorrectamente o un grupo con excesivos permisos como Operadores de Cuentas o una cuenta de servicio con derechos de escritura DS). Las cuentas de automatización/servicio con elevados derechos de escritura en AD o cuentas abandonadas con permisos persistentes son objetivos atractivos.

4. Modificar AdminSDHolder o ACL de objeto protegido

Si se permite, el atacante modifica el descriptor de seguridad AdminSDHolder para agregar una ACE que otorga a un principal elegido derechos poderosos (WriteDacl, FullControl, WriteProperty). Alternativamente, pueden cambiar las ACLs en una cuenta protegida individual o establecer adminCount=1 en una cuenta trasera. Métodos: Set-ACL, LDIF, ldapmodify, APIs nativas de Windows.

5. Espere a que SDProp se propague

SDProp se ejecuta periódicamente en los controladores de dominio y propaga el descriptor AdminSDHolder a todos los objetos donde adminCount=1. Una vez que ocurre la propagación, la ACE maliciosa se aplica a las cuentas protegidas — a menudo Administradores del Dominio — otorgando al atacante un acceso elevado persistente.

6. Utilice derechos elevados para persistir y moverse lateralmente

Con las nuevas ACL, el atacante puede tomar control de las cuentas de administrador de dominio (si se permite), leer/modificar configuración sensible (GPOs, confianzas), crear principios de servicio adicionales o cuentas de administrador oculto, y mantener persistencia que sobrevive a remedios simples si no se detectan cambios en las ACL.

✱ Variante: Modificación directa de adminCount o SD de objeto único

Un atacante con la capacidad de modificar objetos individuales puede establecer adminCount=1 en una cuenta elegida, convirtiéndola en un objetivo para SDProp, o reemplazar directamente el descriptor de seguridad de una cuenta de alto valor. Ambas variantes pueden proporcionar acceso privilegiado duradero.

Diagrama de flujo de ataque

Ejemplo: Perspectiva de la Organización

Un atacante compromete una cuenta de servicio utilizada por una herramienta de respaldo heredada. Dicha cuenta de servicio tiene permiso de escritura delegado en un subárbol bajo CN=System. El atacante escribe una ACE otorgando a su cuenta de atacante control total sobre AdminSDHolder, espera a SDProp y luego utiliza los privilegios elevados resultantes para tomar control de las cuentas de administrador de dominio y exportar secretos del dominio.

Ejemplos (patrones del mundo real)

Consecuencias de la modificación de AdminSDHolder

Modificar el descriptor AdminSDHolder o los objetos protegidos puede tener efectos devastadores:

Consecuencias financieras

El compromiso de cuentas privilegiadas puede llevar al robo de propiedad intelectual, registros financieros o información personal identificable de clientes, seguido de multas regulatorias, costos de respuesta a incidentes, honorarios legales y posibles demandas de rescate.

Interrupción Operativa

Un compromiso de dominio socava la autenticación y autorización en todo el entorno. Los servicios pueden deshabilitarse, AD puede requerir una remediación cuidadosa o reconstrucciones, y las operaciones comerciales pueden detenerse durante la recuperación.

Daño reputacional

La evidencia de compromiso de dominio señala fallos de seguridad significativos y puede dañar la confianza del cliente, las relaciones con socios y la reputación pública.

Impacto Legal y Regulatorio

La exposición de datos regulados puede desencadenar acciones de cumplimiento, investigaciones y multas relacionadas con el GDPR, HIPAA o normativas específicas del sector.

Objetivos comunes: ¿Quién está en riesgo?

Cuentas protegidas por AdminSDHolder

Domain Admins, Enterprise Admins, Schema Admins, Administrators

Cuentas de servicio y principios no humanos delegados

Cuentas de servicio a las que se les otorgó accidentalmente derechos de escritura en contenedores del sistema

Automatización heredada

Herramientas de respaldo, agentes de monitoreo, scripts de DevOps con capacidades de escritura en AD

Grandes dominios de AD con auditorías deficientes

Muchos permisos delegados y cuentas obsoletas

Evaluación de riesgos

Cómo prevenir la modificación de AdminSDHolder

La prevención requiere reducir quién puede editar AdminSDHolder y mejorar la detección & gobernanza.

Higiene de ACL y delegación

Restrinja los permisos en CN=AdminSDHolder: solo un conjunto mínimo de principios de alto privilegio de confianza deben tener WriteDacl, WriteOwner o FullControl. Audite los permisos delegados bajo CN=System y revoque los derechos excesivos. Evite otorgar escritura AD a cuentas de servicio no privilegiadas; utilice identidades privilegiadas dedicadas y controladas para la automatización.

Privileged Access Management (PAM)

Utilice el acceso JIT/de lo justo necesario para tareas de administración en lugar de privilegios permanentes. Use cuentas de servicio gestionadas (gMSA) y certificados/secreto de corta duración para los servicios donde sea posible.

Endurecimiento y controles de cuenta

Refuerce el acceso de emergencia / cuentas de romper el vidrio, deshabilite o elimine cuentas de servicio heredadas/sin usar y aplique la gestión del ciclo de vida.

Control de Cambios & Separación de Funciones

Requiere la aprobación de varias personas para cambios en objetos críticos de AD (AdminSDHolder, ACLs de raíz de dominio). Registra y revisa los tickets de cambio vinculados a cambios de ACL.

Verificaciones de línea base e integridad

Mantenga una copia de referencia del descriptor de seguridad de AdminSDHolder y compárelo periódicamente con el objeto en vivo; alerte sobre cualquier cambio. Escanee regularmente objetos con adminCount=1 y cuentas inesperadas en grupos privilegiados.

Estrategias de detección, mitigación y respuesta

Detección

• Audite y alerte sobre escrituras en CN=AdminSDHolder: habilite la auditoría de Servicios de Directorio (DS Access) para capturar modificaciones en AdminSDHolder y generar alertas para cambios de atributos en nTSecurityDescriptor o en la lista de control de acceso discrecional (DACL).
• Monitoree los cambios en adminCount: alertas cuando adminCount se establece en 1 para cuentas inusuales.
• Alerta sobre nuevas ACE que otorgan a los principios no administradores altos derechos sobre objetos protegidos.
• Esté atento a los picos en las modificaciones de cuentas protegidas (reseteos de contraseñas, cambios en las ACL).
• Monitoree los cambios en la membresía de grupos privilegiados y las adiciones inesperadas.

Respuesta

1. Elimine de inmediato las ACE maliciosas y restaure AdminSDHolder al último descriptor de seguridad conocido como bueno (o desde una copia de seguridad verificada).
2. Revocar el acceso del atacante: deshabilitar cuentas, rotar credenciales, revocar certificados/secreto de cuentas de servicio que fueron utilizados.
3. Invalidar sesiones de autenticación donde sea posible (forzar la purga de tickets Kerberos, imponer reautenticación).
4. Realice una evaluación de integridad de dominio e impacto: enumere dónde se propagó la ACE maliciosa, identifique cuentas privilegiadas comprometidas y busque artefactos laterales.
5. Realice restablecimientos de credenciales para las cuentas privilegiadas afectadas y rote los secretos de servicio.
6. Busque persistencia: verifique si se han creado principios de servicio, tareas programadas, GPOs con scripts maliciosos o entradas de delegación modificadas.

Mitigación

• Limite la exposición futura eliminando delegaciones de escritura innecesarias, reforzando los controles e implementando Privileged Access Management/JIT para actividades de administración.
• Mejore la auditoría e integre alertas en los libros de jugadas de IR para acelerar la detección y contención.

Cómo Netwrix puede ayudar

Netwrix Threat Prevention ayuda a detener el abuso de AdminSDHolder detectando y bloqueando cambios no autorizados en objetos críticos de AD en tiempo real. Crea un registro de auditoría completo y resistente a manipulaciones para cambios en objetos y atributos, y puede alertar automáticamente o prevenir acciones riesgosas como ediciones de DACL y modificaciones en grupos privilegiados o GPO, reduciendo el tiempo para la persistencia y la toma de control del dominio. Los equipos pueden personalizar políticas para asegurar contenedores sensibles y ejecutar una respuesta inmediata cuando se manipulan AdminSDHolder o cuentas protegidas, fortaleciendo la Data Security That Starts with Identity.

Impacto específico del sector

Evolución de los ataques y tendencias futuras

• Automatización del reconocimiento de ACL: los atacantes están automatizando búsquedas de contenedores de sistema con permisos de escritura y permisos delegados en grandes propiedades de AD.
• La combinación con otros ataques de AD — El abuso de AdminSDHolder se combina con cadenas de abuso de Golden Ticket / DCSync / ACL para una persistencia robusta.
• La exposición de la cadena de suministro y DevOps — la filtración de credenciales de automatización en pipelines sigue apareciendo como vectores para modificaciones delegadas de ACL.
• Menos acciones ruidosas, más sigilo: los atacantes prefieren las manipulaciones de ACL/DACL porque se mezclan con la actividad legítima del administrador.

Estadísticas Clave & Telemetría (controles sugeridos)

• Porcentaje de dominios con permisos de escritura no estándar en CN=System o AdminSDHolder (midiendo la higiene).

• Cantidad de cuentas con adminCount=1 y sin actividad legítima de administrador reciente.

• Número de cuentas de servicio con privilegios de escritura AD en el entorno.

Pensamientos finales

La modificación de AdminSDHolder es una técnica sigilosa de alto impacto: al atacar el mecanismo que AD utiliza para proteger cuentas privilegiadas, los atacantes pueden lograr una escalada de privilegios duradera y a nivel de dominio que sobrevive a muchos pasos de remediación simples. Defenderse contra esto requiere una estricta gobernanza de ACL, delegación de mínimo privilegio, controles de acceso privilegiado fuertes (Privileged Access Management/JIT), auditoría continua de los objetos AdminSDHolder y adminCount, y libros de jugadas de respuesta ensayados para eliminar rápidamente ACEs maliciosos y rotar las credenciales afectadas.