Malas configuraciones GPO como vector

Que son las malas configuraciones GPO?

Las malas configuraciones GPO no son solo un problema de hygiene administrativa. En Active Directory, un GPO con permisos de edicion demasiado amplios o con configuraciones inseguras aplicadas a sistemas sensibles se convierte en un mecanismo de distribucion masiva para errores operativos y para cambios maliciosos.

Un lector tecnico deberia separar dos planos distintos:

quien puede modificar un GPO
que configuracion distribuye ese GPO y a que alcance llega

Si solo se revisa el contenido del GPO pero no los permisos, o si solo se revisan los permisos pero no su linking y su scope, la auditoria queda incompleta.

Como funciona el riesgo en la practica

Un GPO vive en dos sitios a la vez:

el Group Policy Container (GPC) dentro de AD
el contenido asociado en SYSVOL

Esto significa que la seguridad real del GPO depende de:

permisos de edicion y lectura en el objeto y en su contenido
linking a OU, dominio o Domain Controllers OU
precedencia y herencia
configuraciones concretas que aplica a equipos o usuarios

La razon por la que el tema importa tanto es sencilla: un error en un GPO relevante puede afectar muchos equipos a la vez, incluidos sistemas de administracion o incluso Tier 0, si el alcance no se ha controlado bien.

Que revisar primero

1. Permisos de edicion sobre GPO

Microsoft documenta Get-GPPermission y Set-GPPermission como la forma correcta de revisar y administrar permisos de GPO.

Get-GPO -All | ForEach-Object {
  $gpo = $_
  Get-GPPermission -Guid $gpo.Id -All | Select-Object \
    @{N="GPO";E={$gpo.DisplayName}}, Trustee, Permission
}

El objetivo no es solo encontrar Domain Users. Tambien hay que revisar:

grupos delegados antiguos
cuentas de soporte o de operaciones que ya no deberian editar baselines
permisos heredados que nadie reviso tras una reorganizacion

2. Alcance del GPO

Un GPO mediocre ligado a una OU de pruebas no tiene el mismo impacto que uno ligado al dominio o a la OU de controladores de dominio. La pregunta clave es siempre: donde se aplica realmente?

3. Configuraciones que multiplican el riesgo

En este tema, los problemas tipicos que merecen prioridad son:

permisos peligrosos sobre GPO de alta sensibilidad
parametros de seguridad local o hardening debilitados
ausencia de Windows LAPS o despliegue incompleto
baselines incoherentes entre estaciones, servidores y sistemas Tier 0

Microsoft documenta Windows LAPS como el mecanismo recomendado para gestionar contraseñas de administrador local, tanto en AD como en Entra ID. Si LAPS falta, sigue existiendo el viejo problema de contraseñas locales compartidas o mal rotadas entre equipos.

Auditoria tecnica minima

Revisar permisos reales

Get-GPO -All | ForEach-Object {
  $gpo = $_
  Get-GPPermission -Guid $gpo.Id -All |
    Where-Object {$_.Permission -match "GpoEdit|GpoEditDeleteModifySecurity"} |
    Select-Object @{N="GPO";E={$gpo.DisplayName}}, @{N="Principal";E={$_.Trustee.Name}}, Permission
}

Revisar despliegue de LAPS

Get-ADComputer -Filter * -Properties msLAPS-PasswordExpirationTime |
  Select-Object Name, msLAPS-PasswordExpirationTime

Si el entorno sigue usando LAPS antiguo o no tiene LAPS en absoluto, el hallazgo no es solo "falta una feature". Es que la postura de administracion local sigue dejando demasiado valor a cualquier movimiento lateral exitoso.

Revisar GPO sobre sistemas sensibles

Los GPO ligados a:

OU de controladores de dominio
servidores de administracion
jump hosts
estaciones administrativas
grupos de servidores de infraestructura

merecen una revision manual, incluso aunque el inventario general salga limpio.

Revisar contenido que altera superficie de ataque

No todos los GPO peligrosos destacan por permisos. Algunos lo hacen por contenido. Conviene revisar con especial atencion:

configuraciones de auditoria que reducen visibilidad
politicas de seguridad local que aflojan restricciones
scripts de inicio o cierre distribuidos ampliamente
configuraciones que gestionan administradores locales o despliegues de software

El problema no es solo "un GPO editable". El problema es un GPO editable con contenido que da alcance o persistencia.

Comparar GPC y SYSVOL como una misma unidad de riesgo

En revisiones superficiales se valida el objeto AD y se olvida el contenido SYSVOL, o al reves. Eso deja ciego al equipo ante cambios que no aparecen en la misma consola. La comprobacion madura debe responder:

si el GPO tiene el owner esperado en AD
si la carpeta SYSVOL asociada conserva ACLs coherentes con ese mismo modelo de control
si hay scripts, plantillas o ficheros heredados que ya nadie usa pero que siguen desplegandose
si el control de cambios cubre tanto la configuracion como el contenido distribuido

Esta comprobacion no requiere inventar complejidad. Solo exige tratar el GPO como objeto compuesto y no como entrada aislada en una lista.

Revisar memberships locales y user rights con foco en impacto

Muchos equipos revisan passwords y auditoria, pero dejan en segundo plano las configuraciones que alteran privilegios locales. Conviene inspeccionar con prioridad:

Restricted Groups o Group Policy Preferences que añaden miembros a administradores locales
User Rights Assignment que concede logon local, acceso por red o capacidades de backup/restore a identidades inesperadas
despliegues de software o scripts que introducen binarios o tareas en hosts de alto valor

Si una modificacion GPO puede cambiar quien administra un equipo o que codigo se ejecuta al arrancar, ya no es un simple hallazgo de hygiene. Es una via de privilegio.

Detection

La deteccion util en GPO mezcla cambio y alcance.

Un evento como 5136 ayuda a ver modificaciones sobre objetos de directorio, pero por si solo no te dice si el cambio era aceptable. Conviene correlacionarlo con:

quien hizo el cambio
sobre que GPO
a que OU o dominio esta vinculado
si el GPO forma parte de una baseline sensible

Tambien conviene revisar regularmente:

cambios en permisos de GPO
cambios en linking
cambios en configuraciones que afectan credenciales locales, hardening o auditoria
despliegue real de LAPS por poblacion de equipos

La buena pregunta no es "hubo un cambio?". La buena pregunta es "hubo un cambio en un GPO cuyo alcance hace que ese cambio importe?".

Remediacion

1. Reducir permisos de edicion a un conjunto muy corto

Set-GPPermission -Name "Default Domain Controllers Policy" \
  -TargetName "Grupo-Soporte-Antiguo" \
  -TargetType Group \
  -PermissionLevel None

La lista de quienes pueden editar GPO de alta sensibilidad debe ser muy corta y muy facil de justificar.

2. Separar baselines por criticidad

No conviene mezclar controles de estaciones normales, servidores comunes y Tier 0 dentro de la misma logica de administracion. Si el mismo equipo que mantiene estaciones tambien puede tocar sin control GPO ligados a controladores de dominio, ya existe un problema de separacion de funciones.

3. Desplegar Windows LAPS donde falte

Update-LapsADSchema

Despues del esquema, la parte importante no es solo habilitar LAPS. Es verificar:

en que equipos se aplica
quien puede leer las contraseñas
si hay excepciones sin justificar
si la rotacion se esta produciendo realmente

4. Revisar SYSVOL y el contenido asociado

El GPO no es solo el objeto de AD. Si el contenido en SYSVOL queda fuera del mismo nivel de control, la postura sigue siendo debil. En ambientes grandes conviene tratar GPC y SYSVOL como una misma unidad de riesgo.

5. Validar que el GPO siga cumpliendo su objetivo legitimo

La remediacion correcta no termina cuando desaparece un permiso. Termina cuando el GPO sigue funcionando para el caso de uso legitimo y deja de ser una herramienta de distribucion amplia para identidades equivocadas.

6. Revisar excepciones de GPO como deuda tecnica real

En muchos entornos los peores problemas aparecen en excepciones: una OU que quedo sin baseline, un servidor excluido para una prueba, una delegacion temporal que se hizo permanente. La remediation madura requiere inventariar esas excepciones y decidir si siguen justificadas. Sin este paso, el hardening se queda bonito en el GPO principal y debil en la realidad operativa.

7. Validar la aplicacion real despues del cambio

Reducir permisos o limpiar contenido no basta si nadie comprueba que la policy resultante se sigue aplicando donde debe. Conviene verificar al menos:

gpresult o Get-GPResultantSetOfPolicy en una muestra de hosts sensibles
rotacion real de LAPS en estaciones y servidores objetivo
ausencia de grupos locales privilegiados añadidos por error
que el GPO ya no alcance OUs o sistemas que debieron quedar fuera

Esta validacion evita dos fallos comunes: romper una baseline legitima o dejar la configuracion antigua viva por herencia, precedence o unlink incompleto.

Validacion

La validacion correcta debe demostrar que:

los GPO criticos tienen permisos de edicion minimizados
su linking y scope siguen siendo los esperados
el despliegue de LAPS cubre los sistemas objetivo
las cuentas que leen o administran LAPS estan justificadas
los cambios no abrieron una nueva deriva entre baselines de estaciones, servidores y Tier 0

Un equipo tecnico serio no cierra este hallazgo con un screenshot de consola. Lo cierra con inventario, permisos, alcance y prueba de aplicacion efectiva. Tambien necesita una evidencia simple de ownership: quien puede cambiar el GPO, para que, y con que validacion posterior. Eso es lo que evita que la misma debilidad reaparezca tras el siguiente cambio urgente.

Evidencia que conviene guardar

Para no reabrir el mismo problema en la siguiente auditoria, merece la pena conservar:

inventario de GPO Tier 0 o de alto impacto con sus trustees de edicion
snapshot de links y OUs alcanzadas por cada baseline sensible
muestra de hosts donde se comprobo la aplicacion real tras el cambio
listado de principals con lectura de contraseñas LAPS y su justificacion

Ese paquete de evidencia es pequeño, pero permite distinguir una limpieza puntual de un control operativo sostenible.

Fuentes primarias

Como EtcSec detecta esto

EtcSec cubre este tema desde varios angulos:

GPO_DANGEROUS_PERMISSIONS
GPO_WEAK_PASSWORD_POLICY
GPO_LAPS_NOT_DEPLOYED

La pregunta util no es solo si el GPO existe. La pregunta util es si alguien que no deberia puede cambiar una politica con alcance suficiente para alterar el comportamiento de todo el dominio.

Malas configuraciones GPO como vector de ataque