GPO ACL débil, OU Tier 0, Active Directory: el pivote que anula el modelo de tiers que acaba de construir

GPO ACL Débil, OU Tier 0, Active Directory: Qué Es Realmente Esta Mala Configuración

GPO ACL débil, OU Tier 0, Active Directory: este vínculo es el control que la mayoría de los equipos olvida revisar una vez que su modelo de tiers ya está desplegado. Crear una unidad organizativa Tier 0 dedicada y bloquear la herencia de directivas en ella es un paso bien conocido — es R58 y R59 de ANSSI-PA-099, la guía de la agencia francesa de ciberseguridad sobre cómo asegurar la administración de Active Directory (consulte nuestro resumen de las recomendaciones de ANSSI para el conjunto más amplio). R58 exige una OU dedicada que agrupe los objetos Tier 0 — con una excepción explícita: las cuentas de equipo de los controladores de dominio y los usuarios y grupos integrados permanecen en sus OU predeterminadas; R59 exige que esta OU "restrinja las directivas de seguridad aplicables a la unidad organizativa Tier 0" bloqueando la herencia y asegurando que cualquier GPO vinculado o aplicado a ella esté dedicado a los recursos Tier 0 y sea editable únicamente por los administradores Tier 0.

Esa segunda mitad de R59 — "editable únicamente por los administradores Tier 0" — es la parte que silenciosamente queda fuera de alcance una vez que la estructura de OU está construida. Bloquear la herencia cierra un primer plano de control: qué directivas fluyen hacia abajo sobre la OU. No dice nada sobre un segundo plano de control, independiente: quién puede escribir en los objetos GPO ya vinculados allí. Un GPO es en sí mismo un objeto de Active Directory con su propia lista de control de acceso. Si esa ACL otorga derechos de edición a alguien por debajo del Tier 0 — un grupo de soporte técnico, una delegación de alguien que ya se fue y que nunca se limpió, un grupo de seguridad anidado un nivel más abajo de lo previsto — ese principal de baja confianza puede reescribir el contenido de la directiva, y Active Directory aplicará sus cambios a cada equipo y cuenta Tier 0 que el GPO alcance, con o sin bloqueo de herencia.

Este es un fallo más estrecho y específico que la cuestión general de cómo se construye un modelo de tiers en primer lugar. Un equipo puede implementar correctamente la jerarquía de OU de R58, superar cada revisión de la propia estructura de OU, y aun así desplegar una OU Tier 0 con un GPO con permisos débiles adjunto a ella — porque la ACL propia del GPO es un objeto separado que nadie pensó en revisar de nuevo una vez que el modelo de tiers se declaró terminado.

Cómo Funciona

Un Group Policy Object son en realidad dos artefactos mantenidos sincronizados: el Group Policy Container (GPC), un objeto de Active Directory bajo CN=Policies,CN=System,DC=<dominio> que lleva el descriptor de seguridad propio del GPO, y el Group Policy Template (GPT), la carpeta correspondiente en el recurso compartido SYSVOL que contiene los archivos de configuración reales. El vínculo entre un GPO y una OU es una tercera pieza separada: el atributo gPLink de la OU, que simplemente hace referencia al GPO por su GUID.

La propia documentación de Microsoft sobre el procesamiento de directivas de grupo confirma la mecánica detrás del requisito de "bloquear herencia" de R59: cada OU tiene un atributo GPOptions que puede bloquear directivas de contenedores de nivel superior, pero "aunque la herencia bloqueada impide que la mayoría de las configuraciones se apliquen a una OU, no afecta a las configuraciones aplicadas mediante GPO con la opción forzada (enforced)" — enforced es una propiedad del vínculo y tiene prioridad sobre el bloqueo de herencia, que es una propiedad del contenedor. Por eso exactamente R59 también exige comprobar que ningún GPO aplicado en modo forzado desde una OU superior sea editable por alguien fuera del Tier 0: el bloqueo de herencia por sí solo no detiene el problema de permisos de un GPO forzado, solo el de prioridad normal.

Nada de esto afecta a la ACL propia del objeto GPC. Por defecto, solo los Domain Admins, los Enterprise Admins y SYSTEM tienen derechos de edición sobre un GPO — la referencia de Microsoft Get-GPPermission muestra exactamente ese conjunto predeterminado en su propio ejemplo de salida, y denomina a este nivel de permiso GpoEditDeleteModifySecurity. Las ACL débiles aparecen por deriva, no por una única mala decisión: un GPO lo crea un administrador de un tier inferior mediante GPMC y más tarde se vincula a la OU Tier 0 sin que nadie reaudite quién sigue teniendo derechos de edición sobre él, o una delegación de soporte técnico limitada a un GPO concreto para una tarea concreta nunca se revoca, o un grupo de seguridad pensado para el Tier 1 recibe accidentalmente "Edit settings" durante una limpieza de permisos.

La Cadena de Ataque

Paso 1 — Encontrar el eslabón débil

Un atacante (o un auditor) enumera la ACL de cada GPO en busca de concesiones GenericAll, GenericWrite, WriteDacl o WriteOwner a un principal por debajo del Tier 0, y luego cruza el resultado con el gPLink de cada GPO sobre una OU Tier 0 — directamente, o a través de un GPO forzado desde una OU superior. Get-GPPermission -Guid <GUID del GPO> -All muestra un solo GPO a la vez — -Guid (o -Name) es obligatorio, por lo que el barrido debe iterar en lugar de ejecutarse una sola vez: cualquier titular cuyo Permission regrese como GpoEditDeleteModifySecurity — o una ACE personalizada que el cmdlet no pueda asignar a un nivel con nombre — y que no sea un principal Tier 0 reconocido es un hallazgo.

Paso 2 — Convertir la directiva en arma

La documentación de BloodHound de SpecterOps sobre el borde de abuso GenericWrite describe la técnica estándar: abrir el GPO en el Editor de administración de directivas de grupo y añadir "una directiva maliciosa que permita el destino a nivel de elemento, como una nueva tarea programada inmediata" — una función de Group Policy Preferences que ejecuta un comando arbitrario como NT AUTHORITY\SYSTEM la próxima vez que se aplique la directiva. Las herramientas nombradas para esto — SharpGPOAbuse en Windows, pyGPOAbuse en Linux — automatizan la escritura de ese XML de tarea programada en el GPO. La misma documentación señala un límite importante: GenericWrite limitado a "solo este objeto", sin ninguna otra ACE, no basta por sí solo — la configuración del GPT reside en SYSVOL, así que el atacante también necesita acceso de escritura a la carpeta SYSVOL de ese GPO para cambiar realmente lo que se despliega. En la práctica, las dos vías de acceso se conceden juntas con la frecuencia suficiente como para que esto sea una ruta de ataque real, no solo teórica — pero también es el detalle que separa un verdadero GPO con ACL débil de un falso positivo.

Paso 3 — Esperar la ventana de actualización

No se requiere acceso adicional después de la edición. Según la documentación de Microsoft citada arriba, los equipos miembro del dominio y los servidores vuelven a comprobar los cambios de GPO cada 90 minutos con un desfase aleatorio de hasta 30 minutos, mientras que los controladores de dominio comprueban cada cinco. El propio contenido de SYSVOL se replica entre controladores de dominio con una programación DFSR que puede bajar hasta 15 minutos dentro de un mismo sitio. Una vez que el cambio se aplica, cada equipo Tier 0 al que llega el GPO — para un GPO vinculado en la OU Tier 0, eso significa las estaciones de trabajo de administración Tier 0, las cuentas de administración y las cuentas de servicio alojadas allí — ejecuta la tarea del atacante como SYSTEM según su propia programación, sin necesidad de interacción. Los controladores de dominio son un salto aparte: R58 mantiene sus cuentas de equipo en la OU predeterminada OU=Domain Controllers, por lo que un GPO con ACL débil solo alcanza a un DC si también está vinculado a esa OU o aplicado a un contenedor superior en modo forzado.

Detección

El Event ID 5136 ("Se modificó un objeto de servicio de directorio") se dispara bajo la subcategoría Audit Directory Service Changes cada vez que se modifica un objeto con una entrada SACL adecuada para la auditoría de "Escritura" — no aparecerá en absoluto a menos que esa SACL esté configurada de antemano en los objetos contenedor GPO (o heredada desde CN=Policies,CN=System). El campo AttributeLDAPDisplayName del evento es lo que permite a un SIEM distinguir una edición de directiva rutinaria de un cambio de descriptor de seguridad; filtrar por ObjectClass=groupPolicyContainer aísla la actividad de GPO de cualquier otro cambio de servicio de directorio que este evento también cubre.

# Sweep every GPO for trustees with edit/full-control rights, then
# cross-reference against GPOs linked to a Tier 0 OU
Get-GPO -All | ForEach-Object {
    $gpo = $_   # keep the GPO: inside the nested pipeline $_ is a GPPermission
    Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -match 'GpoEdit|GpoCustom' } |
        Select-Object @{N='GPO';E={$gpo.DisplayName}}, Trustee, TrusteeType, Permission
}

Remediation

1. Inventariar la exposición. Liste cada GPO vinculado a la OU Tier 0, más cualquier GPO aplicado en modo forzado desde una OU superior — según ANSSI-PA-099 R59, ambos cuentan. (Get-GPInheritance -Target "<DN de la OU Tier0>").GpoLinks devuelve el conjunto vinculado directamente; compruebe manualmente las OU superiores en busca de vínculos forzados.
2. Revisar la pestaña Delegación. Para cada GPO, ábralo en GPMC y compruebe la pestaña Delegación, luego haga clic en Opciones avanzadas para ver la ACL en bruto en lugar de los niveles de permiso resumidos — la guía de delegación de Microsoft documenta esto como la vía compatible para añadir, quitar o inspeccionar los permisos Edit settings, delete, and modify security sobre un GPO.
3. Eliminar cualquier titular fuera del Tier 0 que tenga un nivel Edit, Edit/Delete/Modify Security, o Custom. Confirme que la carpeta SYSVOL correspondiente a ese GPO no concede por separado el mismo acceso de escritura a ese mismo principal — la ACL de AD y la ACL de SYSVOL son dos comprobaciones distintas sobre dos objetos distintos.
4. Reverificar la otra mitad de R59. Confirme que la herencia sigue bloqueada en la OU Tier 0, que la Default Domain Policy está vinculada allí con la prioridad más baja como especifica R59, y que ningún GPO forzado desde una OU superior sigue teniendo una ACL débil.
5. Repetir el barrido de la sección Detección de forma periódica, no solo una vez — los permisos de GPO derivan de la misma manera que las pertenencias a grupos, mediante delegaciones puntuales que nadie recuerda revocar. Este control pertenece a la misma rotación que una auditoría de seguridad de Active Directory más amplia, no a una limpieza puntual.

Cómo Detecta Esto EtcSec

El catálogo de cumplimiento de EtcSec rastrea exactamente este modo de fallo como ANSSI_R59_TIER0_OU_POLICIES: enumera cada vínculo de GPO habilitado, marca aquellos que apuntan a un GPO cuya propia ACL otorga acceso de escritura a un principal no administrador, y reporta un hallazgo por cada vínculo que recae sobre una OU Tier 0. Está emparejado con GPO_DANGEROUS_PERMISSIONS para el caso general de ACL de GPO débiles en cualquier parte del dominio, PATH_GPO_TO_DA para la vista de ruta de ataque de esta misma exposición, y ANSSI_R15_TIER_MODEL_VIOLATION para la cuestión más amplia de si el propio modelo de tiers está intacto.