ADGPO-008: GPO no aplicadas debido a filtros WMI
- Plataforma
- Active Directory
- Categoría
- AD Group Policy
- Severidad
- Medium
- Pilar de Zero Trust
- Governance (peso 1)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
Los filtros WMI pueden impedir que las GPO se apliquen a los sistemas de destino en función de consultas WQL. Los filtros WMI demasiado amplios o mal configurados pueden bloquear de forma inadvertida la aplicación de GPO críticas para la seguridad en los sistemas que las requieren, lo que crea brechas en la configuración de seguridad prevista
Por qué importa
WMI filters are an additive deny on top of the security filter and the link scope. A GPO applies to a computer only when all three layers permit it: the gPLink reaches the computer through OU or site, the security filter grants Read plus Apply Group Policy to the computer or a group it is a member of, and the WMI filter WQL returns at least one row when run on that computer. If the WMI filter is broken, the GPO silently does not apply, and the resulting gap is invisible in the GPMC link view, which still shows the GPO as enabled and linked. The most common production failures are: a filter written for "Windows 7 and above" that uses Version LIKE "6.%" and therefore excludes every Windows 10 and Windows 11 host (which report 10.0.x); a filter scoped to ProductType=1 attached to a baseline that was later extended to member servers; a filter that references root\CIMV2\Security\MicrosoftTpm on systems that lack the TPM WMI provider; and a filter that depends on a custom inventory namespace populated by an agent that is no longer deployed. The security blast radius depends on what the GPO contained. If the GPO carried the LAPS client GPO settings, every filtered-out host keeps a static or shared local Administrator password (the original LAPS leak vector that drove the Microsoft acquisition and the eventual Windows LAPS shipping in 2023). If the GPO carried AppLocker or WDAC enforcement, the filtered hosts run in audit-only or no policy. If the GPO carried the advanced audit policy or LSA protection (RunAsPPL), the filtered hosts do not emit the logs the SOC depends on and Mimikatz can still read LSASS. WMI filters are also abused offensively: an attacker with GPO edit rights and msWMI-Som write rights can attach a deliberately false WQL filter (SELECT * FROM Win32_OperatingSystem WHERE Version = "0.0") to a security GPO to neutralize it without unlinking the GPO and without raising a "GPO unlinked" audit event. T1484.001 (Group Policy Modification) explicitly covers this technique.
Ruta de ataque
1. Discovery: the attacker enumerates GPOs and their WMI filter bindings with Get-GPO -All | Select DisplayName, WmiFilter, or via PowerView Get-DomainGPO -Properties displayname, gpcwqlfilter. BloodHound (with WriteGPLink and GPO edges) surfaces the same data. The attacker prefers GPOs that carry security baselines: LAPS, AppLocker, Defender exclusions, audit policy, firewall. 2. Permission check: the attacker confirms write rights on either the GPO object (to change gPCWQLFilter) or directly on the msWMI-Som object under CN=SOM,CN=WMIPolicy,CN=System (to rewrite msWMI-Parm2). Group Policy Creator Owners, delegated GPO editors, and OU admins frequently have one or both. ADACL-007 and ADGPO-018 cover the underlying permission misconfigurations. 3. Weaponization (defensive sabotage): the attacker replaces the WQL in msWMI-Parm2 with a query that always returns zero rows, for example SELECT * FROM Win32_OperatingSystem WHERE Version = "0.0.0.0", or attaches an existing broken filter to the target GPO by writing the filter GUID into gPCWQLFilter. SYSVOL replication is not involved because WMI filters live entirely in AD. 4. Weaponization (offensive payload): conversely, an attacker who controls a permissive GPO can attach a true-on-target WQL filter that narrows execution to a specific host class (a DC, a domain admin workstation, a Tier-0 server) before dropping a malicious Scheduled Task or Immediate Task. This is targeted code execution at SYSTEM with no other indicator on the link or security filter. 5. Execution: at the next Group Policy refresh (90 minutes plus 30-minute randomization, immediate on reboot), affected hosts evaluate the new WQL. Filtered-out hosts skip the GPO; targeted hosts execute the payload. The Group Policy event log records Event ID 5017 ("the WMI filter was evaluated") with result "denied (filtering)" on the filtered hosts, which most SOCs do not alert on because it is the normal pathway for WMI-filtered GPOs. 6. Persistence: the broken filter remains in place across reboots and replication cycles. Because the GPO still appears enabled, linked, and security-filtered correctly in GPMC, defenders reviewing the GPO tree see no problem. Only running gpresult /h on a representative host or re-evaluating the WQL surfaces the gap.
Cómo lo evalúa Guerrilla
Guerrilla queries CN=SOM,CN=WMIPolicy,CN=System,DC=domain,DC=tld for every objectClass=msWMI-Som and extracts msWMI-ID, msWMI-Name, msWMI-Author, msWMI-CreationDate, msWMI-ChangeDate, and msWMI-Parm2. The Parm2 string is parsed into namespace plus WQL using the documented length-prefixed format. The check then calls Get-GPO -All and reads the gPCWQLFilter attribute on every GPO, joining filter GUIDs back to the msWMI-Som rows so each GPO has its bound filter resolved. For each (GPO, filter) pair the check runs three evaluations: a syntactic check (does the WQL parse, are quotes balanced, does the namespace exist on a probe host); a content check (does the filter reference deprecated OS versions, ProductType values inconsistent with the GPO link scope, custom namespaces not present in CIMV2 on a representative host); and a live evaluation when a sample of computers from the linked OUs is available (Get-CimInstance -ComputerName $sample -Namespace $ns -Query $wql, with a short timeout). The output row contains GpoDisplayName, GpoId, FilterName, FilterId, FilterAuthor, FilterChangeDate, Namespace, Query, IsValid (bool), Findings (array of strings: "References OS Version 6.1 which is no longer in estate", "ProductType=1 excludes member servers but GPO is linked to OU=Servers", "Namespace root\HP not found on probe host"), IntendedTargets (count from link scope after security filter), PassingTargets (count after WQL evaluation), and CoverageGap (intended minus passing). The check also cross-references Event ID 5017 from forwarded Group Policy operational logs to count how often each filter has denied application in the last 7 days.
Valor recomendado
Todas las GPO críticas para la seguridad se aplican a los destinos previstos; filtros WMI validados frente a las condiciones reales del entorno
Remediación
Revise los filtros WMI vinculados a las GPO críticas para la seguridad con Get-GPO y examinando las asignaciones de filtros WMI. Pruebe las consultas de los filtros WMI frente a sistemas de destino representativos para verificar que se evalúan correctamente. Use Resultados de directiva de grupo (gpresult) en sistemas de muestra para confirmar que las GPO se están aplicando. Reemplace o corrija los filtros WMI que estén bloqueando la aplicación prevista.
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- CM-6, CM-3
- MITRE ATT&CK
- T1484.001