Malas configuraciones GPO como vector de ataque

¿Qué son las malas configuraciones de GPO?

Las malas configuraciones GPO convierten uno de los mecanismos de gestión más importantes de Active Directory en uno de sus vectores de ataque más peligrosos. Los Group Policy Objects (GPO) controlan los ajustes de seguridad, el despliegue de software, la ejecución de scripts y el entorno de usuario en cada equipo del dominio. Cuando sus permisos están mal configurados, crean uno de los vectores de ataque más potentes de Active Directory: un único GPO mal configurado enlazado a los Domain Controllers puede comprometer todo el dominio.

Las malas configuraciones de GPO son especialmente peligrosas porque combinan dos amenazas: movimiento lateral a gran escala (un GPO comprometido puede distribuir scripts maliciosos a cientos de equipos simultáneamente) y escalada de privilegios (permisos débiles en un GPO permiten que usuarios con pocos privilegios modifiquen políticas aplicadas a los propios Domain Controllers).

El otro problema crítico de GPO es la ausencia de LAPS. Sin Local Administrator Password Solution, todas las estaciones de trabajo del dominio comparten la misma contraseña de Administrador local. Basta con crackearla una vez en cualquier equipo -mediante un dump o un hash- para obtener admin local en todas las estaciones de trabajo del dominio.

Cómo funciona

Los GPO se almacenan como objetos en Active Directory y como archivos en el recurso compartido SYSVOL de los Domain Controllers. Cada GPO tiene dos componentes:

• GPC (Group Policy Container) - el objeto de AD, controlado por ACL de AD
• GPT (Group Policy Template) - archivos en \\dominio\SYSVOL\, controlados por ACL de NTFS

Ambos deben protegerse. Un atacante con acceso de escritura a cualquiera de los dos componentes puede inyectar contenido malicioso que se ejecuta en cada equipo al que se aplica el GPO.

Orden de procesamiento de Group Policy

Los GPO se aplican en este orden (en caso de conflicto, gana el último en escribir):

1. Política local
2. GPO a nivel de sitio
3. GPO a nivel de dominio
4. GPO a nivel de OU (de la OU padre a la hija)

Esto significa que un GPO enlazado a nivel de OU que contiene Domain Controllers se aplica a todos los DC de esa OU, lo que lo convierte en un objetivo de muy alto valor para los atacantes.

La cadena de ataque

Paso 1 - Enumerar permisos de GPO

# Encontrar todos los GPO donde cuentas sin privilegios tienen derechos de edición
Get-GPO -All | ForEach-Object {
  $gpo = $_
  $acl = Get-GPPermission -Guid $gpo.Id -All
  $links = ([xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)).GPO.LinksTo.SOMPath -join ", "
  $acl | Where-Object {
    $_.Permission -match "GpoEditDeleteModifySecurity|GpoEdit" -and
    $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM|Creator Owner"
  } | Select-Object `
    @{N="GPO";E={$gpo.DisplayName}},
    @{N="Trustee";E={$_.Trustee.Name}},
    @{N="Permission";E={$_.Permission}},
    @{N="LinkedTo";E={$links}}
}

Paso 2 - Identificar enlaces peligrosos

# Encontrar GPO enlazados a OU de alto valor (Domain Controllers, Tier 0)
Get-GPO -All | ForEach-Object {
  $gpo = $_
  $links = ([xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)).GPO.LinksTo | Where-Object { 
    $_.SOMPath -match "Domain Controllers|Tier0|Admin" 
  }
  if ($links) {
    Write-Host "GPO DE ALTO VALOR: $($gpo.DisplayName) - Enlazado a: $($links.SOMPath -join ', ')"
    Get-GPPermission -Guid $gpo.Id -All | Where-Object {
      $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM"
    }
  }
}

Paso 3 - Explotar permisos débiles (si se encuentran)

Si una cuenta con pocos privilegios tiene derechos GpoEdit sobre un GPO enlazado a los Domain Controllers, el atacante puede añadir un script de inicio malicioso que se ejecuta como SYSTEM en cada DC objetivo:

# El atacante modifica el GPO para añadir una tarea programada maliciosa
# Se ejecuta como SYSTEM en cada equipo dentro del alcance en el siguiente refresco de Group Policy
# Los Domain Controllers refrescan la política cada 5 minutos por defecto (no el intervalo
# de 90 minutos de estaciones de trabajo/servidores) - un GPO malicioso enlazado a una OU de DC
# se propaga rápido
# Se puede forzar de inmediato con: gpupdate /force

Paso 4 - Explotar la ausencia de LAPS para movimiento lateral

Sin LAPS, la cuenta de Administrador local en todas las estaciones de trabajo comparte la misma contraseña. Un único dump de hash lleva a movimiento lateral en todo el dominio:

# Obtener el hash del admin local desde cualquier equipo
# Usar pass-the-hash para autenticarse en todas las estaciones de trabajo (NetExec, el sucesor
# mantenido activamente del ya archivado CrackMapExec)
netexec smb 10.10.0.0/24 -u Administrator -H "aabbccdd11223344:aabbccdd11223344"
# Todos los equipos con la misma contraseña de admin local mostrarán [+]

Detección

Event IDs de Windows

Consultas de detección SIEM (Elastic KQL)

GPO modificado por una cuenta no administrativa:

event.code: "5136" AND
winlog.event_data.ObjectClass: "groupPolicyContainer" AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM" OR "*$")

Modificación de archivos en SYSVOL:

event.code: "4663" AND
file.path: (*\\SYSVOL\\*) AND
event.action: "File Write" AND
NOT winlog.event_data.SubjectUserName: ("SYSTEM" OR "*$")

Remediación

1. Corregir permisos peligrosos de GPO

# Eliminar permisos peligrosos de un GPO específico
Set-GPPermission -Name "Default Domain Controllers Policy" `
  -TargetName "Domain Users" -TargetType Group `
  -PermissionLevel None

# Auditar y corregir todos los GPO
Get-GPO -All | ForEach-Object {
  $gpo = $_
  Get-GPPermission -Guid $gpo.Id -All | Where-Object {
    $_.Permission -match "GpoEdit" -and
    $_.Trustee.Name -notmatch "Domain Admins|Enterprise Admins|SYSTEM"
  } | ForEach-Object {
    Set-GPPermission -Guid $gpo.Id -TargetName $_.Trustee.Name `
      -TargetType Group -PermissionLevel GpoRead
    Write-Host "Corregido: $($gpo.DisplayName) - $($_.Trustee.Name) rebajado a Read"
  }
}

2. Desplegar LAPS

# Windows LAPS viene integrado en Windows Server 2019/2022 (actualización de abril de 2023
# o posterior) y de forma nativa en Windows Server 2025 / Windows 11 22H2+ - no requiere
# instalación desde PowerShell Gallery. Confirme que el módulo está presente:
Get-Command -Module LAPS

# Extender el esquema de AD para LAPS (requiere Schema Admin)
Update-LapsADSchema

# Conceder permisos para que los DC escriban atributos LAPS
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"

# Configurar vía GPO:
# Computer Configuration > Administrative Templates > LAPS
# - Enable local admin password management: Enabled
# - Password complexity: mayúsculas + minúsculas + números + caracteres especiales
# - Password length: mínimo 20 caracteres
# - Password age: máximo 30 días

3. Reforzar los estándares de política de contraseñas en GPO

# Auditar todos los GPO que despliegan políticas de contraseñas
Get-GPO -All | ForEach-Object {
  $report = Get-GPOReport -Guid $_.Id -ReportType XML
  if ($report -match "MinimumPasswordLength") {
    # Extraer y verificar el valor
    $minLen = [regex]::Match($report, 
      '<MinimumPasswordLength[^>]*>(\d+)<').Groups[1].Value
    if ([int]$minLen -lt 14) {
      Write-Warning "Política de contraseñas débil en GPO: $($_.DisplayName) - MinLength: $minLen"
    }
  }
}

4. Proteger SYSVOL

# Verificar que las ACL de SYSVOL son correctas
# Solo Domain Admins y SYSTEM deben tener acceso de escritura
icacls "\\corp.local\SYSVOL\corp.local\Policies" /verify

# Habilitar la auditoría de cambios en SYSVOL vía GPO:
# Computer Configuration > Windows Settings > Security Settings > 
#   Advanced Audit Policy > Object Access > Audit File System: Success, Failure

Cómo lo detecta EtcSec

EtcSec audita cada GPO de su dominio en busca de permisos peligrosos, políticas débiles y controles ausentes.

GPO_DANGEROUS_PERMISSIONS identifica GPO donde cuentas sin privilegios tienen permisos de edición o modificación, especialmente GPO enlazados a OU de Domain Controllers, donde la explotación lleva directamente al compromiso total del dominio.

GPO_WEAK_PASSWORD_POLICY marca cualquier GPO que despliegue una política de contraseñas por debajo de los estándares de seguridad actuales: longitud mínima, requisitos de complejidad, antigüedad máxima e historial de contraseñas.

GPO_LAPS_NOT_DEPLOYED detecta entornos donde LAPS no está configurado vía GPO, dejando las contraseñas de Administrador local sin gestionar e idénticas en todas las estaciones de trabajo, lo que habilita movimiento lateral en todo el dominio a partir del compromiso de un solo equipo.

Preguntas frecuentes

¿Por qué son tan peligrosas las malas configuraciones de GPO? Un GPO mal configurado es peligroso por su escala. Un único GPO enlazado a los Domain Controllers puede ejecutar código como SYSTEM en todos los DC de la organización simultáneamente. A diferencia del compromiso de cuentas individuales, un GPO malicioso afecta a todos los equipos dentro de su alcance en el siguiente ciclo de refresco de Group Policy, potencialmente cientos de equipos en un plazo de 90 minutos.

¿Qué es LAPS y por qué debería desplegarlo? Local Administrator Password Solution (LAPS) gestiona automáticamente la contraseña de la cuenta de Administrador local en cada equipo unido al dominio, estableciendo una contraseña aleatoria única que rota según un calendario. Sin LAPS, todas las estaciones de trabajo suelen compartir la misma contraseña de Administrador local, lo que permite que un atacante que crackea el hash de un equipo se autentique en todas las demás estaciones de trabajo, una técnica llamada pass-the-hash.

¿Cuál es la configuración mínima de GPO que debo revisar? Priorice primero los GPO enlazados a los Domain Controllers y a las OU de Tier 0: son los objetivos de mayor impacto. Después audite la Default Domain Policy y la Default Domain Controllers Policy en busca de cambios de permisos no autorizados. Estos dos GPO por sí solos cubren la superficie de riesgo más crítica.

Prioridades de revisión

Malas configuraciones GPO: cómo Group Policy se convierte en vector de ataque debe tratarse como una exposición real dentro de su entorno de Active Directory, no como un ajuste aislado. Empiece por definir el perímetro de revisión: qué grupos privilegiados, cuentas de servicio, ACL, enlaces de GPO, trusts, ajustes de delegación, plantillas de certificados y estaciones de administración se ven afectados, qué flujos de negocio dependen de ellos, qué privilegios exponen y qué excepciones de emergencia se añadieron con el tiempo. Ese paso de scoping evita una remediación superficial, porque el síntoma técnico suele ser más pequeño que el radio de impacto operativo real. Al documentar la ruta completa desde la configuración hasta el privilegio, el equipo puede priorizar los cambios que reducen el riesgo rápidamente sin romper el acceso en producción. Esto también crea una línea base defendible para la validación posterior y da a la dirección una explicación clara de por qué el problema importa ahora.

Controles adyacentes a revisar

Cuando los atacantes alcanzan su entorno de Active Directory, rara vez se detienen en el primer punto débil. Alrededor de las malas configuraciones GPO, suelen comprobar si la ruta expuesta puede encadenarse con cuentas privilegiadas obsoletas, anidamiento de grupos inseguro, delegación excesiva, ajustes de contraseña débiles, rutas de GPO con permisos de escritura y abuso de ACL heredadas. Esto significa que los defensores deben revisar no solo la debilidad principal, sino cada dependencia cercana que convierte el acceso en persistencia o escalada de privilegios. Confirme qué identidades, roles, permisos y supuestos de confianza puede reutilizar un operador motivado. Si una corrección cierra un único objeto mientras deja intactas las rutas de privilegio adyacentes, el riesgo efectivo apenas cambia. Una revisión disciplinada de las oportunidades de encadenamiento es lo que convierte este tema en un ejercicio práctico de hardening en lugar de una casilla que se marca una sola vez.

Malas configuraciones GPO: validación antes del cierre

Una revisión sólida de las malas configuraciones GPO debe terminar con evidencia de producción, no con la suposición de que la ruta de riesgo desapareció. Antes de cerrar el hallazgo, vuelva a comprobar las identidades privilegiadas, los derechos delegados y el acceso heredado, la política, la ACL, el grupo o el alcance de GPO que realmente cambió, y la evidencia de logging o del collector asociada al hallazgo. Confirme que el estado más seguro se aplica al alcance que realmente importa: la OU de producción, la asignación de rol efectiva, la ruta de la aplicación o la ruta de trust y delegación que un atacante realmente abusaría. Registre el propietario técnico, la dependencia de negocio y la condición de rollback para que la siguiente revisión pueda determinar si el estado más seguro se mantuvo.

Use una checklist breve de cierre:

• verifique que el estado de riesgo desapareció desde el punto de vista del atacante, no solo desde una captura de pantalla del administrador
• conserve una exportación o muestra de log antes/después que demuestre que el alcance afectado cambió
• documente el propietario y la decisión de excepción si el control no pudo aplicarse por completo

Para la exposición adyacente, contraste el resultado con Anidamiento de Grupos AD: Rutas Ocultas a DA, Rutas de Ataque en Active Directory hacia Domain Admin, Supervisión de Seguridad AD: Event IDs y SIEM, y Cumplimiento AD y Azure: NIS2, ISO 27001, CIS Controls. El mismo hueco de control suele reaparecer en rutas de identidad cercanas, huecos de logging o permisos delegados, por lo que el paso final de validación importa tanto como el hallazgo inicial.

Malas configuraciones GPO: evidencia a conservar para el próximo ciclo de revisión

El siguiente revisor no debería tener que reconstruir el caso de memoria. Conserve la evidencia que originalmente justificó el hallazgo, la prueba de que el cambio se aplicó y la nota que explica por qué el estado final es aceptable. Para este tema, la evidencia más útil suele combinar la exportación actual de identidades, grupos o rutas delegadas afectadas, la prueba de configuración antes/después del control que cambió, y el ticket, el propietario y la nota de excepción que explica el estado final. Ese paquete compacto agiliza mucho las revisiones trimestrales o posteriores a un cambio, y ayuda a explicar si el problema se eliminó, se redujo o se aceptó formalmente.

Si un cambio posterior de administración, política o aplicación reabre la ruta, esta evidencia histórica también facilita demostrar qué se desvió. Eso es lo que convierte las malas configuraciones GPO de una comprobación puntual en un proceso de aseguramiento repetible.

Lecturas relacionadas

Revise este tema junto con Supervisión de Seguridad AD: Event IDs y SIEM, Seguridad de Contraseñas en Active Directory: Malas Configuraciones que Importan, Anidamiento de Grupos AD: Rutas Ocultas a DA, Ataques NTLM Relay: Secuestro de Autenticación en AD, y Rutas de Ataque en Active Directory hacia Domain Admin. Estos artículos adyacentes muestran cómo las mismas debilidades de identidad suelen encadenarse en una evaluación real, en lugar de aparecer como hallazgos aislados.

• Supervisión de Seguridad AD: Event IDs y SIEM
• Seguridad de Contraseñas en Active Directory: Malas Configuraciones que Importan
• Anidamiento de Grupos AD: Rutas Ocultas a DA
• Ataques NTLM Relay: Secuestro de Autenticación en AD
• Rutas de Ataque en Active Directory hacia Domain Admin

Usar estas referencias mantiene la discusión de remediación centrada en la ruta de ataque completa, en lugar de en un único hueco de control.

Validar alcance, herencia y excepciones

La limpieza de GPO debe probarse contra la estructura real de OU y los flujos de administración que existen en producción. Los equipos deben confirmar qué políticas enlazadas siguen aplicándose a sistemas de alto valor, si los bloqueos de herencia o los derechos de edición delegados introducen nuevas oportunidades de bypass, y si las políticas de emergencia o heredadas siguen justificadas. Esa revisión mantiene el hardening de Group Policy anclado en cómo funcionan realmente el privilegio y el control de estaciones de trabajo en el entorno.

Revisar la propiedad administrativa de los GPO

La pregunta final es quién puede seguir cambiando la política después de la limpieza. Si demasiados administradores, equipos delegados o scripts heredados pueden editar GPO de alto impacto, el mismo riesgo vuelve rápidamente a través de la administración rutinaria. Revisar la propiedad, las rutas de aprobación y la monitorización de cambios sensibles en GPO mantiene el esfuerzo de hardening duradero en lugar de temporal.

Qué vigilar después de la limpieza

Después de un proyecto de remediación de GPO, preste especial atención a los nuevos editores delegados, los cambios de política de emergencia y los enlaces aplicados a OU de alto valor. Esos son los puntos donde las viejas debilidades tienden a reaparecer. Una revisión ligera de las ediciones recientes de GPO, los cambios de propiedad y las políticas recién enlazadas ayuda a confirmar que el entorno se mantiene reforzado una vez concluido el esfuerzo inicial de limpieza.

Mantener la gobernanza de GPO en el tiempo

El control a largo plazo es la consistencia. Si los equipos siguen rastreando quién puede editar políticas críticas, qué cambios de emergencia se saltan la revisión estándar y con qué rapidez se investigan los enlaces de alto riesgo, Group Policy sigue siendo un control defensivo en lugar de convertirse en una superficie de ataque recurrente. Ese ritmo operativo es a menudo lo que distingue una limpieza puntual de un hardening duradero.

El hardening de GPO también depende de la rapidez con la que se revisan los cambios de política inusuales tras mantenimientos fuera de horario, parches de emergencia y despliegues de nuevas estaciones de trabajo. Mantener ese bucle de revisión activo ayuda a los equipos a detectar cuándo ediciones de conveniencia reintroducen configuraciones peligrosas mucho después de que el proyecto de remediación original se haya cerrado. En la práctica, la seguridad duradera de GPO depende menos de tener una línea base perfecta y más de mantener visibilidad sobre cada cambio futuro que pueda afectar a sistemas privilegiados.